[00:03] TheMuso: no deadline now, the rest of the flavors are going out and we'll catch up mythbuntu once the SRUs are resolved [00:04] slangasek: Gotcha. [00:13] TheMuso: oh, wait; which SRU were we talking about? :) [00:13] oh, 221518 [00:13] slangasek: Sorry I was talking about the genpo SRU. [00:13] TheMuso: well, persia semi-verified it; if you can actually reproduce the original bug, with a test case, I would feel better about the fact that I just shoved it into -updates [00:13] slangasek: Although there was another one you mentioned yesterday against audacious that I have yet to test, as I have to set up a gutsy environment. [00:14] slangasek: Ok I'll look into doing that once I'm through my morning email run. [00:14] I did the audacious one myself [00:15] slangasek: Oh you took care of the audacious dist-upgrade bug. [00:15] yeah just saw that, and wrote my above comment after I switched back to IRC from reading bug mail. :) [00:18] :) [00:33] has there been any talk as to what version of xorg will ship with 8.10? [00:34] The new one [00:39] Awsoonn: 7.4 [00:39] xserver 1.5 [00:39] with xserver 1.5? [00:39] :) === slangasek changed the topic of #ubuntu-devel to: intrepid alpha-1 released, archive open | Ubuntu 8.04.1 released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [00:41] Awww. libdrm 2.3.1 doesn't seem to ship with the nouveau drm headers. [00:41] I see that intrepid is running almost the same version as Hardy, would it be useful to package up the RC of 7.4 so it's ready for alpha 2? [00:41] RAOF: should it? [00:41] slangasek: \o/ [00:41] RAOF: it's too old for nouveau anyway [00:42] Awsoonn: WIP [00:42] (see my post on planet) [00:42] WIP? [00:42] tjaalton: I haven't been following, but the drm snapshots I've been taking have been reporting themselves as version 2.3.1. [00:42] work-in-progress [00:42] I was just seeing whether it'd be nice and easy. [00:42] RAOF: they should be 2.4.0 [00:43] hah, nice and easy.. [00:43] right on, I'll find something else to hit with a rock then. :) [00:43] :P [00:43] Yeah. It was a pretty long shot :) [00:45] RAOF: we might get 2.4.0 if the stuff intel is working on (GEM) proves to be worth it [00:46] Gah. Memory managers. Why isn't there one already? [00:46] not just one, _TWO_ :) [00:46] That's what I mean. [00:46] heh [00:46] Two incomplete managers. [00:47] 1 + 1 ~= 2 [00:47] tjaalton: Did you mean ~1/2 + ~1/2 ~= 1? [00:47] tjaalton: FSVO 1 [00:48] ion_: heh [00:48] RAOF: yep, that's more accuraty [00:48] *te [00:48] ~= ≈ ≈ [00:49] ah the flashbacks of some math courses.. FSVO [00:49] *FSVO foo [00:49] * RAOF is a particular fan of "almost all". [00:49] Is there a “standard” Finnish equivalent for FSVO? [00:50] "pienillä arvoilla" [00:50] Alright [00:51] "pienillä n:n arvoilla" [00:51] Yeah [00:51] hmm, the warm smell of offtopic dung [00:52] (The S in FSVO typically means “some”, though.) [00:52] oh :) [00:52] I thought it was "small" [00:53] no cookie for me [01:10] slangasek: Ok, genpo's SRU has a rubber stamp now. :) [01:10] thanks :) [01:14] TheMuso: rock! [01:26] Now... To work out why there are broken deps for some packages in hary-proposed/updates. [01:54] im not sure how to query apt to figure this out: is wacom-tools installed by default, for say ubuntu-desktop? [01:57] pwnguin: doesn't seem so directly [01:58] not according to the seeds. [01:58] well thats clearly the challenge [01:58] ok [01:58] crimsun: would you need to germinate to really be sure? [01:58] or are the seeds enough [01:58] no, you can cheat and grep through http://people.ubuntu.com/~ubuntu-archive/seeds/ubuntu.hardy/ [01:59] heh [02:00] crimsun: but those aren't germinated, couldn't it be pulled in indirectly? [02:01] in a very, very, obscure universe, possibly. [02:01] I have a VM with a fresh install on it, give me a sec :) [02:01] wacom seems like an obscure place [02:02] Awsoonn: while you're there, see if xserver-xorg-input-wacom is also in [02:03] kk, I do know xauto config sets up wacom stuff by default... [02:03] that part i know [02:03] but its been ages since ive installed from scratch [02:05] xserver-xorg-input-wacom 1:0.7.9.8-0 [02:05] Can anybody on hardy confirm that python-all-dev is uninstallable? [02:06] negitive on wacom-tools though [02:06] interesting [02:07] i dont know how the installer is written -- is it possible it only installs some packages if the hardware is present? [02:11] I am under the impression that the only case that happens is through the Restricted Manager. But I would love to know for reals [02:14] Shouldn't you be able to tell by the Task field on the package? [02:15] if its empty? [02:16] well thanks for the info [02:17] pwnguin: If you apt-cache show another package that you know to be pulled in by a seed, and can see the Task field, but can't see it on package X, X probably isn't pulled in. [02:29] Bug 244110 [02:29] Launchpad bug 244110 in python2.5 "python2.5-dev cannot be installed" [Undecided,Incomplete] https://launchpad.net/bugs/244110 [03:08] i'm trying to mix some intrepid packages with hardy. i added APT::Default-Release "stable"; to apt.conf and added the main intrepid repo to my sources.list, then ran apt-get -t intrepid install hello, but it still grabs hello from hardy [03:09] if someone knows how to do this, i'd appreciate the tip. its too advanced for #ubuntu. [03:09] i followed the debian guide as much as possible http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html [03:11] aib: or #ubuntu+1? [03:11] thanks [03:56] hello, i am trying to port gdebi to Debian, I have problems with gdebi-kde [03:57] from kparts import konsoleParts,TerminalInterface [03:57] they cannot be imported [03:57] its python [03:57] python-kde3 is installed [04:19] EagleScreen: The konsolepart has been removed from python-kde3 [04:19] oh [04:20] when happened? [04:20] The latest upstream release, whatever it is .1. [04:20] It was incompatible with KDE4 [04:55] someone explain this [04:55] read(3, 0x8103564, 4096) = -1 EAGAIN (Resource temporarily unavailable) [04:55] Rhythmbox works after booting, but after a while even if I close/open it again, it does THAT when trying to play a file, in a constant loop, and doesn't play [04:56] and FREEZES and won't close (sigterm kills it) [04:58] what the hell? [04:59] it looks like 3 is closed, but there's a pipe(3,4) reading man page... [05:02] ok at the time of this anal behavior, it looks like connect(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 110) = 0 has not seen a close(3) [05:14] Welcome to Asshole Reactions 101 [05:15] Today we are discussing Pidgin, as a casualty of Malone #219848 [05:15] Launchpad bug 219848 in pulseaudio "rhythmbox freezes after playing for an hour or more and locks all sound until reboot" [Medium,New] https://launchpad.net/bugs/219848 [05:15] It seems killing pulseaudio causes Pidgin to have a VIOLENT reaction and consume RAM as fast as possible, possibly even rivaling do{malloc(4096);}while(1); [05:21] !ohmy [05:21] Please watch your language and topic to help keep this channel family friendly. === tkamppeter_ is now known as tkamppeter [07:05] Good morning [07:07] slangasek: congratulations for 8.04.1! [07:08] thanks - congrats to you as well, for surviving all the SRUs :) [07:09] Good morning pitti [07:09] hey geser [07:09] pitti: good morning! [07:20] good morning [07:23] Good morning dholbach [07:24] <\sh> hey geser, dholbach [07:24] hi geser, hi \sh, hi thekorn [07:25] dholbach: good morning! [07:25] hey dholbach [07:25] hi all [07:26] hi nxvl [07:26] <\sh> and yeah [07:26] <\sh> happy birthday 8.04.1 :) [07:59] G'morning [08:00] hi Iulian [08:00] Hello Daniel === thekorn_ is now known as thekorn [08:19] are 8.04 images still available? [08:20] 8.04 images have the ssl bug I believe; 8.04.1 is available now [08:21] lifeless: I know, but thought that for testing purposes the original images might be nice to have somewhere [08:22] tjaalton: I don't know for sure, sorry. [08:22] tjaalton, if you can't find them on mirrors, I have copies of some (ubuntu only, alternate/desktop/server, i386/amd64) [08:24] pitti: thats interesting. unless the conflicts/replaces have a glitch i dont see what one would need to --purge nss/nspr [08:24] s/what/why/ [08:25] asac: maybe missing epoch or so? [08:25] * asac looking [08:25] no epoch in nss :/ [08:25] pitti: the other idea is that firefox gave up on component registration when it found that it couldnt load all libs [08:26] if you purge nss, you will purge xulrunner ... and if you reinstall that you will force component registration [08:26] s/purge xul/remove/xuL/ [08:27] and component registration might have been what cured the previous "blacklisted" weave component [08:29] (one theory) [08:30] liw: no worries, I was just wondering if they were available. good to know where to find them ;) [08:30] How do "officially supported" packages work? Do they all go through Canonical, or is there a way to help the process? (Trying to figure out why Pidgin 2.4.3 still isn't released for Hardy.) [08:31] xnv: look up the SRU process (stable release updates) [08:34] xnv: why should 2.4.3 be uploaded to hardy? [08:36] seb128: Well, a fix for the ICQ problem should be uploaded. It appears a patched version of 2.4.1 is what is being proposed, which I'd also be happy with. [08:36] xnv: the ICQ fix has been backported indeed and moved to hardy-updates already [08:37] xnv: maybe you are using a mirror which is not lagging behind? [08:37] -not rather ;-) [08:38] seb128: Possibly. I'll try changing servers. [08:40] seb128: Tried 'Main Server' without luck. [08:41] xnv: maybe it's not published yet in -updates, it has just been moved this morning, hardy-proposed has it since yesterday [08:46] sorry, pidgin hardy-updates is delayed, due to the *$#($ hppa buildd not catching up [08:46] ETA 2 hours [08:46] xnv: ^ [08:48] pitti: Alright. Thanks for the info. [08:49] So the rule is you have to release for every supported architecture at once? [08:51] at the moment, anyway (due to a pretty harsh restriction in the package copy script) [09:08] is it agreed upon that the new xserver etc can be pushed in for alpha2 [09:08] ? [09:14] ogra: can you confirm bug 242379 please ;) [09:14] Launchpad bug 242379 in nss "constantly shows popups with certification errors on some pages" [High,Fix committed] https://launchpad.net/bugs/242379 [09:22] tjaalton: 8.04(.0) images are available from http://old-releases.ubuntu.com/releases/ [09:22] cjwatson: oh, thanks [09:23] (the HTML there is a bit wrong - I've corrected it on the master, may take a while to sync out though) [09:38] ArneGoet1e,pitti: have intrepid language packs only been partially uploaded or something? see the end of http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/ubuntu/latest/livecd-20080704-i386.out [09:38] (I've fixed the gparted thing there already) [09:39] cjwatson: there were tons of failed-to-uploads, and rejects, due to a soyuz bug [09:39] cprov: could you please do your magic "reprocess all f-t-u" again? [09:41] pitti: I've already re-procesed all binaries. [09:42] ArneGoet1e: hm, how did your langpack upload from yesterday go? === dholbach_ is now known as dholbach [09:42] cprov: when was that? [09:42] cjwatson: yesterday evening [09:43] cprov: ok, there were still some failures then [09:43] cprov: e.g. /srv/launchpad.net/ubuntu-queue/failed/upload-20080703-100950-001203/language-pack-pt_8.10+20080527_source.changes hasn't been processed [09:43] cjwatson: did I miss anything ? I can only see libdrm from the 1st [09:43] cjwatson: that's source, I've only done binaries [09:44] and http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html shows a number of similar problems [09:44] cprov: ok, shall I reprocess those source failures then? [09:45] cprov: has the deadlock issue been fixed, or is it still likely to happen sometimes? [09:45] cjwatson: yes, the problem is fixed (or excluded, in fact) [09:46] pitti: I got a number of 'upload failures' back [09:46] ok, those need to be reprocessed as well, then === ArneGoet1e is now known as ArneGoetje [09:47] ok, I'll give it a go [09:55] ArneGoetje: should be reprocessing more happily now - I'll keep an eye on them and go round again if any fail [10:00] much better, all done [10:04] cjwatson: thanks :) [10:07] Riddell: can I remove kubuntu-kde4-meta from the archive now that kubuntu-meta is KDE4? [10:08] cjwatson: yes [10:08] Riddell: (then I can do NBS removals for the stuff only it depends on ...) [10:08] cool [10:09] cjwatson: oh, are you processing NBS? (I planned to do so today, too, as part of archive admin) [10:09] done [10:09] pitti: yeah, just trying to clean up a bit for alpha 2 [10:09] thanks [10:09] I'm just doing the ones with zero reverse deps [10:09] ok, good to know; I'll have a look at the nonzero ones then [10:09] (still processing NEW, though) [10:10] * Riddell sets kubuntu-kde4.intrepid to merged [10:10] I'm assuming that some of the non-zero ones will go to zero due to other NBS removals [10:10] pitti: you're using lp-remove-package for everything now, yes? [10:11] yes, I do [10:11] (just checking) [10:11] and AFAICS I changed all scripts and documentation to do so, too [10:11] cjwatson: ah: [10:11] $ remove-package.py [10:11] Use lp-remove-package.py, see https://wiki.ubuntu.com/ArchiveAdministration [10:11] right, we did that some months ago, as a reminder :) [10:11] oh good :) === mdz_ is now known as mdz [10:14] Riddell: out of interest, how does dbus-1-qt3 (in source NEW) differ from dbus-qt3? [10:15] pitti: different implementation. dbus-1-qt3 is a backport of the qt4 bindings [10:15] Riddell: (dbus-qt3 is in main, too) [10:15] pitti: hopefully dbus-1-qt3 won't have to go to main, it's needed for knetworkmanager 0.7 but hopefully there will be a kde 4 version of knetworkmanager soon [10:27] is some other archive admin doing syncs but not closing bugs (and so presumably not using syncbugbot)? see 244955 and 244974 [10:27] bug #244955 [10:27] Launchpad bug 244955 in licq "Please sync licq 1.3.5-7 from Debian(Unstable)" [Undecided,Fix released] https://launchpad.net/bugs/244955 [10:27] bug #244974 [10:27] Launchpad bug 244974 in dlocate "Please sync dlocate 0.96.1 (universe) from Debian unstable (main). " [Undecided,Fix released] https://launchpad.net/bugs/244974 [10:28] not me [10:28] whoa. is it just me or did somebody do an autosync? [10:29] looking at the commands history it looks like some did one indeed [10:29] own up :) [10:32] Somebody did up to p* a couple of days ago. [10:32] I presume an 'oh crap' moment then ensued. [10:33] that can also happen because sync-source.py bails out completely on errors [10:33] so if something starting with 'p' failed to sync, and then the archive admin went for coffee and forgot ... [10:33] oh, argh, that was me [10:33] Ah. [10:33] darn, we are past DIF [10:33] we are indeed [10:33] * pitti fetches brown paperbag, sorry [10:33] Only just. [10:33] yes, fortunately not very far past [10:33] old habits die hard? :) [10:34] yeah, standard Friday routine... [10:34] ah, so that's why above bugs weren't covered by syncbugbot, since they already got autosynced [10:34] pitti, please use a cloth bag instead of a paper one, it's re-usable and thus more ecological [10:34] * pitti closes manually [10:34] * liw has several :) [10:36] liw: I believe you can reuse brown paperbags stuck over your head. [10:36] liw: Do cloth bags provide the same benefits of opacity and airflow restriction? I'd think most cloth bags wouldn't properly restrict oxygen flow. [10:37] Mithrandir, I find that they get all soggy and break from my tears [10:37] liw: you're supposed to hide, in it, not cry. [10:37] ok, sync bugs match reality again [10:37] persia: paper bags are too stiff to restrict oxygen flow properly. [10:38] liw: 57/73 indices from that mega-repository converted to the new index format [10:38] liw: 22GB repositories make baby jebus cry. [10:38] dpkg-gencontrol: erreur interne: The method merge_union() is only valid for Dpkg::Deps::Simple [10:39] Hmm [10:40] len(NEW) == 0 \o/ [10:40] Source too? [10:41] yes [10:41] WooHoo! [10:41] * seb128 hugs pitti [10:41] liw: ping [10:42] lifeless, pong [10:43] liw: do you still have that 8Gb server and that 22G repository ? [10:44] cjwatson: http://merges.ubuntu.com/libm/libmtp/REPORT popped up over the weekend (just uploaded to Debian recently); do you think we should do those kind of merges, or ignore them? [10:45] lifeless, I have the machine, but I don't seem to have the repo [10:45] liw: I'm upgrading the index to one that has an upper bound on memory use :) [10:47] 28609 robertc 18 0 2303m 1.9g 1416 R 0.0 96.7 9:46.52 python [10:47] lifeless, good, good -- will the new index code be in a bzr release soon? [10:47] liw: the machine is thrashing :( 2G ram [10:47] liw: hopefully yes. For now lp:~robertc/+junk/index2 [10:47] erm [10:47] bzr-index2 [10:48] lifeless, if I get some extra time, I'll try that out, but don't hold your breath [10:49] :) [10:49] I appreciate your torture [10:51] What is this enormously massive branch? [10:51] wgrant: Ubuntu [10:52] All one branch? [10:52] I keep forgetting whether it was Debian etch or Ubuntu hardy [10:52] Ooh dear. [10:52] one repository, but one branch per source package [10:52] Oh. [10:52] wgrant: I blogged it [10:52] it found some scaling considerations [10:52] lifeless, you might talk to james_w about large repositories [10:53] liw: well, I'll make this one work fast first. He should be doing separate ones per package for now :) [10:53] liw: will you be in London? [10:53] lifeless, I will [10:55] then we can hack [11:00] pitti: I have no strong feelings either way. We shouldn't waste time on a campaign to do them, but if somebody's bored and wants to then I don't object [11:03] cjwatson: same here; for this particular merge it's not really worth it, since the only Debian change is the adoption of half of our patch [11:09] tkamppeter: if you have a moment, could you take a look at http://bugs.debian.org/286127 ? I think the depends/recommends should be updated, and some packages might be obsolete due to the PPD-autogenerator in cups 1.3 [11:10] liw: http://advogato.org/person/robertc/diary/90.html [11:17] lifeless: Is the bzr branch format likely to stabilise at some point? [11:17] There seems to be a new one every couple of months. [11:17] Which is probably bad. [11:20] wgrant: ubuntu changes every few months [11:20] wgrant: thats probably bad [11:21] lifeless: Ubuntu is supported for bzr for between 18 and 60 months, but bzr format changes can make the distributed tools unsuitable for use. [11:21] persia: we maintain compatibilty with every format since 0.0.4 or so [11:22] persia: we can write back to 0.0.6 or so [11:22] lifeless: Forward compatibility? Old clients can access new trees? [11:22] persia: and users explicitly choose when to upgrade [11:22] persia: no, users can publish in arbitrarily old trees [11:22] Right. Users of older distributed clients can't participate with newer trees. [11:22] persia: also we provide builds for all the supports versions of Ubuntu, and other platforms via community members [11:23] persia: for some value of can't [11:23] lifeless: It's distro-attitude vs. upstream-attitude. I understand your motivations entirely, and am sympathetic. It would still be nice to have stability so that the distributed tools just worked. [11:23] persia: generally, they do just work [11:23] * pitti is using the etch backpor on his server happily [11:24] persia: when was the last time you had bzr's default format bite you with a contributor, or your bzr unable to read someone else's tree? [11:24] * persia notices the work "backport", remembers lots of comments about problems working with updated trees because some member of the development group felt like upgrading, and hopes that waiting another couple years will make it go away [11:24] mesa 7.1rc1 incoming [11:25] tjaalton: yay new crack! [11:25] persia: there are two dimensions on formats; one is a _real_ problem. Its called 'rich root' and its a one way trapdoor. [11:25] lifeless: I'm not really a bzr user, but I'll admit to not seeing many complaints in the past 6 months. [11:25] pitti: indeed :) [11:25] tjaalton: Then new X soon enough? [11:25] I'm currently dist-upgrading my laptop to intrepid, let's have a look at all the other intrepid crack :) [11:25] wgrant: I might upload xorg-server too, but all the drivers need a rebuild so it'll take a few days until things have settled down [11:25] persia: the second dimension is just disk encoding and is trivially exported to any other format that has teh same encoding, and we don't see problems with that. [11:25] lifeless: I suspect people won't use new formats because they know anybody running less than $LATEST_DEVELOPMENT_RELEASE won't be able to use their branches. [11:26] persia: we've been sitting on the rich root change for about 3 years now, because its a problem [11:26] pitti, I tried upgrading a hardy virtual machine to intrepid, now it doesn't boot [11:26] the other, we've changed the default from time to time with no problems - because we've thought about the toolchain, and the window between introducing and making default etc [11:26] pitti, I was too lazy to investigate, though [11:26] wgrant, lifeless: isn't that merely a problem of having the latest bzr on the server side? if you have new bzr and new branch format on the server, and old bzr on the client, the client should still be able to read/write through bzr+ssh:///, right? [11:27] wgrant: honestly, people use the the default format, which is not the newest format. Because they shouldn't need to know. [11:27] pitti: in principle but we're not there yet. [11:27] pitti: bzr+ssh itself is fairly new. [11:28] lifeless: seeing "we're not there yet" is hugely confidence inspiring :) [11:28] wgrant: compare with hg - has changed format as often as bzr, but with less doco and clarity, or svn which has _forced_ upgrades (svn 1.5 silently upgrades working trees to its new format) [11:28] persia: you need to disable all VFS methods to achieve the abstraction pitti is referring to. Thats not possible if you want to support _all_ bzr operations. [11:28] lifeless: Ah yes, but nobody uses Hg. [11:29] or git, which hasn't changed formats but has introduced features that cause older versions to barf [11:29] and SVN 1.5 isn't anywhere yet, so people won't have had time to be horrified and murder them. [11:29] (and not barf with a beautiful message either) [11:29] Nothing about git is beautiful. [11:30] whenever I use git, I am astonished at how much output it gives in normal use -- output that I then have to sift through to see if there's any problems reported [11:30] wgrant: so, your point then is 'it will be nice when the bzr folk can not think of anything to make better that involves disk or network formats' ? :) [11:31] lifeless: My original question was when that was likely to happen. [11:32] I guess when bzr manages every network operation in a single round-trip with 0% data redundancy :) [11:32] wgrant: ok, I may have jumped slightly because we do get critiqued about this, even though I think when one looks deep we're no worse than others and better than most about managing this. [11:32] lifeless: Sorry for any confusion: I meant "hugely confidence inspiring" seriously. [11:32] (and that I was happy as a result) [11:32] persia: oh, ok :) [11:33] lifeless: That it is a goal is a good thing, as with 5-year distro support, changing formats are unfortunate: in comparison to git, hg, svn, etc.: you're here to hear the complaints. [11:33] wgrant: anyhow, I'm pretty bad at predicting the future. All I can say right now is I have a long list of things that we know would be better; and another list of things in the R&D space I'd like to experiment with, and finally a list of user desired features. [11:37] lifeless: btw, are you already at a point where some operations actually start to become CPU-bound instead of I/O bound, i. e. the relative Python slowness starts to matter? [11:37] lifeless, my friend with the time machine tells me you'll be finished making bzr faster than git in 2009 [11:38] pitti: we're way past that [11:38] pitti: 60% of performance with the new index was in 'str.split' in python [11:39] wow [11:39] pitti: so I wrote a C parser [11:40] I had expected it to still be pretty much I/O and network bound [11:40] which is used if compiled otherwise you get python [11:40] network is a headache [11:40] and disk efficiency [11:40] also memory efficiency [11:48] mbiebl: there? === Zic is now known as Zic`Angine === Zic`Angine is now known as Zic [12:39] cjwatson, did you come around to drop hwdb-client from the archive ? i still get bugreports for it and whould like to close them (or point tem to hwtest where appropriate) [12:39] *them [12:39] I didn't, is there a bug report for it? [12:39] no, i'll write one [12:40] also, is there a bug on hwtest that it should conflicts/replaces hwdb-client, or something like that, to deal with upgrades? [12:42] What part of dbus am I missing if I get "Couldn't connect to system bus: Failed to connect to socket /tmp/gdm-new/var/run/dbus/system_dbus_socket: No such file or directory"? [12:42] hmm, i dont think so, and it doesnt, we just replaced the seed entry afaik, i'll check that with cr3 [12:43] MacSlow: running system daemon at that socket address [12:43] assumedly the dbus system daemon isn't actually under /tmp/gdm [12:43] DBUS_SYSTEM_BUS_ADDRESS=/var/run/dbus/system_bus_socket [12:43] ? [12:43] pitti, http://bugs.debian.org/286127 is stone-old it is from the time of CUP 1.1.x and the answers are from clean-up rounds when CUP 1.2.x was introduced. We are now at 1.3.x, and until FF for Intrepid 1.4.x is possible. [12:44] PPD auto-generation was introduced with CUPS 1.2.x. [12:44] tkamppeter: I am aware of that; I just think some parts of it are still relevant, so I'd like to check which dependencies/recommends should still be there, and which should go [12:45] ogra: done, thanks [12:45] You can for sure remove any Recommends or Suggests on foomatic-filters-ppds. This package is obsolete and probably already removed from Ubuntu. [12:45] pitti: on nss bug i'd suggest to flip back the tag to verification-needed and give a bit more infos what to test. [12:45] asac: works for me; can you do that, please? [12:45] pitti: sure. just wanted to let you know ;) [12:46] * pitti -> off to lunch [12:46] cjwatson, bug 245488 files accordingly [12:46] Launchpad bug 245488 in hwtest "please add proper replaces for hwdb-client to hwtest " [Undecided,New] https://launchpad.net/bugs/245488 [12:46] *filed [12:47] thanks [12:47] pitti, remove only foomatic-filters-ppds from Suggests, all the rest is OK in the cups package. [12:52] asac: where exactly was your nm 0.7 for intrepid supposed to be? [12:53] asac: the version in your ppa appears to be for hardy. [12:54] Hobbsee: my ppa is dead NM wise ;) [12:54] long live ~network-manager team [12:54] Hobbsee: http://launchpad.net/~network-manager/+archive [12:55] Hobbsee: you have to edit the nm-dhcp-client.conf in /etc/db*/sys*/ and grant rights for "root" instead of "dhcp" [12:55] ahhhh [12:55] we found out that dhclient no longer runs as dhcp in intrepid ... thats why [12:55] useful [12:57] asac, isnt that a bug in dhclient ? [12:57] ogra: no we dropped a patch intentionally and are now back to upstream behaviour according to pitti [12:58] hmmm, for the daemon as well ? [12:58] pitti, ^^^ ? [12:58] * ogra wishes he could run intrepid :/ [12:58] ogra: why can't you? [12:58] pitti, SVN for Debian and Ubuntu updated. [12:59] Hobbsee, some project bounds keep me from it at least until the sprint [12:59] ogra: damn. [13:01] Anybody here who messes around with upstream gdm atm? [13:01] pitti, unping ... sorry for not reading the changelog first :) [13:02] MacSlow: what do you call messing around? [13:02]