[00:50] <kees> Keybuk: MoM is marking changelogs as jaunty instead of karmic
[01:05] <Keal> i found a severe glitch in ubuntu for athlon64xp cpu machines
[01:05] <Keal> the same glitch is in windows xp
[01:06] <Keal> mass storage devices with a boot partition on them lose power via usb 2.0 as soon as the kernel loads
[01:06] <Keal> causing the kernel to halt loading
[01:08] <lifeless> Keal: you should start by filing a bug
[01:12] <geiseri_> is there a way to force apt to redownload all of the currently installed packages?
[01:12] <geiseri_> apt-get -d install $(dpkg --get-selections | awk '{print $1}') seems to not do it
[01:13] <StevenK> apt-get -d --reinstall ?
[01:13] <geiseri_> oh /me tries that
[01:14] <geofft> Something like rm -r /var/cache/apt; aptitude -d install '~i'?
[01:15] <geiseri_> 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] <directhex> Keal, that would be an issue related to a specific motherboard chipset, not the CPU
[01:43] <Anon> roll call
[01:48] <Anon> where can I get a copy of the libdvdcss library?
[01:49] <Anon> i can't seem to find the LINUX version with a google search
[01:50] <Hobbsee> !libdvdcss
[01:50] <Anon> un erstood
[01:51] <Anon> >understood
[01:51] <Anon> stupid keyboard
[01:51] <Hobbsee> there's a script that will install it for you, too
[01:51] <Hobbsee> in libdvdread4.  However, i think that page will tell you more
[01:52] <Hobbsee> oh, it points directly to medibuntu now
[01:58] <Anon> hobbsee, thanks for the tip on the libdvdcss
[01:58] <Hobbsee> Anon: you're welcome
[01:59] <Anon> i guess I'll see you guys later.
[01:59] <Anon> and thanks for giving version 9.04 the ability to use my sprint wireless air card
[01:59] <Hobbsee> :)
[01:59] <Anon> now i can finally get rid of windows
[01:59] <Anon> later
[03:11] <pace_t_zulu> can someone point me to some documentation regarding install time package detection with dpkg/apt?
[03:22] <lifeless> pace_t_zulu: what do you mean
[03:22] <pace_t_zulu> i am working on a fix for https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/301007
[03:23] <pace_t_zulu> !ubottu
[03:25] <lifeless> pace_t_zulu: it looks like there is a fix as far as packaging is concerned
[03:25] <geofft> pace_t_zulu: why not try: import Tkinter, except: try: import ...?
[03:26] <lifeless> 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] <lifeless> try:
[03:26] <lifeless> e.g.
[03:26] <lifeless>     import tkbackend
[03:26] <pace_t_zulu> are you referring to this fix? http://launchpadlibrarian.net/26327836/matplotlib_0.98.5.2-1ubuntu4.debdiff
[03:26] <lifeless>     return tkbackend
[03:26] <lifeless> except ImportError:
[03:26] <lifeless>     pass
[03:26] <lifeless> try:
[03:26] <lifeless>     import gtkbackend
[03:26] <lifeless>       return gtkbackend
[03:26] <lifeless> except ImportError:
[03:26] <lifeless>     pass
[03:26] <lifeless> etc
[03:27] <geofft> right, what he said, but in fewer words. :) do it at runtime, not install time, because packages can change later
[03:27] <geofft> and check for the python packages, not debian packages. What if I easy_install something?
[03:29] <pace_t_zulu> lifeless thank you
[03:30] <ScottK> geofft: If you easy_install something, the Debian packaging system can't help you.
[03:31] <geofft> sure... that's an argument to do this check outside of the Debian packaging system :)
[03:31] <geofft> for example, I can easy_install something into ~. I can't do that to a Debian package
[03:31] <geofft> 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] <ScottK> Sure.
[03:33] <pace_t_zulu> this is a UX problem i am trying to address... i agree that a backend fix is optimal
[03:34] <ScottK> 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] <pace_t_zulu> ScottK: it is already a depend
[03:34] <ScottK> 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] <pace_t_zulu> ScottK: problem is that the python-tk depend is ORed with python-gtk2 which is available on ubuntu systems
[03:35] <geofft> Er, can't you add a patch to it to do the try/import test if /etc/matplotlibrc doesn't exist?
[03:35] <pace_t_zulu> but the default backend is set to python-tk
[03:35] <geofft> (and not install an /etc/matplotlibrc)
[03:35] <pace_t_zulu> so the python-tk should have an exclusive depend
[03:36] <pace_t_zulu> for a quick fix... but i agree that a more optimal fix should be implemented next
[03:36] <lifeless> its been quick fixed
[03:36] <pace_t_zulu> lifeless: it has not
[03:36] <lifeless> the quick fix for ubuntu is incompatible with a quick fix for kubuntu is incompatible with a quick fix xubuntu
[03:36] <ScottK> OK.  I read the bug.  I understand it now.
[03:36] <pace_t_zulu> python-tk is not installed with python-matplotlib
[03:36] <lifeless> because they all want a different backend
[03:36] <pace_t_zulu> lifeless: exactly
[03:36] <lifeless> so it has been quick fixed. You can't quick fix it any more. Do the real fix.
[03:37] <pace_t_zulu> there are a lot of different ideas about how to be fixed
[03:37] <lifeless> its probably about as much time as has been spent discussing it here to do it.
[03:37] <pace_t_zulu> lifeless: that debdiff that i provided has not been accepted
[03:38] <pace_t_zulu> lifeless: i'm fine with that... do you think it should be implement at the backend?
[03:38] <calc> ok so i don't know if i am the moron or if doko is... bug 373911
[03:40] <calc> 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] <calc> so either i am having a severe reading comprehension issue or he is, lol
[03:41] <lifeless> pace_t_zulu: an auto backend was proposed; and the bug seems to claim there is an upstream bug for that already
[03:42] <calc> doko: ping... you are confusing the hell out of me wrt 373911
[03:43] <pace_t_zulu> 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] <lifeless> pace_t_zulu: have you had much luck convincing people of that?
[06:43] <pitti> Good morning
[06:44] <ScottK> Good morning pitti.
[06:45] <pitti> dtchen: right, I was following along; let's revert the patch, unless you find a better solution; thank you!
[06:45] <pitti> ScottK: hey, how are you? had a nice weekend?
[06:46] <ScottK> pitti: Not bad.  It was Mother's Day here on Sunday, so that was a big day at our house.
[06:46] <ScottK> 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] <pitti> here, too
[06:48] <pitti> ScottK: ugh, recently came from Europe or so? :-)
[06:49] <ScottK> 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] <dholbach> good morning
[07:00]  * pitti hugs dholbach
[07:00] <pitti> Keybuk: good morning
[07:00]  * dholbach hugs pitti back
[07:12] <pitti> 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)
[07:27] <iulian> 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] <iulian> 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] <TheMuso> iulian: hrm I don't remember seeing any policykit bugs.
[07:28] <iulian> Set its status to Fix released or Invalid?
[07:28] <TheMuso> for merging
[07:28]  * TheMuso checks again
[07:29] <TheMuso> iulian: sorry, I totally and utterly missed it. I'll deal with that bug.
[07:30] <iulian> TheMuso: No problem, thanks!
[07:39] <pitti> asac: I was going to propose udev-extras for main today, to switch keymap handling from hal to it
[07:39] <pitti> asac: that will bring the modem prober to main as well
[07:40] <pitti> 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] <pitti> asac: ah, apparently so; could we try using the ones from udev-extras in karmic soon?
[07:42] <dholbach> robert_ancell: good work on the gcalctool merge/update
[07:43] <robert_ancell> dholbach: cheers
[07:57] <lool> Hi all
[08:01] <pitti> hey lool, good morning!
[08:02] <lool> Hey pitti!
[08:45] <didrocks> hey everybody :)
[08:45] <didrocks> doko: around?
[08:51] <djsiegel_> hey didrocks
[08:53] <didrocks> hello djsiegel_
[09:39] <tkamppeter> pitti, hi
[09:39] <pitti> hi takm
[09:40] <pitti> hi tkamppeter
[09:41] <tkamppeter> 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.
[09:41] <pitti> tkamppeter: will do
[09:44] <tkamppeter> pitti, is the last SRU of CUPS already in -updates
[09:45] <pitti> tkamppeter: see "rmadison cups", it is
[09:46] <pitti> tkamppeter: you forgot to bzr add the new patch; please do, commit, and push
[09:48] <tkamppeter> pitti, done
[09:48] <lifeless> TheMuso: patch sent off
[09:49] <TheMuso> lifeless: thanks
[09:50] <pitti> tkamppeter: the ps2write patch doesn't look like an appropriate SRU
[09:50] <pitti> tkamppeter: if you change the gs backend, that has a high regression potential, doesn't it?
[09:55] <lool> Is this a good time to upgrade to karmic?  Anything I should be careful with or hold back?
[09:55] <lool> (/me returns from holidays and wants to jump into karmic)
[09:59] <pitti> lool: works pretty well; UXA might be a bit unstable if you enable it, but it's not by default
[09:59] <tkamppeter> 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] <pitti> tkamppeter: it would help certainly, but switching the entire implementation is still regression prone
[10:00] <pitti> tkamppeter: if there's a focused workaround for the particular affected driver/printer model, this would be more appropriate
[10:07] <tkamppeter> 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] <tkamppeter> of some HP printers, we could tell the users to use PCL-XL mode here.
[10:07] <tkamppeter> pitt WDYT?
[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] <ogra> 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] <ogra> *strict
[10:09] <ogra> (or rather "not userfriendly enough")
[10:15] <pitti> tkamppeter: Is that something they can influence, by picking another driver?
[10:16] <cjwatson> 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] <cjwatson> we might not be that far off the latter
[10:17] <ogra> 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] <ogra> (or even tools that edit the file the wrong way)
[10:24] <tkamppeter> 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] <pitti> Keybuk: hal with libblkd uploaded, FYI; so the only remaining thing is redhat-cluster
[10:24] <asac> 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] <pitti> asac: oh, that's not just a copy?
[10:24] <asac> pitti: no. the udev-extras thing was an experiment afaik
[10:25] <tkamppeter> pitti, for the incompatibility with the Canon driver one will need the ps2write device.
[10:25] <pitti> asac: if it should permanently live in n-m, then we should remove it from udev-extras completely IMHO
[10:25] <lifeless> TheMuso: please read my patch; if you're happy with it we could just land it in karmic ;)
[10:25] <pitti> asac: (and I agree that it would make sense to keep it in NM)
[10:25] <TheMuso> lifeless: will have a look in a bit.
[10:26] <asac> pitti: i will check with Dan, for now i would think it should be removed ... it might do harm
[10:26] <asac> by probing some modem ports its not supposed to probe etc.
[10:26] <pitti> asac: thanks; indeed it should just be probed once, and the code should just live in one place
[10:28] <lifeless> TheMuso: thanks
[10:29] <directhex> hm, i wish i didn't need to restart my printer every print
[10:32] <pitti> tkamppeter: hm, current cups test suite hangs on "Waiting for jobs to complete..."
[10:32] <pitti> tkamppeter: that worked in the previous upload
[10:42] <TheMuso> 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] <lifeless> TheMuso: cool
[10:43] <lifeless> TheMuso: I can't see how I would have broken older disks :)
[10:43] <TheMuso> 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] <TheMuso> use as in use full-time.
[10:44] <lifeless> cool
[10:44] <lifeless> thanks
[10:47] <pitti> tkamppeter: can you please try to build current cups on current karmic? test suite fails pretty badly (and hangs in sid)
[10:56] <lool> directhex: Congrats on MOTY!
[10:56] <lool> *MOTU
[10:58] <tkamppeter> 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] <pitti> 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] <tkamppeter> pitti, I did not replace Ghostscript by something newer after Jaunty. Did there come a new Ghostscript from Debian?
[11:00] <pitti> tkamppeter: no, apparently not
[11:00] <StevenK> TheMuso: Does that at least solve the reconstruction problem?
[11:00] <TheMuso> StevenK: For isw it will.
[11:01] <TheMuso> 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] <lifeless> TheMuso: Score!
[11:01] <lifeless> TheMuso: have you looked at the 2.4 isw kernel module?
[11:01] <lifeless> *fun*
[11:01] <TheMuso> lifeless: yeah
[11:01] <TheMuso> lifeless: no
[11:02] <\sh> moins
[11:07] <ogra> could someone rescore python-apt on armel ?
[11:08] <ogra> as well as nautilus-share
[11:09] <ogra> and totem
[11:10]  * StevenK waits for ogra to ask for *
[11:10] <ogra> heh
[11:10] <ogra> these three for now, just checking what breaks openoffice
[11:10] <ogra> 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] <ogra> \sh, probably on my way back from barcelona
[11:11] <Hobbsee> ogra: trying to
[11:11] <ogra> (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] <pitti> tkamppeter: hah, I get a lot of gs segfaults in kern.log indeed
[11:13] <StevenK> \sh: Next 18 years: raise child; After that: everything else
[11:14] <ogra> \sh, oh, yeah, congrats btw :D
[11:14] <Hobbsee> 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] <StevenK> Hobbsee: You need to sacrafice a rubber chicken on the stroke of 9pm with a silver handled knife
[11:15] <Hobbsee> StevenK: heh.  Seems like it
[11:15] <lifeless> Hobbsee: what is it unhappy with
[11:15] <Hobbsee> Rescoring https://launchpad.net/ubuntu/+source/nautilus-share/0.7.2-5/+build/989902 (armel).
[11:15] <Hobbsee> Unable to request rescore on armel.
[11:15] <Hobbsee> lifeless: ^
[11:15] <Hobbsee> i've regenerated my LP cookie
[11:15] <lifeless> cprov: ^
[11:16]  * ogra guesses there was not enough sugar in the cookie ... LP likes it sweet :)
[11:16] <StevenK> Estimated build start:  2009-05-12
[11:16] <StevenK> Heh
[11:17] <cprov> Hobbsee: apparently I am, what's the value you want to set ?
[11:18] <ogra> hight++
[11:18] <Hobbsee> ah, damn
[11:18] <ogra> *high even
[11:18] <Hobbsee> the syntax has changed - it needed to be ~/.lpcookie.txt now, not just ~/.lpcookie, which was what my logs had
[11:18] <Hobbsee> lifeless, cprov: sorry for the noise
[11:19] <cprov> Hobbsee: np
[11:21] <Hobbsee> ogra: all tweaked
[11:21] <ogra> thanks a lot
[11:22] <Hobbsee> y/w
[11:22]  * Hobbsee adds the new version to her ~/UsefulCommands
[11:23] <tkamppeter> pitti, I have also many gs segfaults. Which gs drivers is the CUPS test suite using?
[11:23] <pitti> tkamppeter: I don't know by heart
[11:26] <ogra> 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] <seb128> no opinion on the topic
[11:27] <seb128> but it should not be an issue right now
[11:27] <seb128> what is the issue exactly?
[11:28] <tkamppeter> pitti, there is a queue using rastertohp in the test suite, so the cups device of GS is crashing.
[11:28] <ogra> The following packages have unmet dependencies:
[11:28] <ogra>   libnautilus-burn-dev: Depends: libeel2-dev but it is not installable
[11:28] <ogra> seb128, ^^
[11:28] <ogra> from http://launchpadlibrarian.net/26525134/buildlog_ubuntu-karmic-armel.rhythmbox_0.12.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[11:28] <seb128> did nautilus-cd-burner ftbfsed too?
[11:28] <ogra> (yes i know its eel's fault, but i was curious)
[11:28] <seb128> no it's not
[11:28] <seb128> that's a deprecated lib and it's not used nowadays
[11:28] <ogra> oh
[11:29] <seb128> it has been cleaned in karmic
[11:29] <seb128> I expect your issue is that nautilus-cd-burner didn't build on armel
[11:29] <seb128> it did 8 hours ago in fact
[11:29] <ogra> 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] <seb128> ogra: did you apt-get update?
[11:30] <seb128> ogra: should be fixed since 6 hours ago or so
[11:30] <ogra> on the buildd ?
[11:30] <seb128> https://edge.launchpad.net/ubuntu/+source/nautilus-cd-burner/2.25.3-0ubuntu2/+build/978020
[11:30] <ogra> ah, k, so a give back will fix it
[11:30] <seb128> it should
[11:30] <ogra> good, thanks
[11:30] <seb128> you're welcome
[11:30] <ogra> :)
[11:33] <tkamppeter> 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] <Keybuk> cjwatson: a build failure is baffling me
[11:41] <Keybuk> cjwatson: it honestly looks like dpkg hasn't applied the full diff.gz
[11:50] <pitti> 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] <Keybuk> ooh, your stuff got merged?
[11:50] <Keybuk> 3044c4e ok?
[11:50] <pitti> Keybuk: I committed it myself with Kay's approval
[11:50] <pitti> Keybuk: 3044c4e ack
[11:51] <pitti> Keybuk: also, asac said that we should not install the modem prober for now, since it's already in NM
[11:51] <pitti> Keybuk: unless you want to do that, I can work on it later
[11:51] <Keybuk> modem-probe is empty now, no?
[11:51] <pitti> oh right, that was modem-modeswitch
[11:51] <ogra> hrm, no mvo today ?
[11:52] <pitti> ogra: holiday
[11:52] <pitti> Keybuk: ok, thanks
[11:52] <ogra> gah
[11:52] <Keybuk> 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] <cjwatson> Keybuk: oh?
[11:55] <Keybuk> cjwatson: looks like the diff.gz was corrupted
[11:56] <cjwatson> odd that it didn't bail if so
[11:56] <cjwatson> or was it corrupted such that that was justifiable?
[11:59] <Keybuk> I think that things were just missing from it
[11:59] <Keybuk> dpkg-source--
[11:59] <Keybuk> since they're clearly in my working directory as changes ;)
[11:59] <Keybuk> regenerated it and it looks ok now
[12:39] <james_w> jdstrand, kirkland: syncbugbot failed for me too. Regenerating my lpcookie fixed it though
[12:42] <cjwatson> james_w: there's an RT request open for diffstat
[12:42] <james_w> cjwatson: cool, thanks
[12:56] <pitti> 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] <pitti> Keybuk: whoops, missed new gperf build dep; I'll upload a new version
[13:01] <pitti> Keybuk: hm, can you please bzr push udev-extras?
[13:04] <asac> 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] <pitti> asac: cool
[13:05] <pitti> asac: do you know whether the modem prober makes all those hal-info FDIs obsolete already?
[13:05] <pitti> asac: I wonder what's missing in order to drop them
[13:05] <Keybuk> pitti: weird "these branches have diverged" <g>
[13:05] <pitti> Keybuk: did you pull first? I added a test suite call to debian/rules
[13:05] <Keybuk> ahh
[13:05] <Keybuk> I did pull
[13:06] <Keybuk> but of course, bzr pulled from the wrong place
[13:06] <asac> pitti: in theory it makes them obsolete ... however, we still use them to tie-break if the modem prober is unsure
[13:06] <Keybuk> so said everything was fine
[13:06] <pitti> Keybuk: I told you in the morning, but I guess you weren't sufficiently caffeinated yet or so :)
[13:06] <Keybuk> pitti: I don't read IRC scrollback
[13:06] <asac> pitti: you are looking in removing hal-info completely? or just the 10-modem.fdi?
[13:07] <pitti> asac: eventually it needs to go away completely
[13:07] <pitti> but of course we should remove stuff part by part, once we know that it can go
[13:07] <Keybuk> pitti: ok, pushed
[13:08] <asac> pitti: i think we cannot remove 10-modem.fdi upstream ... we still need SRUs for hardy/intrepid for a while i guess
[13:08] <pitti> asac: yes, but we shoudl eventually stop shipping them in karmic
[13:08] <pitti> ./configure --without-modem or so
[13:11] <tkamppeter> pitti, I have looked into the error_log of the test suite of CUPS. pdftops segfaults in job 4.
[13:11] <pitti> 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] <asac> 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] <pitti> asac: yeah, I wondered whether we should disable them early and ask for regression testing
[13:12] <Keybuk> pitti: autoreconf -i
[13:12] <pitti> Keybuk: great, will do that
[13:12] <Keybuk> usually bzr clean-tree first
[13:12] <pitti> already done
[13:12] <TheMuso> 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] <pitti> Keybuk: why not do that in debian/rules then, in build/ ?
[13:13] <pitti> TheMuso: right, I know; X.org input needs work as well
[13:13] <pitti> 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] <pitti> to minimize the structural changes in the lazy lizzard (LTS)
[13:14] <TheMuso> Ok, I'll see what upstream plans on doing.
[13:14] <Keybuk> pitti: I don't like putting that kind of thing in debian/rules
[13:15] <pitti> ooh, we can have orig.tar.bz2 now?
[13:15] <Keybuk> since it means you're uploading something that you haven't actually tested the build of
[13:16] <asac> pitti: http://paste.ubuntu.com/169518/
[13:16] <asac> pitti: so removing hal would make all modems get deferred initialization ... looked at code, and i think it should be fine.
[13:17] <pitti> asac: it looks like only d) is the remaining concern then?
[13:17] <asac> pitti: in any case. i think we shouldnt remove 10-modem.fdi
[13:17] <asac> modemmanager uses hal atm and we want to experiment with that (hopefully moving it to udev as well)
[13:18] <pitti> 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] <asac> 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] <Keybuk> pitti: keymaps/* doesn't look like a valid taget?
[13:18] <pitti> asac: sure
[13:19] <Keybuk> pitti: you can't use wildcards like that ;)
[13:19] <asac> ok i will tell you once we have made progress
[13:19] <pitti> Keybuk: keymap/Makefile.am has udevkeymap_DATA = keymaps/*
[13:19] <Keybuk> pitti: exactly, you can't use wildcards in make like that
[13:19] <Keybuk> that means a file *called* keymaps/*
[13:20] <pitti> Keybuk: $(shell ls keymaps/*) then?
[13:20] <Keybuk> pitti: Automake will forbid it
[13:20] <Keybuk> pitti: just list them
[13:21] <Keybuk> 27.3 Why doesn't Automake support wildcards?
[13:21] <Keybuk> Developers are lazy.
[13:21] <pitti> that's stupid
[13:21] <Keybuk> (and then with sensible rationale)
[13:21] <Keybuk> read that info page
[13:21] <pitti> having to explicitly list all files in a subdir?
[13:22] <Keybuk> pitti: then you'll end up accidentally distributing keymap~
[13:22] <pitti> that reminds me why I ripped out the automake stuff from human-icon-theme and friends
[13:22] <Keybuk> keymap.orig
[13:22] <Keybuk> keymap.rej
[13:22] <Keybuk> etc.
[13:22] <pitti> meh
[13:23] <Keybuk> 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] <tkamppeter> 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] <pitti> Keybuk: glob -> explicit list committed to trunk
[13:32] <pitti> Keybuk: and gperf build dep committed as well; could I ask you for another git pull?
[13:34] <Keybuk> pitti: pulled, merged, pushed
[13:34] <pitti> Keybuk: thanks
[13:35] <directhex> yay james_w
[13:35] <directhex> \o/
[13:36] <sveinung__> 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] <sveinung__> 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] <sveinung__> By the way: How long should a package be in Karmic before I can suggest a sru to jaunty?
[13:39] <cjwatson> i/wg 169
[13:39] <cjwatson> (sorry)
[13:39] <mnemo> sveinung__: which bugs is it?
[13:39] <pitti> tkamppeter: is that due to one of our patches? I know that it didn't happen in 1.3.10-1
[13:40] <sveinung__> pitti: bug 345706
[13:40] <pitti> sveinung__: you probably meant "mnemo"?
[13:42] <sveinung__> pitti: mnemo?
[13:42] <pitti> sveinung__: "mnemo| sveinung__: which bugs is it?" and you pinged me
[13:42] <sveinung__> aah
[13:42] <sveinung__> pitti: sorry about that
[13:42] <pitti> sveinung__: np :)
[13:43] <sveinung__> mnemo: bug 345706
[13:46] <mnemo> 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] <pitti> Keybuk: *sigh* I committed another build fix to trunk, sorry; but this is the last one, it really works now
[13:51] <Keybuk> pitti: pulled, merged, pushed
[13:51]  * pitti hugs Keybuk
[13:51] <sveinung__> 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] <pitti> seems that "bzr-git" is really called "Keybuk"
[13:56] <Chipzz> sveinung__: I think that what mnemo means is, SRUs happen occasionally rather than often.
[13:56] <Chipzz> not just everything gets SRU'd; there needs to be a very good reason to make an SRU
[13:59] <pitti> asac: I would be grateful if you could process bug 374844, since I wrote it, and it affects you most (with n-m)
[14:00] <TheMuso> 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] <pitti> asac: if possible, I'd like to get it into alpha-1, but if you are swamped, it's not that urgent
[14:01] <asac> pitti: will do
[14:01] <asac> will review today
[14:01] <MacSlow> bryce, hey there
[14:04] <ogra> 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] <TheMuso> 6/c
[14:05] <ogra> Package libgnome-2.0 was not found in the pkg-config search path.
[14:05] <ogra> Perhaps you should add the directory containing `libgnome-2.0.pc'
[14:05] <directhex> ogra, missing comma perhaps?
[14:05] <ogra> ... Package 'libgnome-2.0', required by 'GNOME Media Profiles', not found ...
[14:05] <ogra> directhex, hmm, only on armel ?
[14:06] <directhex> ogra, okay, it just hates you then
[14:06] <ogra> oh, wait, i'm blind, it failed everywhere :P
[14:06] <ogra> hrm, apart from i386
[14:06] <ogra> now thats intresting :)
[14:07] <seb128> ogra: it probably didn't pick the fixed gnome-media
[14:07] <directhex> ogra, link to build log?
[14:07] <seb128> https://edge.launchpad.net/ubuntu/+source/gnome-media/2.26.0-0ubuntu4
[14:07] <seb128> indeed
[14:07] <seb128> didn't build on armel
[14:07] <ogra> ah
[14:07] <lool> Hmm there's a weird issue in krb5
[14:07] <seb128> https://edge.launchpad.net/ubuntu/+source/gnome-media/2.27.1-0ubuntu1 built now
[14:07] <seb128> so a retry will do
[14:07] <ogra> heh
[14:07] <lool> It picked a bunch of deps on a bunch of arches
[14:08] <lool> Depends: libkrb5-3 (= 1.7dfsg~beta1-4), libkadm5srv6 (= 1.7dfsg~beta1-4), comerr-dev, libk5crypto3 (= 1.7dfsg~beta1-4), libgssapi-krb5-2 (= 1.7dfsg~beta1-4), libgssrpc4 (= 1.7dfsg~beta1-4)
[14:08] <lool> (that's lpia for instance)
[14:08]  * ogra spends his day with RB retries, funny :)
[14:08] <lool> on amd64 it's just:
[14:08] <lool> Depends: libkrb53 (= 1.6.dfsg.4~beta1-5ubuntu2), libkadm55 (= 1.6.dfsg.4~beta1-5ubuntu2), comerr-dev
[14:08] <directhex> ogra, well, you could score up the build of https://launchpad.net/ubuntu/karmic/+source/banshee/1.4.3-4 on arm ;)
[14:09] <ogra> i'm not intrested in banshee atm :) .... A1 is my whole focus
[14:10] <sveinung__> Chipzz: ok. My main consern was to get it into the development version. Any bug in my bugreport that reduses the chance for an upload to Karmic?
[14:11] <lool> Ah no, I'm just stupidly looking at jaunty versus karmic
[14:11] <lool> So it's just some bogus NEW
[14:12] <seb128> james_w: ok, let's try there maybe then ;-)
[14:12] <james_w> :-)
[14:12] <lool> pitti: libkadm5srv6 is in universe, but libkrb5-dev depends on it (and is in main)
[14:13] <ogra> lool, yeah there werte component issues the last week with karmic, might be another fallout of that
[14:13] <lool> Oh it's not your day at all
[14:13] <lool> slangasek, Riddell: libkadm5srv6 is in universe, but libkrb5-dev (in main) depends on it
[14:14] <ogra> (things ended up in the wrong place after syncs or some such)
[14:14] <seb128> does anybody knows if the original copyright holder has to be listed when translating code in an another languages?
[14:14] <seb128> some people have been copying the tomboy code in c++, doing a line by line translation
[14:14] <seb128> should the tomboy copyright holders still be listed?
[14:14] <seb128> elmo: ^ do you know?
[14:14] <lool> slangasek, Riddell: and libgssrpc4 as well
[14:15] <lool> seb128: Yes, they do
[14:15] <lool> seb128: It's really a derivative work
[14:15] <directhex> seb128, my understanding is it's a very sticky situation, since it pretty much defines "derived work" - best practice should be "just include it, to remove ambiguity" IMHO
[14:15] <lool> seb128: There was an LWN article on this case BTW :)
[14:15] <seb128> lool: I should perhaps read LWN regularly ;-)
[14:15] <lool> http://lwn.net/Articles/331187/
[14:15] <seb128> directhex: right, it would be nicer for sure, we were wondering if that's a reason to not accept the upload though
[14:16] <Riddell> seb128: new glib recently?
[14:16] <seb128> Riddell: not yet, but coming soon, why?
[14:16] <directhex> seb128, that's up to the archive admi... oh, right.
[14:17] <lool> directhex: There's no doubt that automatically or manually translating code at this scale between languages is a derivative work  :)
[14:17] <Riddell> seb128: actually, never mind
[14:17] <Riddell> lool: one sec
[14:21] <tkamppeter> pitti, I have investigated the GS segfault now, "ps2write" is not able to render test/testfile.pdf
[14:21] <tkamppeter> gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOUTPUTFILE=%stdout -dLanguageLevel=2  ../build-area/cups-1.3.10/test/testfile.pdf > x
[14:21] <tkamppeter> segfaults.
[14:21]  * ogra tickles lamont 
[14:22] <pitti> tkamppeter: hah, that's what I meant with "high regression potential" :-)
[14:23] <pitti> tkamppeter: do you think that's easily fixable, or should we rollback the patch for now?
[14:23] <tkamppeter> pitti, when I return to pswrite the file gets correctly rendered. Seems that I have to work with the GS developers to get a correctly working PS output device. Seems that PS generation must be done by other for at least a year before we can take the software.
[14:23] <pitti> tkamppeter: it seems that we keep switching backends (poppler, ghostscript, ps -> pdf), and this often leads to replacing old and understood bugs with new and untriaged bugs :-(
[14:23] <Riddell> lool: done
[14:24] <tkamppeter> Yes, finding that one filter solves one bug causes always another bug.
[14:24] <Riddell> let me know if anything else needs fixing for that, it's breaking all the KDE builds too (and slangasek is on holiday)
[14:26] <tkamppeter> pitti, GS developers are tending to switch to ps2write as standard PS output device. So perhaps we should support them by 1. reporting this bug, and 2. in Karmic stay with ps2write to collect more bug reports and so to tell GS developers what to fix.
[14:26] <tkamppeter> pitti, if we get close to Karmic release and GS developers did not fix the reported bugs we go back to pswrite.
[14:27] <pitti> tkamppeter: but if the test suite fails, we can't even build the package
[14:27] <tkamppeter> pitti, the most important is to report all bugs upstream.
[14:27] <pitti> and I'm reluctant to upload a known regression into debian sid, too
[14:28] <directhex> seb128, at any rate, i absolutely cannot give advice on that particular decision for political reasons, just offer personal opinions. IANAL, YMMV, IDDQD
[14:28] <tkamppeter> pitti, perhaps we can temporarily replace the test/testfile.pdf until GS developers fix this bug.
[14:31] <pitti> tkamppeter: that would work for me
[14:31] <pitti> tkamppeter: but I would like to see the test suite pass with some real pdf file
[14:32] <pitti> tkamppeter: why not back out the patch entirely until it's fixed in gs?
[14:32] <elmo> seb128: yes, they should
[14:32] <lool> Riddell: Ok; will tell you if anything else shows up; how long does it take to be able to kick rebuilds?
[14:32] <lool> Riddell: Will you mass give back?
[14:34] <Riddell> lool: next publisher run, should be within the half hour I guess
[14:34] <Riddell> lool: no I'm not a buildd admin
[14:37] <ogra> elmo, pkern notified me that the new gobby version in karmic might have incompatibilities with the former gobby server (just a heads up in case we have karmic users at UDS)
[14:37] <james_w> ogra: it's a new binary package name
[14:38] <ogra> james_w, yes
[14:38] <james_w> so they can just use the old one
[14:38] <ogra> indeed
[14:38] <ogra> still the new one is protocol incompatible he said but has undo :)
[14:39] <lool> Riddell: ok thanks
[14:42] <seb128> elmo: thanks
[14:45] <pitti> james_w, jdstrand, seb128: did any of you run sync-source -a and flushed without NOMAILS=-M?
[14:45] <james_w> pitti: ah, me, sorry
[14:45] <pitti> james_w: NP, just a reminder
[14:45] <seb128> pitti: not today, but when I that previous time it didn't email the list
[14:45] <pitti> I saw that several times already, and wanted to send a reminder
[14:46] <james_w> pitti: I'll remember for next time
[14:46] <james_w> thanks
[14:47] <seb128> pitti: I think NOMAILS is not required nowadays
[14:47] <seb128> pitti: it seems that when you don't specify a -b login it doesn't email
[14:47] <pitti> seb128: apparently it is, look at karmic-changes@ ?
[14:47] <seb128> pitti: those are manual syncs
[14:47] <pitti> seb128: sync-source.py -a doesn't use -b AFAIK
[14:47] <pitti> oh really, that many?
[14:47] <pitti> james_w: ^
[14:47] <pitti> for manual syncs it's fine of course
[14:47] <seb128> I've only 39 emails listed
[14:47] <pitti> but over the weekend I got a bunch of like 80
[14:48] <james_w> I did none over the weekend
[14:48] <seb128> and I've the equivalent account in the ubuntu-archive list
[14:48] <james_w> it was a long list of requests today though
[14:48] <pitti> james_w: ok, sorry for the noise then
[14:48] <james_w> good reminder though :-)
[14:48] <seb128> I'm pretty sure that the list doesn't get mailed if you don't -b, I tried to figure why my syncs where not listed the other day
[14:48] <seb128> and I figured that only -b ones are showing there
[14:48] <james_w> yeah, they were all manual
[15:00] <pitti> kees, asac: could either of you please process bug 369185 and bug 369191? they are an alpha-1 blocker
[15:01] <pitti> (since g-p-m needs it now)
[15:07] <tkamppeter> pitti, so I will take it out and report a bug to GS. Should I simply do another commit removing it or can you roll back the BZR to remove it?
[15:07] <pitti> tkamppeter: just disable it in patches/00list and remove it from the changelog
[15:10] <mterry> How do you leave comments or bug links in m-o-m?
[15:10] <tkamppeter> pitti, seems that pdftops filters have still to mature. I would like to go Ghostscript as they seem to get forward more quickly with color management and they support files with more than one paper size ...
[15:10] <asac> mterry: i think m-o-m is just read-only
[15:10] <asac> what are you trying to do?
[15:11] <mterry> asac: See https://merges.ubuntu.com/universe.html on the right side
[15:11] <mterry> asac: Seems some people have noted that something is claimed or left a link to the bug for it
[15:12] <asac> interesting ;)
[15:12] <Keybuk> pitti: random non-udev-extras related question for you, as a security head
[15:12] <Keybuk> why are people regenerating their gpg keys?
[15:12] <Keybuk> I thought the problem was SHA-1, not DSA?
[15:12] <Keybuk> you can use SHA-2 with DSA no?
[15:12] <pitti> Keybuk: TBH I haven't even followed that incident, I just noticed people on planet.d.o and other places going crazy
[15:14] <Keybuk> of course, more amusingly, isn't SHA-1 somewhat fundamental to git's operatio
[15:14] <Keybuk> where changing from SHA-1 to something else is a "burn the archive"-level operation?
[15:15] <broonie> It's not a realistic attack yet; for git you've got the added thing that since it's a SCM any replacement plaintext needs to be buildable source code too.
[15:16] <tkamppeter> pitti, done. Now a CUPS build is not urgent any more, so if you have more important to do ...
[15:16] <pitti> tkamppeter: ok, understood; yes, I have another pending patch from Martin-Eric, so I'll do an upload later then
[15:16] <pitti> tkamppeter: thanks for having looked into that!
[15:17] <Keybuk> broonie: which is what confuses me
[15:17] <Keybuk> since surely for Debian, any replacement plaintext needs to be a valid changes file as well
[15:17] <Keybuk> so why the OMG-level panic
[15:17] <broonie> Keybuk: It's basically people overreacting, plus the idea that it'd be better to transition now rather than when it's an emergancy.
[15:18] <cjwatson> Keybuk: nobody's saying "panic" AFAICS
[15:18] <cjwatson> lots of people are producing lots of noise but I don't think it's panic
[15:19] <Keybuk> cjwatson: "The general consensus is that we should be "moving in an orderly fashion toward the theater exits,"" is not exactly calling for calm
[15:19] <directhex> it is compared to ARGH ARGH ALL PASSWORDS EVER COMPROMISED RUN FOR THE HILLS
[15:20] <cjwatson> Keybuk: see Schneier's post on the subject; it's "walk, don't run"
[15:20] <directhex> or "oh, oops, openssl is meant to have entropy isn't it"
[15:20] <cjwatson> Keybuk: DSA keys can in theory use non-SHA-1 hashes, although (a) the original specification calls for SHA-1 (b) it's set at key generation time so if you want to change it you have to regenerate the key anyway *shrug*
[15:21] <cjwatson> Schneier: http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html
[15:22] <cjwatson> Keybuk: and yes, of course collision weakness is not the same as a second-preimage attack, let alone a practical attack on real protocols where of course you need collisions to take a specified form; but it's a good early-warning sign
[15:22] <Keybuk> but didn't one come up years ago anyway?
[15:22] <Keybuk> about the time Debian started added SHA-256 to things?
[15:22] <cjwatson> Keybuk: one thing most people miss is that collisions in hash functions are actually not all that much different from the original message, so I'm not sure the "real-protocol" defence is quite as strong as it looks
[15:22] <cjwatson> Keybuk: this one is orders of magnitude better
[15:22] <broonie> cjwatson: Well, you can issue new prefernces later on but ATM it's not possible to remove SHA-1 since the spec iwll insert it by default.
[15:23] <cjwatson> broonie: I mean for the key itself
[15:23] <cjwatson> the DSA key length is a function of the hash you choose at the start
[15:23] <Keybuk> cjwatson: shouldn't the proper key ordering be gnupg defaults rather than requiring everyone to update, if it's a real problem?
[15:23] <cjwatson> Keybuk: specifically, this one appears to be in the "$20K machine to crack in eminently practical time" range
[15:24] <cjwatson> well, for "crack" => "find collision"
[15:24] <geofft> broder
[15:24] <geofft> gah, my client sucks. Ignore me.
[15:24] <d1b> cjwatson: how much of that message can be modified ?
[15:24] <cjwatson> Keybuk: the gnupg people are indeed in the process of changing the defaults
[15:24] <cjwatson> d1b: which message?
[15:24] <d1b> a potential message.
[15:24] <cjwatson> how long is a piece of string?
[15:25] <d1b> 4 yarns
[15:25] <directhex> cjwatson, 18 inches
[15:25] <d1b> i take it then that it is not currently know how effective the attack is then.
[15:25] <d1b>  / how similiarthe collision version would be.
[15:25] <cjwatson> taking a practical example, signed .changes files contain descriptions of the packages and of the changes made in that upload; lots of room for manoeuvre there
[15:26] <cjwatson> d1b: do you know the difference between collision and second-preimage?
[15:26] <d1b> cjwatson: no.
[15:26] <cjwatson> this is a demonstration of collision weakness: in other words, the ease of constructing two messages from scratch with the same SHA-1 hash has been demonstrated to be on the order of 2%2
[15:26] <cjwatson> err, "on the order of 2^52"
[15:27] <cjwatson> an attack on a real cryptosystem would involve a second-preimage attack: in other words, constructing another message with a given SHA-1 hash
[15:27] <cjwatson> collision resistance and second-preimage resistance are not the same, and this is about the former, not the latter. *However*, once collision resistance goes, it usually turns out that second-preimage resistance is not far behind
[15:28] <cjwatson> so nobody is alleging a practical attack on real cryptosystems yet; what they are saying is that this is an alarm signal that sensible people would do well to pay attention to before the real alarms go off
[15:29] <cjwatson> so yes, it is a bit silly for everyone to panic and change their keys over. On the other hand it takes a while to reestablish a web of trust and it probably makes sense to do that sooner rather than later.
[15:29] <d1b> cjwatson: i don't follow how the second preimage is "not far behind"
[15:30] <jdstrand> slangasek: re launchpad api> yes, I suppose that is true. I haven't looked at it too closely, but I assumed it was saving the info somewhere like a cookie that could be copied over.
[15:30] <james_w> if it is possible to find a collision in reasonable time, then it is likely to be able to find a second preimage also in reasonable time
[15:31] <cjwatson> d1b: e.g. http://eprint.iacr.org/2004/304.pdf
[15:31] <tkamppeter> pitti, http://bugs.ghostscript.com/show_bug.cgi?id=690475
[15:31] <jdstrand> slangasek: though, everyone is claiming just regenerating the lpcookie file should do it, so I guess I'll try... (odd that it works at home and not on cocoplum, but *shrug*)
[15:31] <pitti> tkamppeter: feel free to add that reference to the dpatch header
[15:31] <cjwatson> briefly, as I understand it: if you can construct messages that collide, and then come up with a method for composing them, that forms part of a toolkit for attempting second-preimage attacks
[15:32] <d1b> what about the recent development on prime numbers, does this affect the situation ?
[15:32] <cjwatson> Keybuk: on SHA-1 and git: http://kitenet.net/~joey/blog/entry/sha-1/
[15:33] <pitti> calc: ok, seems that all those -openoffice.org libs weren't as bad as I thought; it's by and large just package renamings
[15:33] <cjwatson> d1b: which recent development is that?
[15:33] <pitti> calc: so, sorry for freaking out a bit
[15:34] <Keybuk> cjwatson: if collisions can be made relatively similar enough such that they satisfy a changes parser
[15:34] <Keybuk> surely one can write colliding source that differs only in areas such as buffer bounds numbers?
[15:35] <cjwatson> Keybuk: YM for git?
[15:35] <Keybuk> you might not be able to sneak a web server into the code
[15:35] <Keybuk> but you might be able to sneak in enough of a gap to use as your own backdoor
[15:35] <Keybuk> cjwatson: indeed
[15:35] <cjwatson> Keybuk: theoretically, yes. Nobody's yet demonstrated it but that means that now is the time to prepare rather than leaving it until it's too late
[15:36] <Keybuk> I'd extend joey's example
[15:36] <Keybuk> you commit the bad code to your git repo
[15:36] <Keybuk> but you send the good patch to LKML
[15:36] <Keybuk> with a note that you pull from the bad repo to get it
[15:36] <Keybuk> people will review the good patch, but pull the bad patch
[15:36] <Keybuk> the SHA-1 will match, so nobody knows what happened
[15:36] <cjwatson> righ
[15:36] <cjwatson> t
[15:39] <tkamppeter> pitti, done
[15:42] <calc> pitti: ok
[15:42] <pitti> calc: I'm done with the bug now; they all need gcj->default-jdk conversion, and there are two FTBFS, but otherwise look alright
[15:42] <calc> pitti: ok
[15:43] <pitti> calc: I cleaned up the old packages while I was at it
[15:43] <pitti> so duplication is basically null
[15:43] <calc> ok
[16:09] <pitti> asac: yay, thanks
[16:10] <pitti> asac: I'll go ahead and disable keymaps in hal then, and add udev-extras to the standard platform seed
[16:10] <pitti> Keybuk: ^ any objection?
[16:10] <Keybuk> none
[16:10]  * Keybuk does a little dance
[16:10] <pitti> cool
[16:11] <pitti> Keybuk: gvfs migration to devkit-disks is in our PPA, and g-p-m is converted in karmic
[16:11] <pitti> so by now we dropped a fair bit of HALness
[16:11] <Keybuk> why in the PPA? :p
[16:11] <Keybuk> it'd be nice to get X moved from HAL to libudev
[16:11] <pitti> Keybuk: the packages took a while to get built in karmic, only got them on the weekend
[16:11] <Keybuk> that's probably one of the last pieces, no?
[16:12] <Keybuk> evand was overjoyed that he could use devkit-disks for usb-creator
[16:12] <pitti> and the gvfs-devkit thing has some major regressions still
[16:12] <pitti> Keybuk: we still have pulseaudio, X.org input, pm-utils quirks at least
[16:12]  * evand hugs pitti
[16:12] <pitti> the former two are in the works, AFAIUI
[16:12] <pitti> but I didn't see any discussion about suspend quirks
[16:15] <tkamppeter> pitti, what about the SRU for foomatic-db-engine on bug 373371 and bug 361772?
[16:16] <pitti> tkamppeter: I'll get to them, don't worry
[16:22] <pitti> kirkland: please update screen's recommends: to screen-profiles
[16:22] <pitti> kirkland: I'll move byobu to main and remove screen-profiles from karmic
[16:22] <kirkland> pitti: i did
[16:22] <kirkland> pitti: uploaded that this morning
[16:22] <pitti> kirkland: ah, then I guess it just didn't build yet; thans
[16:22] <ion_> pitti: Would it be possible to put all the devkit changes under a specific repository component in your PPA, so users could select the amount of potential breakage they’re happy with? :-)
[16:23] <kirkland> pitti: https://edge.launchpad.net/ubuntu/karmic/+source/screen/4.0.3-11ubuntu6
[16:23] <pitti> ion_: it's in the ubuntu-desktop PPA, and it's just gvfs
[16:23] <pitti> ion_: the rest is already in karmic
[16:23] <pitti> ion_: also, there's nothing else worthwhile in u-desktop PPA ATM
[16:24] <ion_> pitti: I see. I was thinking of stuff that may appear in the PPA in the future, though.
[16:25] <seb128> the gvfs bits should lande to karmic soon since they have commited to upstream git now
[16:25] <pitti> seb128: it still breaks the libgphoto backend
[16:25] <pitti> and two smaller ones (cdda and another one I forgot)
[16:26] <seb128> in which way?
[16:26] <pitti> I'd miss libgphoto, though
[16:26] <pitti> seb128: it doesn't build
[16:26] <seb128> weird
[16:26] <pitti> haven't spend much time on that yet
[16:26] <seb128> I doubt FC11 will ship without that backend so they must have fixed it
[16:26] <seb128> or do we need a newer libgphoto?
[16:26] <pitti> seb128: might just be PEBCAK
[16:26] <pitti> I'll get to it
[16:27] <seb128> I can do a git build for the fun of it if you want
[16:27] <seb128> and let you know if that builds here
[16:31] <pitti> seb128: I built it from David's gvfs branch back then
[16:31] <pitti> seb128: if it costs you nothing, sure :)
[16:31] <geiseri_> hi, i am having problems with setting up custom partition recipes in the preseed file.  The partition looks right, but for some reason the installer is complaining that there is no root filesystem defined
[16:31] <seb128> pitti: it's in gnome git now, I will give it a try
[16:31] <pitti> perhaps they did some further fixes in the meantime
[16:31] <pitti> seb128: I'll merge libgphoto now, we need to do that anyway
[16:32] <geiseri_> did i miss a step? or is some more examples of how this works?
[16:32] <seb128> pitti: ok thanks
[16:32] <pitti> Keybuk: I guess you wouldn't hurt me if I merged libgphoto?
[16:32] <pitti> (it's assigned to you ATM)
[16:32] <cjwatson> geiseri_: need to see preseed file plus syslog
[16:32] <cjwatson> geiseri_: this happens when something goes wrong in applying the partitioning recipe
[16:33] <cjwatson> geiseri_: am I misremembering or did we not already discuss this last week or so?
[16:33] <geiseri_> cjwatson: we discussed setting up the package sets, that i solved over the weekend with apt-move... this week is setting up the partition and im good to go :)
[16:34] <geiseri_> let me bring up pastebin and ill get you the preeseed recipie
[16:34] <kees> pitti: re: devicekit.  can you tell me quickly how it interfaces with the system?  aiui, hal listens for udev events, and rules pattern matches, adds stuff to the dbus tree, and sometimes runs helper scripts.  is that the same for DK?
[16:35] <pitti> kees: DK itself is significantly simpler; it just provides a d-bus interface to the udev db
[16:35] <pitti> kees: it doesn't store anything, nor read files etc.
[16:36] <kees> pitti: ah, much nicer.  :)
[16:36] <pitti> kees: it's all in the MIR
[16:36] <Keybuk> pitti: I would not
[16:36] <kees> yup, just read it now, and wanted to clarify.
[16:36] <pitti> kees: DK itself will go away entirely at some point, but for now we need it
[16:36] <cjwatson> this dpkg-vendor thing is nice
[16:37] <kees> since the recent dbus and udev security glitches, I'm suspicious of anything near them.  ;)
[16:37] <cjwatson> you can test 'dpkg-vendor --derives-from Ubuntu' or 'dpkg-vendor --is Debian' or that kind of thing
[16:37] <kees> cjwatson: ooh, neato
[16:37] <cjwatson> and (as of base-files 5.0.0ubuntu2, just uploaded) it knows that Ubuntu is a derivative of Debian
[16:38] <geiseri_> cjwatson: http://rafb.net/p/GRfG7p20.html here is the section of the preseed file
[16:38]  * geiseri_ is still trying to get syslog from qemu
[16:38] <cjwatson> well, even before that, I see two syntax errors there
[16:38] <geiseri_> cjwatson: oh good :\
[16:38] <cjwatson> options/errors{errors=remount-ro} options/data{data=writeback}
[16:39] <cjwatson> you need spaces inside the {} (so "options/errors{ errors=remount-ro } options/data{ data=writeback }")
[16:39] <cjwatson> yes, the syntax is a bit strange
[16:39] <geiseri_> ah, okay
[16:39] <cjwatson> I don't know whether that's the problem here
[16:39] <cjwatson> I'm also not sure partman actually supports options files like that but anyway :-)
[16:39] <geiseri_> oh
[16:39]  * geiseri_ can do some sedfu on the fstab as a post install if needed
[16:39] <kees> pitti: is it possible for devicekit to use PR_SET_SECCOMP?  (see man prctl)  or does it need access to open() ?
[16:40] <cjwatson> geiseri_: *probably* shouldn't matter for this purpose
[16:41] <pitti> kees: I guess it open()s quite often through libdbus, but I have to check; perhaps you can ask that in the MIR bug? (busy ATM, sorry)
[16:41] <pitti> kees: PR_SET_SECCOMP> interesting, I didn't know that one
[16:41] <kees> pitti: well, I've approved it, but it's more of a curiosity.
[16:41] <pitti> ah, thansk
[16:42] <kees> pitti: yeah, just learned about it myself, which is why I've been posing that question to every service I can think of.  :)
[16:42] <cjwatson> geiseri_: oh and delete your preseeding of partman-auto/init_automatically_partition
[16:42] <kees> pitti: the answers tend to be "no".  :P
[16:42] <geiseri_> cjwatson: okay
[16:42] <cjwatson> probably irrelevant here but it is definitely confusing to have automatic partitioning preseeding and then also ask for manual partitioning at the same time ...
[16:42] <pitti> kees: it might work, though, if it opens netlink and dbus sockets and then keeps them open
[16:43] <pitti> kees: please post it anyway, I'll keep the mail to investigate
[16:43] <geiseri_> ah, okay... i apologize i am still a bit fuzzzy on some of the parts so i am guessing
[16:43] <geiseri_> cjwatson: im going to try the install run again with those changes...
[16:44] <geiseri_> cjwatson: im assuming a single syntax error can cause the entire thing to abort?
[16:44] <cjwatson> I'm happy to look at the syslog before that
[16:44] <cjwatson> and it would probably be better if I looked at the syslog before that, since it may be none of these things
[16:44] <cjwatson> it's possible
[16:44] <cjwatson> error reporting isn't always quite brilliant, as you're discovering
[16:44] <geiseri_> well syslog said nothing but starting partitioner
[16:44] <geiseri_> is there a way to crank up the debug level?
[16:44] <cjwatson> DEBCONF_DEBUG=developer can help
[16:45] <cjwatson> as a boot parameter
[16:45] <geiseri_> ah, okay
[16:45]  * geiseri_ tries that too
[16:45] <cjwatson> don't expect to be able to read it yourself though; it's best to pass the result to an installer developer
[16:45] <geiseri_> :D with pleasure
[16:45] <cjwatson> definitely needs to be read in conjunction with the code
[16:46] <geiseri_> cjwatson: okay its booting up in qemu now, should have a syslog here in a minute or two...
[16:46] <geiseri_> cjwatson: qemu is not a speed demon here
[16:48] <ogra> The following packages have unmet dependencies:
[16:48] <ogra>   udev: Breaks: dmsetup (<= 2:1.02.27-4ubuntu5) but 2:1.02.27-4ubuntu5 is installed
[16:48] <ogra> E: Unmet dependencies. Try using -f.
[16:48]  * ogra grumbles at Keybuk 
[16:48] <kees> pitti: oh, btw, can I hand the sudo merge over to you?  I touched it late in the cycle, but am not too familiar with the standard ubuntu changes.
[16:49] <pitti> kees: okay
[16:52] <geiseri_> cjwatson: okay i am back at the error point.... what might be the best way to get the syslog off of here?
[16:53] <pitti> kees: in exchange for sudo, would you mind looking at devicekit-power as well?
[16:53] <kees> pitti: already done (and approved)  :)  (so, yes)
[16:54]  * pitti hugs kees, thanks
[16:54] <kees> :):)
[16:54] <geiseri_> cjwatson: im doing something wrong here because its not even touching the partition table...
[16:55] <ikonia> would it be appropriate to ask about the setup for how ssh/ssh-agent is intergrated into gnome for ubuntu, I can't find anything design related to it and I think there may have been a change between 8.10 and 9.04 ?
[16:56] <pitti> kees: what would chroot()ing gain? just robustness against stupid programming errors?
[16:57] <kees> pitti: yeah.  just random thoughts.
[16:57] <kees> pitti: if it's easy to do, it's an easy benefit.  if it's not easy, ignore the idea.
[16:57] <Keybuk> ogra: ?
[16:57] <Keybuk> you're grumbling at me for saving your system from not booting?
[16:58] <ogra> Keybuk, i dont care ... my livefs build chokes on it now
[16:58] <ogra> (on armel)
[17:00] <geiseri_> cjwatson: okay this i _think_ is the problem:  GETAGET full-disk description \n 10 full-disk doesn't exist... full-disk is the entry i put in my script
[17:01] <geiseri_> could it be that i am still missing some information to cause it to use my recipe?
[17:05] <maxb> byobu!?
[17:06] <maxb> That seems possibly more weird than alsdorf!
[17:06] <mterry> asac: woah!  To leave comments in m-o-m, you just enter text in an invisible text box in the comment column, press enter, and it updates.  Neat.
[17:06] <ogra> whats wrong with alsdorf ? its an existing german village :)
[17:06] <asac> mterry: omg
[17:07] <mterry> Fancy
[17:07] <maxb> Renaming screen-profiles to byobu seems a bit incongruous considering alsdorf got renamed to notify-osd :-)
[17:08] <ogra> well, you surely avoid naming conflicts :)
[17:09] <ScottK> Between byobu and ayatana, there may well be a random word generator involved.
[17:09] <maxb> Feels that way :-)
[17:10] <maxb> Perhaps they're naming projects using pwgen :-)
[17:10] <pitti> ScottK: or Mark learning Japanese
[17:10] <ScottK> Could be.
[17:13] <mterry> asac: Added comment in wiki (UbuntuDevelopment/Merging) about it; it's useful but not discoverable
[17:17] <cjwatson> geiseri_: go back to the main menu and select "Save debug logs"
[17:17] <cjwatson> geiseri_: or, if you prefer, switch to tty2, 'anna-install openssh-client-udeb', and use scp
[17:18] <geiseri_> oh i like scp, let me try that
[17:21] <maco> pitti: gjiten doesnt recognize ayatana as a japanese word
[17:30] <geiseri_> cjwatson: May 11 16:21:30 debconf: --> SET partman-auto/disk      /dev/sda \n May 11 16:21:30 debconf: <-- 10 partman-auto/disk doesn't exist
[17:30] <geiseri_> this looks telling
[17:30] <geiseri_> but fdisk sees it as /dev/sda
[17:40] <cjwatson> geiseri_: I really can't deal with fragments of the syslog like this; I need the whole thing
[17:40] <cjwatson> geiseri_: I think it's likely that you're misreading normal behaviour
[17:41] <cjwatson> it's normal for questions not to exist when they're initially preseeded
[17:46] <geiseri_> cjwatson: okay, sorry, give me a minute, as rfab.net is choking on it....
[17:47] <cjwatson> geiseri_: paste.ubuntu.com?
[17:49] <geiseri_> ah, i was using the kde one
[17:54] <geiseri_> cjwatson: http://paste.ubuntu.com:80/169797/
[17:54] <geiseri_> cjwatson: that is the entire syslog
[18:07] <cjwatson> geiseri_: this syslog doesn't match the preseed file you gave me earlier; it says you set partman-auto/method to "manual" (which is wrong) instead of the correct "regular"
[18:12] <geiseri_> oh i used the wrong file... sorry :(  one sec
[18:13] <geiseri_> i have too many copies of these damn files rolling around
[18:40] <geiseri_> cjwatson: okay, here is the preseed code again (http://paste.ubuntu.com:80/169827/) if i run this it keeps creating a root partition but also a swap partition, that i dont want...
[18:40] <geiseri_> but other than that it keeps going correctly
[18:40] <cjwatson> geiseri_: can I have the syslog again?
[18:41] <cjwatson> (preferably with DEBCONF_DEBUG=developer if you have it)
[18:41] <geiseri_> okay, let me spin up the vm with that flag in the boot line...
[18:50] <geiseri_> cjwatson: here is the mess: http://paste.ubuntu.com:80/169834/ for the preseed file i posted.
[18:51] <geiseri_> cjwatson: its almost correct save for the problem that its adding swap when i dont want it too do so
[18:52] <cjwatson> "Expert recipe too large (523837440 > 2147); skipping"
[18:53] <cjwatson> so it isn't using your recipe because it declares that it needs 523 TB of disk space and you only have 2 GB
[18:53] <geiseri_> doh
[18:53]  * geiseri_ must have calculated the offset wrong...
[18:54] <cjwatson> geiseri_: remember that the first field is a minimum
[18:54] <cjwatson> surely you can just make it relatively small and let partman automatically grow it
[18:54] <cjwatson> and the sizes are in megabytes
[18:54] <geiseri_> okay, that makes a few things make sense :)
[18:54] <geiseri_> will it make sure its the size of the base install?
[18:55] <cjwatson> TheMuso: are you likely to have a brltty merge available soon? I ask because it's one of the packages that still require libicu38 rather than libicu40, and those two packages are each very big
[18:55] <geiseri_> my ideal is that it creates 1 partition the entire size of the disk...
[18:55] <cjwatson> geiseri_: no, but if you only have one partition in your recipe it will use the whole disk for it anyway
[18:55] <geiseri_> k
[18:55] <cjwatson> I don't think partman actually *can* leave free space right now :-) It'll give up if you try to force it to do so
[18:55] <cjwatson> (this is a bug ...)
[18:56] <geiseri_> okay, i can live with that constraint
[19:09] <geiseri_> cjwatson: okay that worked, but now it asks me if i want to keep going without swap space..... can i look in the syslog to see what d-i field that is?
[19:10] <geiseri_> afaik it should be partman-basicfilesystem/no_swap boolean true?
[19:12] <ion_> keybuk: libdbus-1-3 1.2.14-2ubuntu3 causes hal to hang on startup. I didn’t get around to testing whether other dbus programs have problems as well. Installing libdbus-1-3/jaunty made the system work again. Is this known, or should i investigate more and report at launchpad?
[19:15] <Keybuk> ion_: probably a bug ;)
[19:15] <ion_> No kidding :-)
[19:15]  * Keybuk has had it installed for ages without encountering it though
[19:16] <ion_> I guess i’ll investigate further.
[19:16] <Keybuk> almost certainly the timeout patches
[19:16] <Keybuk> dunno whether davidz has code in HAL to expect them that he hasn't tested
[19:17] <Keybuk> (using INT_MAX was his original idea)
[19:18] <Keybuk> indeed, I can see two instances of that in the source
[19:18] <Keybuk> so it's likely david has pre-empted a timeout-less D-Bus without testing ;)
[19:19] <Keybuk> ion_: I'd wager it's blocking inside hald_runner_run_sync() ?
[19:32] <geiseri_> cjwatson: sweet everything seems to be working now!
[19:32] <geiseri_> cjwatson: thanks a ton for your help
[19:47] <cjwatson> geiseri_: yes, partman-basicfilesystem/no_swap is correct. Glad it works for you now
[20:29] <Keybuk> ion_: can you think of an example of another HAL service?
[20:29] <ion_> keybuk: What do you mean?
[20:30] <Keybuk> ion_: other than HAL that is hanging?
[20:30] <ion_> keybuk: Ah. I didn’t get to investigating the issue yet. As soon as i do, i’ll try various dbus services.
[20:30] <Keybuk> HAL seems to get to the main loop for me
[20:31] <Keybuk> but then simply doesn't accept connections
[20:32] <Keybuk> empathy/telepathy seem to work
[20:34] <chrisccoulson> hey mbiebl - you there?
[20:40] <chrisccoulson> kees - good spot on the vala MIR - thanks
[20:40] <chrisccoulson> i just noticed from the latest build log that one of the tests does fail
[20:42] <kees> chrisccoulson: cool
[20:42] <chrisccoulson> i'll take a look at sorting that over the next few days. might need some help though, although i suppose i could start by looking at some other packages with test suites
[21:00] <calc> pitti: i have all of the packages except pentaho fixed and uploaded
[21:02] <hyperair> does anyone know why the kernel method of suspend/hibernate is preferred over uswsusp?
[21:03] <hyperair> it seems to me that the kernel method is considerably slower than uswsusp.
[21:11] <pace_t_zulu> I have a question regarding PPA in Launchpad... is this the right place to ask it?
[21:11] <maxb> pace_t_zulu: #launchpad or #ubuntu-motu
[21:17] <Keybuk> hyperair: probably because it works
[21:17] <hyperair> Keybuk: don't both "just work"?
[21:22] <DarkRavin> can anybody tell me why everytime i click on places and click on pictures and it opens my music player
[21:23] <seb128> because you associated the player with directories
[21:24] <DarkRavin> how do i fix it
[21:24] <seb128> what ubuntu version do you use?
[21:25] <DarkRavin> the new one i just upgraded but it started from the first time i installed 8.xx
[21:25] <Keybuk> ion_: I assume it was only libdbus that you needed to change?
[21:26] <ion_> keybuk: Yep
[21:29] <DarkRavin> where do i find nautilus properties
[21:39] <ubuntuwin> ciao raga
[21:39] <DarkRavin> why does my folders say root is owner
[21:39] <ubuntuwin> ciao DktrKranz
[21:39] <DarkRavin> it wont let me make changes because of it
[21:40] <ubuntuwin> come faccio a firmare un pacchetto generato con debuild -S -sa?
[21:41] <ubuntuwin> la firma l'ho creata con gpg
[21:41] <mbiebl> chrisccoulson: hi
[21:41] <Keybuk> ubuntuwin: you will be unlikely to get an answer here unless you ask the question in English, also note that this is not a support channel so you may wish to try #ubuntu or #ubuntu-it
[21:42] <mbiebl> chrisccoulson: you pinged an hour ago?
[21:42] <ubuntuwin> how can I sign a packet generated with 'debuild -S -sa'?
[21:42] <ubuntuwin> i've made a key with gpg
[21:42] <chrisccoulson> mbiebl - hi. i'm currently looking at packaging a snapshot of tracker from git master in karmic at the moment
[21:43] <mbiebl> oh, is master usable already?
[21:43] <chrisccoulson> they've changed the library versioning in 0.7.x, and i was just wondering if you plan to change some of the package names in debian when you do the 0.7.0 update
[21:43] <mbiebl> I tried a week ago, and it crashed immediately
[21:43] <Keybuk> ubuntuwin: "debsign"
[21:44] <chrisccoulson> i've been told master is sort of useable, but it doesn't matter too much at this stage. i'd like to try and get it in quite early, to avoid some of the issues we had with 0.6.9x (where we introduced it within the last few weeks of the jaunty cycle)
[21:44] <chrisccoulson> mbiebl - the libraries in tracker are now versioned similar to gtk
[21:44] <mbiebl> chrisccoulson: Yeah, I think of renaming the library packages to match the soname
[21:45] <chrisccoulson> i was going to rename libtracker-gtk0 to libtracker-gtk0.7-0
[21:45] <chrisccoulson> is that what you were thinking?
[21:46] <chrisccoulson> the library so files are now libtracker-gtk-0.7.so.0.0.0 as opposed to libtracker-gtk.so.0.0.0 i think
[21:46] <mbiebl> I would have used libtrackerclient-0.7-0 and libtracker-gtk-0.7-0, as that is the scheme we use in dbus(-glib)
[21:46] <mbiebl> but libtracker-gtk0.7-0 would be ok too.
[21:46] <chrisccoulson> mbiebl - that makes sense too
[21:47] <LLStarks> pitti. you here? hal is in real bad shape on karmic right now.
[21:47] <mbiebl> It's mostly a matter of personal preference
[21:47] <chrisccoulson> i only suggested libtracker-gtk0.7-0 as that is how the gtk packages are named
[21:47] <chrisccoulson> it's up to you then. i'd like to name them the way you intend to do it in debian
[21:48] <chrisccoulson> LLStarks - pitti is finished for the evening i think
[21:48] <chrisccoulson> what's wrong with hal?
[21:48] <mbiebl> I prefer the additional dash as, but have no strong opinion either way
[21:49] <LLStarks> prevents boots and hal initialization on karmic
[21:49] <LLStarks> with latest 2 updates
[21:49] <chrisccoulson> mbiebl - i can add the dash - that's no problem.
[21:49] <ion_> chrisccoulson: Install libdbus-1-3 from jaunty to get a working system while waiting for the fix.
[21:49] <LLStarks> it's a huge break
[21:49] <chrisccoulson> mbiebl - it won't get updated for another week or so as it is currently blocked on promoting another package in to main, but i'll use that time to get the package ready anyway
[21:50] <mbiebl> chrisccoulson: I'm wondering if we should also version the -dev packages.
[21:50] <chrisccoulson> i was going to do that in the same way - libtracker-gtk-0.7-dev i think
[21:50] <mbiebl> Apparently the API will be completely different, so packages will need sourceful changes.
[21:50] <mnemo> my karmic computer just broke as well.... hal failed to install and now it won't boot anymore... when I run "netroot" and try to reinstall hal it says it can find .../run/dbus/system_bus_socket something
[21:51] <mbiebl> chrisccoulson: yeah, sounds ok
[21:51] <Keybuk> mnemo: well, if you will run karmic
[21:51] <mnemo> yea I know its not a problem, I just wanted to let you know in case you want to block the update or so
[21:52] <ion_> llstarks, mnemo: See my previous message.
[21:52] <Keybuk> mnemo: it's karmic, we don't block updates there
[21:52] <mnemo> ah ok
[21:52] <mnemo> ion_: oh.. thanks
[21:52] <chrisccoulson> mbiebl - i'm not too worried about API change - there's currently no other packages in the archive that depend on the tracker libraries
[21:52]  * Keybuk has already tracked down the HAL bug
[21:52] <chrisccoulson> actually, totem-plugins depends on libtrackerclient
[21:53] <ion_> keybuk: Cool
[21:53] <Keybuk> just haven't figured out whether it's HAL misbehaving or D-Bus
[21:53] <mbiebl> chrisccoulson: don't you also build nautilus with tracker support on ubuntu?
[21:53] <Keybuk> HAL is asking for an infinite timeout, and the new D-Bus gives it that
[21:53] <chrisccoulson> i didn't even know there was a HAL bug. should i try and reboot to find out? ;)
[21:53] <LLStarks> ion thx
[21:53] <Keybuk> what I'm not sure about is why this method call never completes as a result
[21:53] <chrisccoulson> mbiebl - we disabled the tracker support in nautilus
[21:54] <Keybuk> iz probably bug
[21:54] <mnemo> seems libdbus-1-3 was already installed on my system and install hal still wont work.. anyone got any other ideas for working around it?
[21:54] <LordKow> yay thank you libvolumeid is gone forever
[21:54] <chrisccoulson> users expect the nautilus search to just look at filenames, and the tracker results confused a lot of users
[21:55] <Keybuk> mnemo: you need the libdbus-1-3 from jaunty, not from karmic
[21:55] <Keybuk> LordKow: well....  kiiiinda
[21:55] <mnemo> ah ok
[21:55] <Keybuk> LordKow: libblkid now mostly consists of libvolume-id's old code
[21:55] <Keybuk> LordKow: so it's not so much dead as moved into a different body
[21:56] <mbiebl> chrisccoulson: I've played around with tracker 0.7 some time ago
[21:56] <mbiebl> Maybe you can use the debian/ I sent you as a starting point
[21:56] <Keybuk> mnemo: it's the -0ubuntu3 that seems to be specifically upsetting HAL
[21:56] <chrisccoulson> mbiebl - thanks. the transfer hasn't started yet though. not sure if that's an issue with my router or not
[21:56] <Keybuk> ironically this is because the HAL author wrote the code expecting the behaviour that the patches in D-Bus 0ubuntu3 finally, years later, provide
[21:57] <mbiebl> chrisccoulson: I'll send you an email...
[21:58] <chrisccoulson> mbiebl - thanks:)
[22:01] <mbiebl> chrisccoulson: stupid gmail. It rejects the tarball because it contains a executable (debian/rules)...
[22:01] <chrisccoulson> that's a pain. i didn't realise gmail was that clever
[22:01] <mbiebl> chrisccoulson: do you have another email addy?
[22:02] <chrisccoulson> i have my work e-mail address bug i'm pretty sure that will reject it too. the filters on that are failry strict
[22:03] <mbiebl> ok, I'll just chmod -x and retar it then
[22:03] <chrisccoulson> thanks:)
[22:03] <chrisccoulson> if it were a few weeks ago i'd still have a server here i could just let you ssh in to
[22:05] <lool> kees: How many rebuilds are there for FORTIFY?  I'm a bit worried that the buildds are already lagging and we need to build /something/ for A1  :)
[22:06] <mbiebl> chrisccoulson: email should be out
[22:06] <chrisccoulson> mbiebl - thanks. i'll take a look at that over the next day or so
[22:07] <kees> lool: it was just a short list.  I personally rebuilt them all in about 45 minutes.
[22:07] <lool> Ok, fine then
[22:07] <kees> lool: "zip" would mark the end of them.
[22:08] <kees> lool: though "zip" is not a no-change rebuild.
[22:08] <hyperair> does anyone know where i can find (if any) usplash api documentation? i'm referring to the C documentation, not usplash_write's interface.
[22:08] <maxb> Speaking of usplash, is it dying with a "general protection" message for anyone else on Karmic?
[22:08] <doko> kees: wow! xfonts-75dpi did gain fortify defaults!
[22:09] <lool> Yeah, the chars have a small square drawn around each glyph
[22:13] <Keybuk> ion_: basically it looks like the pending call for the pm-is-supported runner never "completes"
[22:15] <Keybuk> it doesn't help that whenever I compile this, the line numbers don't match up in gdb
[22:17] <kees> doko: yeah, my ELF-finder glitched on a few
[22:17] <ion_> keybuk: Heh
[22:18] <Keybuk> ion_: I'm going to assume there's a bug in D-Bus causing this
[22:18] <Keybuk> since HAL appears to be basically correct
[22:18] <Keybuk> it uses INT_MAX because it doesn't mind how long the runner takes
[22:18] <Keybuk> so in this case, INT_MAX should mean "forever"
[22:18] <Keybuk> and that's when it hangs
[22:22] <Keybuk> oh...
[22:22] <Keybuk> this may be one of those "the patch keybuk uploaded wasn't the patch keybuk tested" issues
[22:25] <Keybuk> yawp
[22:25] <Keybuk> the patch I put into the package is not the patch in git
[22:25] <Keybuk> and is not the one I've been testing for the best part of the year
[22:25] <Keybuk> la la la
[22:29] <seb128_> Keybuk: btw do you plan to ever review the patch on bug #258491?
[22:29] <seb128_> Keybuk: would be nice to get it off the sponsoring list either way, ie apply or unsubscribe the team and add a comment
[22:30] <Keybuk> it's a complex path
[22:30] <Keybuk> I've been on/off testing/reviewing it for ages
[22:30] <walters> Keybuk: you shipping the timeout stuff now?
[22:30] <Keybuk> walters: yes
[22:30] <Keybuk> walters: I was going to nag you about whether I could just commit to to trunk ;)
[22:32] <walters> Keybuk: i think it's probably right, rereading the thread again
[22:33] <Keybuk> walters: it's still the client's choice, after all - the default timeout is still low
[22:33] <walters> Keybuk: are there no changes since the patches attached in bugzilla?
[22:33] <Keybuk> you have to give very large numbers, or INT_MAX, as a timeout
[22:33] <Keybuk> walters: there's one change to the first one
[22:33] <walters> Keybuk: can you attach then and say what changed?
[22:33] <Keybuk> which ironically is the very bug hit today - I applied the patches from the ML not the patches that worked <g>
[22:34] <Keybuk> walters: which bug# was it?
[22:34] <walters> Keybuk: http://bugs.freedesktop.org/show_bug.cgi?id=16841
[22:34] <Keybuk> ah yes
[22:34] <Keybuk> I'll reattach the first one
[22:34] <walters> cool
[22:35] <walters> Keybuk: did you have any thoughts on testing?  we should have at least one test call where we pass INT_MAX, and maybe just timeout after 5 seconds or something for the test suite
[22:36] <walters> Keybuk: so there's at least some exercise of the code path
[22:37] <Keybuk> walters: that seems reasonable
[22:55] <dazjorz> So this is the place to talk about huge breakage in karmic if it's not already known?
[22:55] <dazjorz> :)
[22:55] <Keybuk> no
[22:55] <dazjorz> #ubuntu+1 doesn't seem like the place, too
[22:56] <dazjorz> or is it?
[22:56] <Keybuk> #ubuntu+1 may be appropriate
[22:56] <ienorand> dazjorz: it is, hal issues?
[22:56] <Keybuk> this is the place to talk about the patches you're writing to fix the huge breakage you found ;)
[22:56] <dazjorz> well
[22:56] <dazjorz> I don't have patches, but I do have solutions
[22:56] <dazjorz> does that do? :)
[22:56] <dazjorz> ienorand: not only that
[22:56] <Keybuk> it depends on your solution
[22:56] <dazjorz> also KDE package breakage
[22:57] <dazjorz> kde-icons-oxygen: trying to overwrite `/usr/share/icons/oxygen/16x16/status/meeting-organizer.png', which is also in package libkdepim4
[22:57] <Keybuk> if your solution is "zomg! karmic is broken! go back to jaunty versions" then no, that's not really helpful
[22:57] <Keybuk> dazjorz: file a bug?
[22:57] <dazjorz> only that one isn't that easy - earlier, kdelibs5 would conflict with libplasma-dev, uninstalling libplasma-dev fixed it, but kdelibs5 doesn't Conflict with libplasma-dev
[22:57] <dazjorz> I filed that, and a fix was committed; weird that the original maintainer didn't even know
[22:57] <Keybuk> not especially
[22:58] <Keybuk> our maintainers test things more often than not :p
[22:58] <dazjorz> Keybuk: don't worry, any solutions I will bring up won't be braindead
[22:58] <Riddell> "would conflict...doesn't conflict" I don't follow
[22:58] <dazjorz> conflict without a capital c: conflict in theory
[22:59] <dazjorz> Conflict with a capital c: have that package as a conflicting package in debian/contro
[22:59] <dazjorz> l
[22:59] <dazjorz> or, conflict in practice, actually
[22:59] <ion_> I’d call ubuntu-minimal’s postinst calling rm -fr / “huge breakage”. It’s a development version. A package here and another there is expected to break every once in a while. :-)
[22:59] <dazjorz> Keybuk: the thing about bugreporting things like kde-icons-oxygen conflicting with libkdepim4 is
[23:00] <dazjorz> Keybuk: it's so *obvious* the new package won't install, the maintainer *must* already know :/
[23:00] <dazjorz> so why bother to file a bug anyway
[23:01] <Keybuk> dazjorz: hah
[23:01] <Keybuk> the maintainer clearly doesn't know
[23:01] <Keybuk> otherwise they wouldn't have uploaded it in the first place
[23:02] <dazjorz> maybe it wasn't uploaded at the same time, or something
[23:02] <dazjorz> I mean
[23:02] <Keybuk> file a bug anyway
[23:02] <dazjorz> maybe it was uploaded, then the other package uploaded at the same time, causing both maintainers to think everything was OK, when in fact it wasn't
[23:02] <dazjorz> okay, will do
[23:02] <Keybuk> at the very least, it gives the QA team something to do
[23:03]  * dazjorz wonders why apport didn't pop up with "Package foo failed to install!" yet, usually it does that
[23:04] <dazjorz> https://bugs.launchpad.net/ubuntu/+source/oxygen-icons/+bug/374348
[23:04] <dazjorz> Yeah, yeah. The rest of KDE needs upgraded to KDE 4.3 beta. At this point bug reports would be counterproductive.
[23:05] <dazjorz> ooh, updating to 4.2.85, that makes sense, the 4.3 beta
[23:05] <Keybuk> well, it is karmic
[23:06] <dazjorz> yep - we just need to wait until the upload of kde 4.3 is done, I guess
[23:07] <TheMuso> cjwatson: oh right. I hadn't seen that pop up. I'll make it top priority for this morning.
[23:08] <dazjorz> [00000496] alsa audio output error: cannot write: Broken pipe    # another sign of the HAL problems, isn't it?
[23:09] <dazjorz> by the way: is there a way to get apt to completely ignore the current breakage of the system, and still do what I ask it to do? I read the manpage, tried some options, but it's still begging me to run -f
[23:11] <TheMuso> cjwatson: actually there is no merge available, but I can do a rebuild to use the newer library.
[23:29] <directhex> evand1, ping
[23:35] <cjwatson> TheMuso: oh, right, I misread rmadison's output or else I'd have just done a simple rebuild myself - sorry to bother you about that
[23:36] <TheMuso> cjwatson: np
[23:49] <dazjorz> Keybuk: is there a deb yet? :)
[23:49] <dazjorz> it's not on packages.ubuntu.com, anyway
[23:50] <ajmitch> packages.ubuntu.com is often a little out of date
[23:50] <Keybuk> no, and we can't stop for ice cream
[23:50] <dazjorz> any sources link ?
[23:51] <dazjorz> http://packages.ubuntu.com/source/karmic/dbus still shows -2ubuntu3, and modifying the download URL doesn't work, it doesn't seem to be on the mirrors yet
[23:51] <Keybuk> shees
[23:51] <Keybuk> do they not teach patience these days?
[23:52] <Keybuk> the upload process takes between one and three hours
[23:52] <Keybuk> after which sources, and if you're lucky, binaries will appear
[23:52] <Keybuk> after that, mirrors update whenever they feel like it
[23:52] <Keybuk> in practice, within an hour or so
[23:52] <dazjorz> I just figured if there was an URL to get the new .diff.gz and .dsc, you'd be the one to know
[23:52] <dazjorz> or, anyone else in this channel, for that matter
[23:53] <directhex> has someone done something funny with apache2 on lpia/armel? i got a ftbfs for mod-mono
[23:53] <cjwatson> if it's not on Launchpad then it isn't sufficiently published yet for there to be any such URL
[23:53] <Keybuk> /home/scott/work/drive-by/dbus_1.2.14-2ubuntu4.dsc
[23:53] <Keybuk> that's the URL I have ;)
[23:53]  * dazjorz ssh scott@that-machine
[23:53] <cjwatson> actually though you just aren't looking in the right places. start at https://launchpad.net/ubuntu/+source/dbus
[23:53] <ajmitch> Keybuk: fwiw, LP is showing build failures for -2ubuntu4 so far, failing to apply the patch
[23:53] <maxb> All of the buildds except lpia are a bit backlogged at the moment anyway
[23:53] <Keybuk> ajmitch: really?
[23:54] <Keybuk> that's vexing
[23:54] <dazjorz> cjwatson: right... thanks
[23:54] <directhex> Keybuk, computers are vexatious.
[23:54] <ajmitch> Keybuk: at least on lpia, i386 is still sitting on currently building
[23:54]  * dazjorz remembers that
[23:55] <Keybuk> typically it's the patch that adds the tests ;)
[23:55] <TheMuso> hrm i386 FTBFs as well.
[23:55] <dazjorz> patches fine here
[23:55] <Keybuk> hah
[23:56] <Keybuk> I bet it's complaining about .gitignore
[23:56] <cjwatson> looks like it
[23:56] <Keybuk> *sigh*
[23:56]  * TheMuso chuckles
[23:56] <Keybuk> my life would be so much easier if the bzr developers were killed in a freak unit testing accident