[00:03] <slangasek> 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] <TheMuso> slangasek: Gotcha.
[00:13] <slangasek> TheMuso: oh, wait; which SRU were we talking about? :)
[00:13] <slangasek> oh, 221518
[00:13] <TheMuso> slangasek: Sorry I was talking about the genpo SRU.
[00:13] <slangasek> 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] <TheMuso> 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] <TheMuso> slangasek: Ok I'll look into doing that once I'm through my morning email run.
[00:14] <slangasek> I did the audacious one myself
[00:15] <TheMuso> slangasek: Oh you took care of the audacious dist-upgrade bug.
[00:15] <TheMuso> yeah just saw that, and wrote my above comment after I switched back to IRC from reading bug mail. :)
[00:18] <slangasek> :)
[00:33] <Awsoonn> has there been any talk as to what version of xorg will ship with 8.10?
[00:34] <cody-somerville> The new one
[00:39] <tjaalton> Awsoonn: 7.4
[00:39] <tjaalton> xserver 1.5
[00:39] <Awsoonn> with xserver 1.5?
[00:39] <Awsoonn> :)
[00:41] <RAOF> Awww.  libdrm 2.3.1 doesn't seem to ship with the nouveau drm headers.
[00:41] <Awsoonn> 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] <tjaalton> RAOF: should it?
[00:41] <LaserJock> slangasek: \o/
[00:41] <tjaalton> RAOF: it's too old for nouveau anyway
[00:42] <tjaalton> Awsoonn: WIP
[00:42] <tjaalton> (see my post on planet)
[00:42] <Awsoonn> WIP?
[00:42] <RAOF> 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] <tjaalton> work-in-progress
[00:42] <RAOF> I was just seeing whether it'd be nice and easy.
[00:42] <tjaalton> RAOF: they should be 2.4.0
[00:43] <tjaalton> hah, nice and easy..
[00:43] <Awsoonn> right on, I'll find something else to hit with a rock then. :)
[00:43] <tjaalton> :P
[00:43] <RAOF> Yeah.  It was a pretty long shot :)
[00:45] <tjaalton> RAOF: we might get 2.4.0 if the stuff intel is working on (GEM) proves to be worth it
[00:46] <RAOF> Gah.  Memory managers.  Why isn't there one already?
[00:46] <tjaalton> not just one, _TWO_ :)
[00:46] <RAOF> That's what I mean.
[00:46] <tjaalton> heh
[00:46] <RAOF> Two incomplete managers.
[00:47] <tjaalton> 1 + 1 ~= 2
[00:47] <RAOF> tjaalton: Did you mean ~1/2 + ~1/2 ~= 1?
[00:47] <ion_> tjaalton: FSVO 1
[00:48] <tjaalton> ion_: heh
[00:48] <tjaalton> RAOF: yep, that's more accuraty
[00:48] <tjaalton> *te
[00:48] <ion_> ~= ≈ ≈
[00:49] <tjaalton> ah the flashbacks of some math courses.. FSVO
[00:49] <tjaalton> *FSVO foo
[00:49]  * RAOF is a particular fan of "almost all".
[00:49] <ion_> Is there a “standard” Finnish equivalent for FSVO?
[00:50] <tjaalton> "pienillä arvoilla"
[00:50] <ion_> Alright
[00:51] <tjaalton> "pienillä n:n arvoilla"
[00:51] <ion_> Yeah
[00:51] <tjaalton> hmm, the warm smell of offtopic dung
[00:52] <ion_> (The S in FSVO typically means “some”, though.)
[00:52] <tjaalton> oh :)
[00:52] <tjaalton> I thought it was "small"
[00:53] <tjaalton> no cookie for me
[01:10] <TheMuso> slangasek: Ok, genpo's SRU has a rubber stamp now. :)
[01:10] <slangasek> thanks :)
[01:14] <LaserJock> TheMuso: rock!
[01:26] <TheMuso> Now... To work out why there are broken deps for some packages in hary-proposed/updates.
[01:54] <pwnguin> im not sure how to query apt to figure this out: is wacom-tools installed by default, for say ubuntu-desktop?
[01:57] <LaserJock> pwnguin: doesn't seem so directly
[01:58] <crimsun> not according to the seeds.
[01:58] <pwnguin> well thats clearly the challenge
[01:58] <pwnguin> ok
[01:58] <LaserJock> crimsun: would you need to germinate to really be sure?
[01:58] <LaserJock> or are the seeds enough
[01:58] <crimsun> no, you can cheat and grep through http://people.ubuntu.com/~ubuntu-archive/seeds/ubuntu.hardy/
[01:59] <pwnguin> heh
[02:00] <LaserJock> crimsun: but those aren't germinated, couldn't it be pulled in indirectly?
[02:01] <crimsun> in a very, very, obscure universe, possibly.
[02:01] <Awsoonn> I have a VM with a fresh install on it, give me a sec :)
[02:01] <pwnguin> wacom seems like an obscure place
[02:02] <pwnguin> Awsoonn: while you're there, see if xserver-xorg-input-wacom is also in
[02:03] <Awsoonn> kk, I do know xauto config sets up wacom stuff by default...
[02:03] <pwnguin> that part i know
[02:03] <pwnguin> but its been ages since ive installed from scratch
[02:05] <Awsoonn> xserver-xorg-input-wacom 1:0.7.9.8-0
[02:05] <TheMuso> Can anybody on hardy confirm that python-all-dev is uninstallable?
[02:06] <Awsoonn> negitive on  wacom-tools though
[02:06] <pwnguin> interesting
[02:07] <pwnguin> i dont know how the installer is written -- is it possible it only installs some packages if the hardware is present?
[02:11] <Awsoonn> 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] <wgrant> Shouldn't you be able to tell by the Task field on the package?
[02:15] <pwnguin> if its empty?
[02:16] <pwnguin> well thanks for the info
[02:17] <wgrant> 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] <TheMuso> Bug 244110
[03:08] <aib> 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] <aib> if someone knows how to do this, i'd appreciate the tip. its too advanced for #ubuntu.
[03:09] <aib> i followed the debian guide as much as possible http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html
[03:11] <Hobbsee> aib: or #ubuntu+1?
[03:11] <aib> thanks
[03:56] <EagleScreen> hello, i am trying to port gdebi to Debian, I have problems with gdebi-kde
[03:57] <EagleScreen> from kparts import konsoleParts,TerminalInterface
[03:57] <EagleScreen> they cannot be imported
[03:57] <EagleScreen> its python
[03:57] <EagleScreen> python-kde3 is installed
[04:19] <ScottK> EagleScreen: The konsolepart has been removed from python-kde3
[04:19] <EagleScreen> oh
[04:20] <EagleScreen> when happened?
[04:20] <ScottK> The latest upstream release, whatever it is .1.
[04:20] <ScottK> It was incompatible with KDE4
[04:55] <bluefoxicy> someone explain this
[04:55] <bluefoxicy> read(3, 0x8103564, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
[04:55] <bluefoxicy> 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] <bluefoxicy> and FREEZES and won't close (sigterm kills it)
[04:58] <bluefoxicy> what the hell?
[04:59] <bluefoxicy> it looks like 3 is closed, but there's a pipe(3,4) reading man page...
[05:02] <bluefoxicy> 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] <bluefoxicy> Welcome to Asshole Reactions 101
[05:15] <bluefoxicy> Today we are discussing Pidgin, as a casualty of Malone #219848
[05:15] <bluefoxicy> 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] <persia> !ohmy
[07:05] <pitti> Good morning
[07:07] <pitti> slangasek: congratulations for 8.04.1!
[07:08] <slangasek> thanks - congrats to you as well, for surviving all the SRUs :)
[07:09] <geser> Good morning pitti
[07:09] <pitti> hey geser
[07:09] <nxvl> pitti: good morning!
[07:20] <dholbach> good morning
[07:23] <geser> Good morning dholbach
[07:24] <\sh> hey geser, dholbach
[07:24] <dholbach> hi geser, hi \sh, hi thekorn
[07:25] <nxvl> dholbach: good morning!
[07:25] <thekorn> hey dholbach
[07:25] <thekorn> hi all
[07:26] <dholbach> hi nxvl
[07:26] <\sh> and yeah
[07:26] <\sh> happy birthday 8.04.1 :)
[07:59] <Iulian> G'morning
[08:00] <dholbach> hi Iulian
[08:00] <Iulian> Hello Daniel
[08:19] <tjaalton> are 8.04 images still available?
[08:20] <lifeless> 8.04 images have the ssl bug I believe; 8.04.1 is available now
[08:21] <tjaalton> lifeless: I know, but thought that for testing purposes the original images might be nice to have somewhere
[08:22] <lifeless> tjaalton: I don't know for sure, sorry.
[08:22] <liw> tjaalton, if you can't find them on mirrors, I have copies of some (ubuntu only, alternate/desktop/server, i386/amd64)
[08:24] <asac> pitti: thats interesting. unless the conflicts/replaces have a glitch i dont see what one would need to --purge nss/nspr
[08:24] <asac> s/what/why/
[08:25] <pitti> asac: maybe missing epoch or so?
[08:25]  * asac looking
[08:25] <asac> no epoch in nss :/
[08:25] <asac> pitti: the other idea is that firefox gave up on component registration when it found that it couldnt load all libs
[08:26] <asac> if you purge nss, you will purge xulrunner ... and if you reinstall that you will force component registration
[08:26] <asac> s/purge xul/remove/xuL/
[08:27] <asac> and component registration might have been what cured the previous "blacklisted" weave component
[08:29] <asac> (one theory)
[08:30] <tjaalton> liw: no worries, I was just wondering if they were available. good to know where to find them ;)
[08:30] <xnv> 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] <laga> xnv: look up the SRU process (stable release updates)
[08:34] <seb128> xnv: why should 2.4.3 be uploaded to hardy?
[08:36] <xnv> 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] <seb128> xnv: the ICQ fix has been backported indeed and moved to hardy-updates already
[08:37] <seb128> xnv: maybe you are using a mirror which is not lagging behind?
[08:37] <seb128> -not rather ;-)
[08:38] <xnv> seb128: Possibly. I'll try changing servers.
[08:40] <xnv> seb128: Tried 'Main Server' without luck.
[08:41] <seb128> xnv: maybe it's not published yet in -updates, it has just been moved this morning, hardy-proposed has it since yesterday
[08:46] <pitti> sorry, pidgin hardy-updates is delayed, due to the *$#($ hppa buildd not catching up
[08:46] <pitti> ETA 2 hours
[08:46] <pitti> xnv: ^
[08:48] <xnv> pitti: Alright. Thanks for the info.
[08:49] <xnv> So the rule is you have to release for every supported architecture at once?
[08:51] <pitti> at the moment, anyway (due to a pretty harsh restriction in the package copy script)
[09:08] <tjaalton> is it agreed upon that the new xserver etc can be pushed in for alpha2
[09:08] <tjaalton> ?
[09:14] <asac> ogra: can you confirm bug 242379 please ;)
[09:22] <cjwatson> tjaalton: 8.04(.0) images are available from http://old-releases.ubuntu.com/releases/
[09:22] <tjaalton> cjwatson: oh, thanks
[09:23] <cjwatson> (the HTML there is a bit wrong - I've corrected it on the master, may take a while to sync out though)
[09:38] <cjwatson> 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] <cjwatson> (I've fixed the gparted thing there already)
[09:39] <pitti> cjwatson: there were tons of failed-to-uploads, and rejects, due to a soyuz bug
[09:39] <pitti> cprov: could you please do your magic "reprocess all f-t-u" again?
[09:41] <cprov> pitti: I've already re-procesed all binaries.
[09:42] <pitti> ArneGoet1e: hm, how did your langpack upload from yesterday go?
[09:42] <cjwatson> cprov: when was that?
[09:42] <cprov> cjwatson: yesterday evening
[09:43] <cjwatson> cprov: ok, there were still some failures then
[09:43] <cjwatson> 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] <cprov> cjwatson: did I miss anything ? I can only see libdrm from the 1st
[09:43] <cprov> cjwatson: that's source, I've only done binaries
[09:44] <cjwatson> and http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html shows a number of similar problems
[09:44] <cjwatson> cprov: ok, shall I reprocess those source failures then?
[09:45] <cjwatson> cprov: has the deadlock issue been fixed, or is it still likely to happen sometimes?
[09:45] <cprov> cjwatson: yes, the problem is fixed (or excluded, in fact)
[09:46] <ArneGoet1e> pitti: I got a number of 'upload failures' back
[09:46] <pitti> ok, those need to be reprocessed as well, then
[09:47] <cjwatson> ok, I'll give it a go
[09:55] <cjwatson> ArneGoetje: should be reprocessing more happily now - I'll keep an eye on them and go round again if any fail
[10:00] <cjwatson> much better, all done
[10:04] <ArneGoetje> cjwatson: thanks :)
[10:07] <cjwatson> Riddell: can I remove kubuntu-kde4-meta from the archive now that kubuntu-meta is KDE4?
[10:08] <Riddell> cjwatson: yes
[10:08] <cjwatson> Riddell: (then I can do NBS removals for the stuff only it depends on ...)
[10:08] <cjwatson> cool
[10:09] <pitti> cjwatson: oh, are you processing NBS? (I planned to do so today, too, as part of archive admin)
[10:09] <cjwatson> done
[10:09] <cjwatson> pitti: yeah, just trying to clean up a bit for alpha 2
[10:09] <pitti> thanks
[10:09] <cjwatson> I'm just doing the ones with zero reverse deps
[10:09] <pitti> ok, good to know; I'll have a look at the nonzero ones then
[10:09] <pitti> (still processing NEW, though)
[10:10]  * Riddell sets kubuntu-kde4.intrepid to merged
[10:10] <cjwatson> I'm assuming that some of the non-zero ones will go to zero due to other NBS removals
[10:10] <cjwatson> pitti: you're using lp-remove-package for everything now, yes?
[10:11] <pitti> yes, I do
[10:11] <cjwatson> (just checking)
[10:11] <pitti> and AFAICS I changed all scripts and documentation to do so, too
[10:11] <pitti> cjwatson: ah:
[10:11] <pitti> $ remove-package.py
[10:11] <pitti> Use lp-remove-package.py, see https://wiki.ubuntu.com/ArchiveAdministration
[10:11] <pitti> right, we did that some months ago, as a reminder :)
[10:11] <cjwatson> oh good :)
[10:14] <pitti> Riddell: out of interest, how does dbus-1-qt3 (in source NEW) differ from dbus-qt3?
[10:15] <Riddell> pitti: different implementation.  dbus-1-qt3 is a backport of the qt4 bindings
[10:15] <pitti> Riddell: (dbus-qt3 is in main, too)
[10:15] <Riddell> 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] <cjwatson> is some other archive admin doing syncs but not closing bugs (and so presumably not using syncbugbot)? see 244955 and 244974
[10:27] <seb128> bug #244955
[10:27] <seb128> bug #244974
[10:28] <seb128> not me
[10:28] <cjwatson> whoa. is it just me or did somebody do an autosync?
[10:29] <seb128> looking at the commands history it looks like some did one indeed
[10:29] <cjwatson> own up :)
[10:32] <wgrant> Somebody did up to p* a couple of days ago.
[10:32] <wgrant> I presume an 'oh crap' moment then ensued.
[10:33] <cjwatson> that can also happen because sync-source.py bails out completely on errors
[10:33] <cjwatson> so if something starting with 'p' failed to sync, and then the archive admin went for coffee and forgot ...
[10:33] <pitti> oh, argh, that was me
[10:33] <wgrant> Ah.
[10:33] <pitti> darn, we are past DIF
[10:33] <cjwatson> we are indeed
[10:33]  * pitti fetches brown paperbag, sorry
[10:33] <wgrant> Only just.
[10:33] <cjwatson> yes, fortunately not very far past
[10:33] <cjwatson> old habits die hard? :)
[10:34] <pitti> yeah, standard Friday routine...
[10:34] <pitti> ah, so that's why above bugs weren't covered by syncbugbot, since they already got autosynced
[10:34] <liw> 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] <Mithrandir> liw: I believe you can reuse brown paperbags stuck over your head.
[10:36] <persia> 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] <liw> Mithrandir, I find that they get all soggy and break from my tears
[10:37] <Mithrandir> liw: you're supposed to hide, in it, not cry.
[10:37] <pitti> ok, sync bugs match reality again
[10:37] <Mithrandir> persia: paper bags are too stiff to restrict oxygen flow properly.
[10:38] <lifeless> liw: 57/73 indices from that mega-repository converted to the new index format
[10:38] <lifeless> liw: 22GB repositories make baby jebus cry.
[10:38] <lool> dpkg-gencontrol: erreur interne: The method merge_union() is only valid for Dpkg::Deps::Simple
[10:39] <lool> Hmm
[10:40] <pitti> len(NEW) == 0 \o/
[10:40] <persia> Source too?
[10:41] <pitti> yes
[10:41] <persia> WooHoo!
[10:41]  * seb128 hugs pitti
[10:41] <lifeless> liw: ping
[10:42] <liw> lifeless, pong
[10:43] <lifeless> liw: do you still have that 8Gb server and that 22G repository ?
[10:44] <pitti> 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] <liw> lifeless, I have the machine, but I don't seem to have the repo
[10:45] <lifeless> liw: I'm upgrading the index to one that has an upper bound on memory use :)
[10:47] <lifeless> 28609 robertc   18   0 2303m 1.9g 1416 R  0.0 96.7   9:46.52 python
[10:47] <liw> lifeless, good, good -- will the new index code be in a bzr release soon?
[10:47] <lifeless> liw: the machine is thrashing :( 2G ram
[10:47] <lifeless> liw: hopefully yes. For now lp:~robertc/+junk/index2
[10:47] <lifeless> erm
[10:47] <lifeless> bzr-index2
[10:48] <liw> lifeless, if I get some extra time, I'll try that out, but don't hold your breath
[10:49] <lifeless> :)
[10:49] <lifeless> I appreciate your torture
[10:51] <wgrant> What is this enormously massive branch?
[10:51] <lifeless> wgrant: Ubuntu
[10:52] <wgrant> All one branch?
[10:52] <liw> I keep forgetting whether it was Debian etch or Ubuntu hardy
[10:52] <wgrant> Ooh dear.
[10:52] <liw> one repository, but one branch per source package
[10:52] <wgrant> Oh.
[10:52] <lifeless> wgrant: I blogged it
[10:52] <lifeless> it found some scaling considerations
[10:52] <liw> lifeless, you might talk to james_w about large repositories
[10:53] <lifeless> liw: well, I'll make this one work fast first. He should be doing separate ones per package for now :)
[10:53] <lifeless> liw: will you be in London?
[10:53] <liw> lifeless, I will
[10:55] <lifeless> then we can hack
[11:00] <cjwatson> 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] <pitti> 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] <pitti> 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] <lifeless> liw: http://advogato.org/person/robertc/diary/90.html
[11:17] <wgrant> lifeless: Is the bzr branch format likely to stabilise at some point?
[11:17] <wgrant> There seems to be a new one every couple of months.
[11:17] <wgrant> Which is probably bad.
[11:20] <lifeless> wgrant: ubuntu changes every few months
[11:20] <lifeless> wgrant: thats probably bad
[11:21] <persia> 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] <lifeless> persia: we maintain compatibilty with every format since 0.0.4 or so
[11:22] <lifeless> persia: we can write back to 0.0.6 or so
[11:22] <persia> lifeless: Forward compatibility?  Old clients can access new trees?
[11:22] <lifeless> persia: and users explicitly choose when to upgrade
[11:22] <lifeless> persia: no, users can publish in arbitrarily old trees
[11:22] <persia> Right.  Users of older distributed clients can't participate with newer trees.
[11:22] <lifeless> persia: also we provide builds for all the supports versions of Ubuntu, and other platforms via community members
[11:23] <lifeless> persia: for some value of can't
[11:23] <persia> 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] <lifeless> persia: generally, they do just work
[11:23]  * pitti is using the etch backpor on his server happily
[11:24] <lifeless> 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] <tjaalton> mesa 7.1rc1 incoming
[11:25] <pitti> tjaalton: yay new crack!
[11:25] <lifeless> persia: there are two dimensions on formats; one is a _real_ problem. Its called 'rich root' and its a one way trapdoor.
[11:25] <persia> lifeless: I'm not really a bzr user, but I'll admit to not seeing many complaints in the past 6 months.
[11:25] <tjaalton> pitti: indeed :)
[11:25] <wgrant> tjaalton: Then new X soon enough?
[11:25] <pitti> I'm currently dist-upgrading my laptop to intrepid, let's have a look at all the other intrepid crack :)
[11:25] <tjaalton> 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] <lifeless> 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] <wgrant> 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] <lifeless> persia: we've been sitting on the rich root change for about 3 years now, because its a problem
[11:26] <liw> pitti, I tried upgrading a hardy virtual machine to intrepid, now it doesn't boot
[11:26] <lifeless> 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] <liw> pitti, I was too lazy to investigate, though
[11:26] <pitti> 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] <lifeless> wgrant: honestly, people use the the default format, which is not the newest format. Because they shouldn't need to know.
[11:27] <lifeless> pitti: in principle but we're not there yet.
[11:27] <wgrant> pitti: bzr+ssh itself is fairly new.
[11:28] <persia> lifeless: seeing "we're not there yet" is hugely confidence inspiring :)
[11:28] <lifeless> 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] <lifeless> 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] <wgrant> lifeless: Ah yes, but nobody uses Hg.
[11:29] <lifeless> or git, which hasn't changed formats but has introduced features that cause older versions to barf
[11:29] <wgrant> and SVN 1.5 isn't anywhere yet, so people won't have had time to be horrified and murder them.
[11:29] <lifeless> (and not barf with a beautiful message either)
[11:29] <wgrant> Nothing about git is beautiful.
[11:30] <liw> 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] <lifeless> 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] <wgrant> lifeless: My original question was when that was likely to happen.
[11:32] <pitti> I guess when bzr manages every network operation in a single round-trip with 0% data redundancy :)
[11:32] <lifeless> 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] <persia> lifeless: Sorry for any confusion: I meant "hugely confidence inspiring" seriously.
[11:32] <persia> (and that I was happy as a result)
[11:32] <lifeless> persia: oh, ok :)
[11:33] <persia> 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] <lifeless> 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] <pitti> 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] <liw> lifeless, my friend with the time machine tells me you'll be finished making bzr faster than git in 2009
[11:38] <lifeless> pitti: we're way past that
[11:38] <lifeless> pitti: 60% of performance with the new index was in 'str.split' in python
[11:39] <pitti> wow
[11:39] <lifeless> pitti: so I wrote a C parser
[11:40] <pitti> I had expected it to still be pretty much I/O and network bound
[11:40] <lifeless> which is used if compiled otherwise you get python
[11:40] <lifeless> network is a headache
[11:40] <lifeless> and disk efficiency
[11:40] <lifeless> also memory efficiency
[11:48] <asac> mbiebl: there?
[12:39] <ogra> 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] <ogra> *them
[12:39] <cjwatson> I didn't, is there a bug report for it?
[12:39] <ogra> no, i'll write one
[12:40] <cjwatson> also, is there a bug on hwtest that it should conflicts/replaces hwdb-client, or something like that, to deal with upgrades?
[12:42] <MacSlow> 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] <ogra> hmm, i dont think so, and it doesnt, we just replaced the seed entry afaik, i'll check that with cr3
[12:43] <Keybuk> MacSlow: running system daemon at that socket address
[12:43] <Keybuk> assumedly the dbus system daemon isn't actually under /tmp/gdm
[12:43] <Keybuk> DBUS_SYSTEM_BUS_ADDRESS=/var/run/dbus/system_bus_socket
[12:43] <Keybuk> ?
[12:43] <tkamppeter> 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] <tkamppeter> PPD auto-generation was introduced with CUPS 1.2.x.
[12:44] <pitti> 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] <cjwatson> ogra: done, thanks
[12:45] <tkamppeter> 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] <asac> 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] <pitti> asac: works for me; can you do that, please?
[12:45] <asac> pitti: sure. just wanted to let you know ;)
[12:46]  * pitti -> off to lunch
[12:46] <ogra> cjwatson, bug 245488 files accordingly
[12:46] <ogra> *filed
[12:47] <cjwatson> thanks
[12:47] <tkamppeter> pitti, remove only foomatic-filters-ppds from Suggests, all the rest is OK in the cups package.
[12:52] <Hobbsee> asac: where exactly was your nm 0.7 for intrepid supposed to be?
[12:53] <Hobbsee> asac: the version in your ppa appears to be for hardy.
[12:54] <asac> Hobbsee: my ppa is dead NM wise ;)
[12:54] <asac> long live ~network-manager team
[12:54] <asac> Hobbsee: http://launchpad.net/~network-manager/+archive
[12:55] <asac> Hobbsee: you have to edit the nm-dhcp-client.conf in /etc/db*/sys*/ and grant rights for "root" instead of "dhcp"
[12:55] <Hobbsee> ahhhh
[12:55] <asac> we found out that dhclient no longer runs as dhcp in intrepid ... thats why
[12:55] <Hobbsee> useful
[12:57] <ogra> asac, isnt that a bug in dhclient ?
[12:57] <asac> ogra: no we dropped a patch intentionally and are now back to upstream behaviour according to pitti
[12:58] <ogra> hmmm, for the daemon as well ?
[12:58] <ogra> pitti, ^^^ ?
[12:58]  * ogra wishes he could run intrepid :/
[12:58] <Hobbsee> ogra: why can't you?
[12:58] <tkamppeter> pitti, SVN for Debian and Ubuntu updated.
[12:59] <ogra> Hobbsee, some project bounds keep me from it at least until the sprint
[12:59] <Hobbsee> ogra: damn.
[13:01] <MacSlow> Anybody here who messes around with upstream gdm atm?
[13:01] <ogra> pitti, unping ... sorry for not reading the changelog first :)
[13:02] <seb128> MacSlow: what do you call messing around?
[13:02] <MacSlow> seb128, grabbing it from svn, compiling, installing, running it
[13:02] <seb128> I doubt anybody is doing that on this chan
[13:02] <tjaalton> umm, could an archive admin promote x11proto-dri2-dev to main?-)
[13:02] <seb128> maybe pedro_ is using jhbuild but that's about it
[13:03] <MacSlow> seb128, last week I got it working... since yesterday it refuses to start... issues with dbus
[13:03] <MacSlow> seb128, ok
[13:03] <seb128> MacSlow: what issue?
[13:03] <seb128> tjaalton: do you have a mir for this one?
[13:04] <tjaalton> seb128: no.. I noticed that mesa is waiting for it
[13:04] <MacSlow> seb128, it cannot connect to the system bus
[13:04] <cjwatson> I think I'd regard x11proto-* as trivial
[13:04] <tjaalton> cjwatson: right..
[13:04] <tjaalton> it's just protocol headers
[13:05] <cjwatson> promoted
[13:05] <tjaalton> cool, thanks
[13:09] <MacSlow> seb128, the gdm-binary cannot find  /tmp/gdm-new/var/run/dbus/system_bus_socket and I thought I could make it use the system-wide /var/run/dbus/system_bus_socket
[13:10] <seb128> right, maybe a configure option or something?
[13:10] <MacSlow> seb128, I've not changed those since last week... that's why I don't get it that it does not work anymore
[13:10] <seb128> maybe an upstream bug
[13:11] <MacSlow> *shrugg*
[13:13] <Hobbsee> !ping
[13:13] <seb128> MacSlow: you can try asking on #gdm on gimpnet
[13:14] <seb128> hey Hobbsee
[13:14] <MacSlow> seb128, of course I'm trying that first all the time... but there's hardly traffic... only yesterday I got Ray there
[13:17] <Hobbsee> hey seb128, how's it going?
[13:17] <Hobbsee> oh, interesting, that did go through.
[13:18] <seb128> Hobbsee: good, thanks, what about you?
[13:18] <Hobbsee> seb128: fighting with network mangler, but otherwise good
[13:19] <Hobbsee> it likes my wired, hates my wireless...
[13:26] <Hobbsee> !ping
[13:26] <Hobbsee> !ping
[13:27]  * Mithrandir tickles the little green alien
[13:28]  * Hobbsee stomps on Mithrandir's feet, before he can levitate
[13:28] <Mithrandir> good thing they were already on my desk then
[13:28]  * Hobbsee can jump onto desks, stages, and other objects.
[13:29]  * Mithrandir watches Hobbsee trip over the USB-powered greenhouse
[13:35] <chmj> oin #ubuntu-za
[13:35]  * chmj #$$%#%@ keyboard 
[13:57] <pitti> tkamppeter: ok, thanks for checking
[13:57] <pitti> tkamppeter: there is no svn for ubuntu any more, we are in sync
[13:57] <pitti> tkamppeter: but thanks
[13:57] <pitti> ogra: :)
[13:59] <pitti> *grumble* after intrepid upgrade, my laptop's X.org is broken
[13:59] <pitti> Keybuk: ^ did you have that as well? I just get a black screen
[14:01] <liw> pitti, but at least it boots
[14:01] <Keybuk> yup
[14:01] <pitti> yes, it does, and I can ssh in
[14:01] <Keybuk> I've been complaining about it to the silent gallery for about two to three weeks
[14:01] <pitti> and numlock etc. work, ctrl+alt+del too
[14:01] <Keybuk> pitti: disable usplash
[14:01] <pitti> I just wanted to make sure not to start debugging from zero if it's already known
[14:02] <Keybuk> I haven't had time to find out why
[14:02] <pitti> even restarting gdm doesn't help
[14:02] <Keybuk> but it's something to do with usplash, since if you leave "splash" off, it works just fine
[14:02] <seb128> pitti: try disabling compiz?
[14:02] <Keybuk> seb128: is a fundamental X problem
[14:02] <pitti> seb128: gdm doesn't come up at all, nor a simple "X"
[14:02] <seb128> alright
[14:02]  * pitti tries with the hardy kernel, and then intrepid without usplash
[14:03] <Keybuk> pitti: does your suspend/resume break too?
[14:03] <Keybuk> or haven't you got that far yet? :p
[14:03] <pitti> Keybuk: the latter
[14:03] <pitti> it was the first virgin boot of intrepid on my laptop
[14:03] <pitti> my desktop is still hardy
[14:04] <pitti> ah, so intrepid with hardy kernel -> usplash and X work
[14:04] <Mithrandir> and hardy usplesh, I suspect?
[14:04] <Hobbsee> pitti: ahcompletely black screen when usplash finishes, or?
[14:04] <pitti> Mithrandir: everything else is intrepid
[14:04] <pitti> Mithrandir: well, except hte initramfs, of course
[14:04] <pitti> Hobbsee: 'zactly
[14:05] <Hobbsee> pitti: ah yes.  i noticed that when i just rebooted, and thought that was odd.
[14:05] <Hobbsee> hadn't seen that happen before
[14:05] <pitti> ugh, WTH?
[14:05] <pitti> screen colors are completely messed up
[14:06] <pitti> the background is ok, but panel and windows are utterly dark
[14:06] <pitti> (still intrepid with hardy kernel)
[14:07] <pitti> oh, that's the new theme, and might actually be deliberate, I'm afraid
[14:07] <Hobbsee> pitti: ah, yes....
[14:07] <Hobbsee> pitti: it's lovely, isn't it?
[14:07] <pitti> well, the brown of active windows and the dark gray don't harmonize at all, but *shrug*
[14:08] <Hobbsee> so lovely that you
[14:08] <Hobbsee> 'll put on your release team hat, and say "no way"?  :P
[14:09] <norsetto> can't be worse than the elephant skin
[14:10] <tkamppeter> pitti, OK, then I know that I need to upload my contributions to the CUPS package only into trunk (pkg-cups/cupsys/trunk, or is there a new "cups" repo?) and you upload the new package into Debian and an automatic process passes it from Debian to Ubuntu?
[14:10] <pitti> argh, my ears explode
[14:10] <pitti> instead of the start up sound I hear something utterly sqeaking and hurting
[14:10] <pitti> tkamppeter: no, trunk is fine
[14:10] <tkamppeter> pitt, ears? You use a screen reader now where your X does not work?
[14:10] <pitti> tkamppeter: exactly, I just sync it over
[14:11] <pitti> tkamppeter: startup sound
[14:11] <norsetto> thats an ibex in heat ...
[14:11] <Mithrandir> pitti: it's the sound of intrepids in the morning.
[14:11] <pitti> no, X works again with disabling usplash
[14:11] <Mithrandir> well, ibices in the morning
[14:12] <Hobbsee> pitti: oh yeah.  tha'ts a known problem too - it's playing through your onboard pcspkr instead of your sound card.
[14:12] <sistpoty|work> tjaalton: btw. what are the plans in regards to x drivers, as I'm listed to merge xserver-xorg-video-nv... is it ok for me to go ahead, or should this be taken from somewhere else?
[14:13] <pitti> Keybuk: confirmed your suspend problem, too
[14:13] <wgrant> Somebody decided to turn pcspkr into an ALSA module :(
[14:13] <tkamppeter> pitti, if I see a package at Debian and I want to have it unchanged in Ubuntu, can I sync it over with some simple clicks with my core-dev access?
[14:13] <pitti> yeah, I noticed that in my vmware instance
[14:13] <pitti> tkamppeter: not yet, you need a sync bug for that
[14:13] <Hobbsee> tkamppeter: you can use his sync-source.py script
[14:14] <tkamppeter> pitti, Hobbsee, what is a sync bug? what is sync-source.py? Is there a doc page for that?
[14:14] <Hobbsee> tkamppeter: .....
[14:15]  * Hobbsee attempts to revise what she's about to say.
[14:15]  * Hobbsee attempts to find some better way of phrasing it, that will actually follow the code of conduct.  ish.
[14:16] <pitti> Hobbsee: I know that my script is a piece of crap, that's why it isn't documented :)
[14:16] <Hobbsee> pitti: no, not that.
[14:17] <Mithrandir> pitti: I think what Hobbsee is trying to phrase is something along the lines of "I think it's a problem that we have people in core-dev who does not appear to know what a sync is or how it is done".
[14:18] <Hobbsee> Mithrandir: it's bad enough that we have them in MOTU, let alone core dev.
[14:18]  * wgrant bows to Mithrandir.
[14:18] <Mithrandir> hiya wgrant, didn't recognize you with the new nick.
[14:18] <tkamppeter> I know what a sync is, but I have never made one, the packages I have produced had always some Ubuntu bits ...
[14:18] <sistpoty|work> tkamppeter: s.th. like bug #243774
[14:18] <wgrant> Mithrandir: That's what they all say.
[14:19] <sistpoty|work> tkamppeter: there was also a post to ubuntu-devel some longer time ago what info should be present in a sync request, but I can't find the post right now
[14:20] <Lrrr> There is a checksum error in the Gutsy archive.  Whom should I contact for that?
[14:20] <Hobbsee> Lrrr: which mirror?
[14:21] <Lrrr> Gulus.usherbrooke.ca, right now.  I can try another mirror but it's probably break again.  It's been like that for a few days now.
[14:21] <Hobbsee> Lrrr: try another mirror first, if that doesn't work either, then come back
[14:21] <Mithrandir> tkamppeter: part of knowing what it is is also to have performed it enough times that your spine knows how it's done.
[14:22] <Lrrr> Hobbsee: Do you suggest any mirror?
[14:22] <Hobbsee> Lrrr: archive.ubuntu.com ?
[14:23] <Lrrr> Okay.
[14:24] <Lrrr> Trying.
[14:24] <Hobbsee> tkamppeter: i think what's most disturbing about that request is that you're asking about where basic development documentation is.  I can understand the fact that you don't normally need to do sync requests.  But i'm absolutely stunned that you don't know where the pages about syncs and merges are, particularly as you have to do them every cycle, and you are a core developer, who is supposed to be able to know and follow ubuntu processes.
[14:25] <Hobbsee> s/be able to//
[14:25] <wgrant> I recall that when others have applied for core-dev in the past on the grounds of sponsorship being inefficient, they have been denied.
[14:25] <tkamppeter> Sorry, I found the page in the Wiki already. I have already merged a lot, most times when I change something in a package I look at merges.u.com and take in the Debian stuff.
[14:25] <Hobbsee> Even people who are in ubuntu-universe-contributors know this information - or can at least point to it.
[14:26] <Lrrr> Hobbsee: Same error when using archive.ubuntu.com.  I'm using reprepro but I can confirm the checksum error by manually.
[14:26] <wgrant> Lrrr: You can confirm it, or have confirmed it?
[14:26] <wgrant> Lrrr: If the latter, which package?
[14:26] <wgrant> I thought all of those got fixed before release.
[14:26] <wgrant> Or maybe that was for Hardy.
[14:27] <wgrant> Oh to have NMAFA running on Primary...
[14:28] <Lrrr> It's from a Release file.  Checksums for several (all?) Packages.gz in the Gutsy archive are apparently broken.
[14:28] <Lrrr> I did confirm it manually.
[14:28] <wgrant> That is very unlikely.
[14:28] <wgrant> That would break the world.
[14:28] <wgrant> Which pocket, or all?
[14:28] <Lrrr> Wrong checksum during receive of 'http://archive.ubuntu.com/ubuntu/dists/gutsy/main/binary-i386/Packages.gz':
[14:28] <Lrrr> sha256 expected: baa89858c7e545390273530ba63c61b94c2e09d38c28b0a0311bfa7bde396181, got: af96b1f3119c4ce4b0c6183750279bf7cbdfe62581289f03ad360787e79f968b
[14:30] <elmo> neat, that's actually true
[14:30] <wgrant> Ah, I've not seen things use the SHA256 before.
[14:30] <wgrant> There's a Soyuz bug on that.
[14:30] <wgrant> Filed a few days back.
[14:30] <elmo> wgrant: got a #?
[14:30] <wgrant> https://bugs.launchpad.net/bugs/243630
[14:31] <wgrant> Bug in python-apt, I guess.
[14:31] <Lrrr> reprepro, AFAIK, has no --dont-bugger-me switch.  That means I can't pull from the Gutsy archive at all.
[14:31] <elmo> it's still wrong, even in intrepid, that's pretty special
[14:31] <wgrant> You can't convince it to use the other hashes?
[14:32] <Lrrr> I doubt it.  Let me see.
[14:32] <wgrant> elmo: It's rather special indeed. No response from mvo yet, either...
[14:33] <cprov> elmo: it's broken since we've switched to python-apt SHA256 generation (it was mid feisty, IIRC)
[14:33] <elmo> cprov: yeah, but I thought drescher being on hardy would have fixed it
[14:33] <Lrrr> The man pages doesn't say anything about that.
[14:33] <elmo> (at least for intrepid Release files)
[14:33] <cprov> elmo:  apt_pkg still thinking it's correct in hardy, Crypto and sha256sum disagree
[14:34] <Lrrr> That bug is relatively recent in the case of Gutsy because my scripts were working just fine a few weeks ago.
[14:34] <cprov> elmo: yeah, but no .. the tests pasted in the bug where done in hardy (drescher, precisely)
[14:34] <mvo> wgrant: it got under in my bug list, its the kind of bug that I like to hear about on irc too
[14:34] <elmo> mmmmmmmveeeeeeeeeeeeeeeeeeoooooooooohhhh
[14:35] <wgrant> Lrrr: You didn't happen to upgrade to a newer reprepro recently, did you? Those files haven't changed in ages.
[14:35] <Lrrr> I'm running sid so yeah I probably upgraded reprepro recently.
[14:35] <Lrrr> Let me check
[14:36] <wgrant> elmo: Oh dear, I have been pronouncing it wrong all this time?
[14:36] <Lrrr> Yep.  +1 to wgrant.  SHA256 support is new since early june.
[14:36]  * Lrrr visits snapshot.debian.net
[14:37] <mvo> cprov: could you please run "apt_pkg.sha256sum(open("Packages.gz"))" (without the .read()) ?
[14:37] <mvo> cprov: that should fix it
[14:38] <liw> does anyone here happen to know of a (scriptable) command line client for gobby?
[14:38] <cprov> mvo: uhmm, let me try
[14:38]  * mvo just had a mild heart-attack hearing
[14:39] <alex-weej> pedro_: https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/93256
[14:39]  * mvo looks futher into the code
[14:40] <pedro_> alex-weej: i've tested it with several icon themes and don't get what you described
[14:41] <Lrrr> yay
[14:41]  * Lrrr updates his sub-distro.
[14:42] <alex-weej> pedro_: with GNOME, i get Internet -> Evolution Mail (mail icon) -- good
[14:42] <alex-weej> and Office -> Evolution Mail and Calendar (mail icon) -- bad * 2
[14:42] <alex-weej> firstly, it's not just mail and calendar, it's notes and contacts too
[14:42] <alex-weej> and secondly, the icon should be the evo icon
[14:42]  * pedro_ still wondering why we have evolution in 2 categories...
[14:42] <alex-weej> rather than just mail
[14:43] <cprov> mvo: yes, apt sha256 does match the world's value if I omit the read()
[14:43] <alex-weej> pedro_: because it's actually like 5 different applications
[14:43] <alex-weej> only one of which pertains to the "Internet"
[14:43] <pedro_> alex-weej: yeah kind of that..
[14:43] <alex-weej> pedro_: can you confirm you see the same as me?
[14:43] <pedro_> alex-weej: let me check
[14:44] <mvo> cprov: thanks for confirming, there is definitely a bug somewhere because the string stuff should work too
[14:45] <mdz> mvo: is it a known issue that the upgrader can pop up *very* many dialogs from a single package failure (for everything which depends on it)?
[14:45] <mdz> mvo: I am clicking through a very long list of such popups right now, upgrading to intrepid :-)
[14:46] <mvo> mdz: yes, funny that you ask, asac mentioned it today too and I just fixed those redunadant dialogs
[14:46] <tjaalton> sistpoty|work: wait until the new xorg-server is built, then you can upload a new merge
[14:46] <mdz> mvo: oh good
[14:46] <Mithrandir> mdz: "libc6"? :-)
[14:46] <mvo> lol
[14:46] <mdz> Mithrandir: findutils, which libc6 depends on
[14:46] <sistpoty|work> tjaalton: ok, will do (of course in case you want to take over again, I don't mind at all as well ;))
[14:46] <mdz> (!)
[14:46] <Mithrandir> mdz: good fun, then.
[14:46] <mdz> yes, this will take some time
[14:46] <mdz> *click* *click* *click*
[14:46] <cprov> mvo: okay, can we afford being wrong about SHA256 for sometime until you get the bug fixed on apt or should we change the publisher code to use the fd instead of the string ?
[14:47] <mvo> mdz: that depends got added to work around assert failure in xargs
[14:47] <mdz> findutils itself seems to have failed due to a Perl issue (via install-docs)
[14:47] <tjaalton> sistpoty|work: ok, we'll see :)
[14:47] <mdz> Can't locate Pod/Usage.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/sbin/install-docs line 18.
[14:47] <sistpoty|work> heh
[14:47] <mvo> cprov: I would say use the fd instead of the string, should be much more efficient anyway (or is there a risk here)?
[14:47] <mvo> mdz: oh, you got hit by the doc-base failure too (bug #243830)
[14:47] <mdz> bug 243830, yes
[14:48] <mdz> just found it myself
[14:48] <mdz> mvo: I should have run the upgrade in a sandbox so that I could verify the fix once it arrives ;-)
[14:48] <mvo> mdz: there is a spec called "upgrade-testing-in-a-sandbox" now .)
[14:49] <mdz> mvo: yes, I was referring to it
[14:49] <mvo> heh :)
[14:50] <mvo> pitti: what is the current policy for new main compoenents that come from debian? new doc-base needs a universe build-depends now. is that reviewed internally or can I help by writing a MIR ?
[14:50] <pedro_> alex-weej: right, i'll comment on the report
[14:51] <alex-weej> pedro_: i'm just looking at the upstream repo... "Evolution Mail and Calendar" is their only Desktop Entry
[14:51] <alex-weej> we're adding one explicitly for "Evolution Mail" i think
[14:52] <pedro_> alex-weej: yes trunk is using that (just see it), that's what i added on the comment also
[14:52] <alex-weej> ok
[15:05] <cprov> mvo: no risk, I can do that quickly them.
[15:05] <pitti> mvo: nothing is reviewed 'automatically', so we need at least a MIR bug
[15:06] <pitti> mvo: for trivial packages, a bug is enough (libperl*), for complex ones we need a wiki MIR
[15:07] <cprov> elmo: do you have any plan to regenerate the Release files for old series ? Can we do that without making people panic ?
[15:16] <mvo> cprov: I'm updating the report with my findings
[15:17] <cprov> mvo: thanks, dude.
[15:18] <pitti> tkamppeter: which part of the printer device ID do I need for the web query? just MFG and MDL, or other stuff as well? (certainly not DES and CLS, but I don't knwo what P, S, and SN are
[15:19] <pitti> tkamppeter: oh, it seems I can just submit the entire thing, and the sever just ignores unimportant bits
[15:20] <pitti> tkamppeter: is the order of the fields important? i. e. does it always have to be MFG;CLS;MDL, or can they come in arbitrary order?
[15:20] <tkamppeter> pitti, make and model are enough in most cases (if device ID is really standards-conforming). Some printers have no make and/or model tag, then you can use the description. CMD is only to find appropriate generic PPDs for a printer which is unknown to the database.
[15:20] <Hobbsee> mvo: why does apt still try to install recommends for a package, if you've held the package back (by dpkg --set-selections), and won't let it upgrade to the newer version?
[15:20] <pitti> tkamppeter: ah, thanks; I think I'll just submit everything cupshelper.getDevices() gives me
[15:21] <Hobbsee> (when running a dist-upgrade)
[15:21] <tkamppeter> P, S, and SN are not constant on different printers of the same model or even not constant during the printer's life (on HP they contain the ink levels). SDo they are not used.
[15:21] <pitti> tkamppeter: lpinfo -l -v still is a string, but cupshelpers dissects it into a dictionary, so the order of the fields is lost
[15:21] <pitti> tkamppeter: "SN" sounds like serial number
[15:22] <tkamppeter> pitti, the order of the field of a device ID string is not relevant. It is always dissected on the server and the server only uses MFG/MDL, DES, and CMD in the given priority order to find its answer.
[15:23] <pitti> tkamppeter: perfect; thanks!
[15:23] <tkamppeter> You ususally can send device IDs as they are to the server. The server dissects them by itself.
[15:24] <mvo> Hobbsee: that sounds like a bug
[15:24] <tkamppeter> pitti, serial number can appear under SN, SER, or SERIAL. It is used by CUPS and by system-config-printer to distinguish two printers of the same model connected to one machine, especially when using USB.
[15:24] <Hobbsee> mvo: http://rafb.net/p/S9g7K465.html
[15:25] <pitti> tkamppeter: so I'll filter out those three, I think; I don't want to send serial numbers over the net for privacy reasons
[15:25] <pitti> tkamppeter: or, rather, I'll only take MFG, MDL, DES, and CMD
[15:26] <tkamppeter> pitti, exactly that, only these four are needed to identify which model a printer is and which drivers it needs. All the others are irrelevant.
[15:27] <pitti> tkamppeter: so I rather don't send them in the first place; thanks!
[15:27] <tkamppeter> You do not need to filter them out, as my software drops them (and does not send them to an ink cartridge store)
[15:28] <pitti> tkamppeter: I still want to avoid sending serial numbers or other potentially personal data over the network
[15:28] <tkamppeter> pitti, but better filter them out, as sooner or later we get mirrors, or simply someone is listening to the connections passing through the net and then delivers the ink ...
[15:28] <pitti> lol
[15:28] <pitti> tkamppeter: jockey 0.6 feature, I'd say :-P
[15:29] <tkamppeter> pitti, when will 0.6 be released?
[15:29] <pitti> dunno, currently working on 0.5
[15:29] <pitti> plan is to get printer support ready, add some more required D-BUS interfaces for printer support, and release 0.5
[15:30] <pitti> I'll probably move PackageKit to 0.6
[15:35] <pitti> tkamppeter: oh, there was another thing I wanted to discuss with you, do you have a minute?
[15:37] <tkamppeter> pitti, yes
[15:54] <mathiaz> mvo: what do you think about bug 245493 ?
[15:55] <mathiaz> mvo: is there a warning message that is shown after the samba package is installed stating that the user has to log off and login ?
[15:55] <ScottK> pitti: I assume it was you that rejected the debian-maintainers keyring package from New.  I'd like to discuss it with you as I find the package useful.
[15:56] <pitti> ScottK: oh, I had assumed it was an accident from an autosync run, so I blacklisted it and rejected it from NEW, yes
[15:57] <pitti> ScottK: hm, but how is it relevant for Ubuntu? we won't even keep it up to date
[15:57] <ScottK> pitti: No, I filed a bug asking for it sync'ed.  I find it useful with who-uploads
[15:57] <pitti> ah, then someone synced it without NEWing
[15:57]  * mdz reboots into intrepid
[15:57] <ScottK> Yes.
[15:57] <pitti> mdz: good luck! did the same today, with mixed results
[15:57] <Hobbsee> pitti: did you sort your sound out?
[15:58] <pitti> Hobbsee: I blacklisted snd_pcsp, but I haven't rebooted yet
[15:58] <pitti> (I think that should do it)
[15:58] <Hobbsee> true
[15:58] <pitti> the entire idea of that module is an abdomination anyway, IMHO
[15:58] <pitti> it *cries* for trouble...
[15:58] <ScottK> pitti: I'd appreciate it if we could have the package. Yes, it will always lag/be incomplete, but that's better than nothing.
[15:58] <jordi> how does Ubuntu deal with ubuntu modifications that have a bigger version than Debian's next uploaded version?
[15:58] <pitti> ScottK: ok; as said, I wasn't aware that it was an explicit request
[15:58] <ScottK> jordi: It shouldn't happen.
[15:59] <jordi> ie, Debian current is 1.0-2, ubuntu uploads 1.0-3, Debian then uploads 1.0-2.1
[15:59] <jordi> ScottK: but it did
[15:59] <mdz> pitti: hmm, spoke too soon, clicking the panel button didn't do what I expected
[15:59] <jordi> MDZ
[15:59] <mdz> pitti: it seemed to grab keyboard and mouse, but didn't fade the screen, and I wasn't able to do anything for about 2 minutes
[15:59] <mdz> jordi!
[15:59] <pitti> jordi: then the one who uploaded 1.0-3 to Ubuntu should be ... taught not to
[15:59] <mdz> pitti: then finally the dialog came up, and I canceled it to try to see what happened
[15:59] <ScottK> jordi: Then that's a mistake.  In general Ubuntu should upload 1.0-2ubuntu1
[16:00] <ScottK> jordi: What package?
[16:00] <mdz> .xsession-errors is full, as always, so it's no help
[16:00] <jordi> pitti: but besudes that, how do we resolve this? It's clearly a mistake, yes
[16:00] <pitti> mdz: hm, I think it happened to me, too, but I can't remember any more what the reason was
[16:00] <jordi> tinyproxy in Debian is 1.6.3-2.1, Ubuntu has 1.6.3-3
[16:00] <mdz> pitti: any guesses where I could look to see what's wrong?
[16:00] <jordi> I'm about to upload 1.6.3-2.2
[16:00] <ScottK> jordi: All we can really do is merge the changes into a 1.6.3-3ubuntu1.
[16:00] <ScottK> Argh.
[16:00] <pitti> mdz: I'd check the following: lo interface present? ck-list-sessions has a session for you? session d-bus running?
[16:00] <mdz> mvo: I can't tell what happened to the upgrader
[16:01] <Hobbsee> bad zul.
[16:01] <mdz> mvo: it seems to have finished, but I don't remember seeing it prompt me to reboot or anything
[16:01] <pitti> mdz: oh, that happened after you upgraded to intrepid, and were about to reboot?
[16:01] <mdz> pitti: yes
[16:01] <jordi> Scottk, pitti: I guess I could bump to -3.2 and add a justification in the changelog?
[16:01] <pitti> hm, I did the same this morning, and it worked for me
[16:01] <pitti> jordi: in Debian you mean?
[16:01] <jordi> although this sucks
[16:01] <jordi> yes
[16:01] <mdz> pitti: I can't reproduce it; clicking the icon again brings up the dialog right away
[16:02] <mdz> pitti: but shouldn't the upgrader prompt me to reboot immediately anyway?
[16:02] <pitti> jordi: sure, possible, but I think we could just wait until Debian gets a non-NMU again, and in the meantime, do what ScottK said
[16:02] <mdz> ah, probably it didn't because the upgrade failed
[16:02] <mdz> but I don't remember dismissing it
[16:02] <pitti> mdz: that would probably be useful, similar to ubiquity
[16:02] <jordi> pitti: ok. That happened last in 2004 though, before the Oxford meeting. :)
[16:02] <mdz> pitti: I think it does already, if the upgrade succeeds
[16:02] <jordi> tinyproxy (1.6.3-2) unstable; urgency=low
[16:02] <pitti> mdz: mine succeeded, but I wasn't prompted either
[16:02] <ogra> mdz, the logout dialog you mean ? that asks g-p-m for ability to hibernate/suspend before it comes up ...
[16:02] <jordi>  -- Ed Boraas <ed@debian.org>  Wed, 11 Aug 2004 12:20:18 -0600
[16:03] <jordi> la la la
[16:03] <mdz> anyway, rebooting for real now
[16:03] <mdz> ogra: hmm, maybe something was wrong there.  but I can't reproduce anymore anyway
[16:04] <ScottK> jordi: -3.something would make our lives easier here, but I don't think it's justifiable from a Debian perspective.
[16:05] <jordi> ScottK: afaik there have been more than a few *epoch* bumps due to Ubuntu and Debian version desyncs.
[16:05] <jordi> X, maybe?
[16:05] <jordi> But I agree this is not good
[16:06] <ScottK> I'd suggest 3.0 if you're going to.
[16:06] <jordi> ScottK: this is https://launchpad.net/distros/debian/+source/tinyproxy/+bug/42598/ fwiw
[16:09] <ScottK> jordi: It'd certainly make our life easier if you uploaded a higher version.
[16:13] <ogra> hmm, mdz doesnt seem to come back ...
[16:13] <pitti> black X...
[16:25]  * stgraber just reinstalled his lappy with Intrepid. Only broken things: fglrx not appearing in jockey (had to install + patch + start dkms) and missing wireless firmwares
[16:32] <beDrung> \sh: have a look at bug 221205
[16:32] <\sh> bug #221205
[16:32] <\sh> hmm? no bot?
[16:33] <stgraber> just laggy
[16:35] <\sh> DktrKranz: ping same bug as above..please comment :)
[16:37] <DktrKranz> \sh: I have not way to test it right now, but it seems good. Does debdiff fix FTBFS on amd64?
[16:38] <DktrKranz> (anyway, it will require DebianMaintainerSpec adjustment too)
[16:39] <\sh> soundtouch_1.3.0-2.2ubuntu0.1_v2.debdiff fixes it (according to bedrung)
[16:40] <\sh> beDrung: please update the maintainer according to DebianMaintainerSpec and find another M-SRU member :)
[16:40] <mdz> I survived the upgrade, but only barely
[16:41] <DktrKranz> \sh: we just need one ACK, and you already gave one (or do we change policy and require two ACKs?)
[16:41] <\sh> DktrKranz: if we just need one then ok..I thought we are at two acks ... (4 eyes are better then 2 ;))
[16:43] <DktrKranz> \sh: sure, another review doesn't harm, but I think we are good with just only one ACK (given that we follow SRU verification)
[16:43] <dholbach> Global Bug Jam Preparation Session in #ubuntu-meeting in 16 minutes.
[16:44] <beDrung> DktrKranz: yes, it fixes FTBFS on amd64
[16:44] <DktrKranz> beDrung: is soundtouch fixed in intrepid?
[16:45] <beDrung> yes
[16:45] <pitti> mdz: welcome back; X broken for you as well with usplash?
[16:45] <DktrKranz> beDrung: good, I'll reflect it on bug status. thanks
[16:45] <mdz> pitti: X broke due to nvidia.ko being missing entirely from lrm
[16:45] <mdz> pitti: decided to test bullet-proof-x and encountered some problems there
[16:46] <pitti> ah, that's currently split out to separate packages, yes
[16:46] <mdz> pitti: also lrm-common is missing the tools (including lrm-manager)
[16:46] <mdz> pitti: split out to separate packages?
[16:46] <pitti> mdz: AFAIU Timo and Alberto, this is supposed to go away, since the modules will not be renamed any more
[16:47] <pitti> mdz: right
[16:47] <pitti> mdz: in fact, l-r-m will shrink to just a bunch of firmware files, AFAIUI
[16:48] <pitti> tseliot and tjaalton would know details
[16:49] <pitti> mdz: but the idea is to repackage them using DKMS, and each driver on its own, so that it becomes easier to maintain
[16:49] <mdz> pitti: but meanwhile, they're missing entirely?
[16:49] <pitti> as well as you don't need to install both
[16:49] <tseliot> mdz: even with lrm-common and the nvidia.ko file, the driver wouldn't work on Intrepid. It needs some patches
[16:49] <mdz> is this "envy-ng"?
[16:49] <pitti> mdz: I don't know TBH, I just updated to intrepid today as well, and only my laptop (which has intel)
[16:50] <mdz> tseliot: bug 243863 says that the current version ought to work with .26
[16:50] <pitti> tseliot: oh, it isn't compatible with 2.6.26 yet?
[16:50] <tseliot> pitti: it depends on which driver version we're talking about
[16:51] <pitti> tseliot: I wasn't aware that the current l-r-m already threw them out
[16:51] <tseliot> mdz: driver 169.12 doesn't work with 2.6.26
[16:51] <pitti> I thought intrepid still had the old -new, -legacy, -glx
[16:51] <tseliot> pitti: it has those packages
[16:51] <pitti> ah, that would be it then; so -legacy and -glx don't work?
[16:51] <pitti> but -new does?
[16:52] <tseliot> however the kernel modules are not included in the linux-restricted-modules
[16:52] <tseliot> and nvidia-glx-<version> doesn't work without its kernel module
[16:52] <tseliot> mdz, pitti: the new packages will be ready soon, I promise
[16:53] <mdz> tseliot: right, the bug says there is a new version from nvidia which supports .26
[16:53] <tseliot> mdz: 173.xx.xx does support kernel 2.6.26 and so does 177.xx
[16:54] <pitti> tseliot: is there any chance at all to make the odler versions work on .26?
[16:54] <tseliot> however they won't work without their respective kernel modules
[16:54] <pitti> (since the newer versions don't support older models)
[16:54] <tseliot> pitti: I'm writing the patches for them right now
[16:54] <pitti> tseliot: oh, wow; so that is in the sourceful bits
[16:55] <beDrung> \sh, DktrKranz: done
[16:55] <tseliot> pitti: yes, a few functions and variables have to be removed and/or replaced by others
[17:06] <cjwatson> any objection to me dropping hplip's recommends: hplip-gui to suggests?
[17:06] <cjwatson> possibly also hpijs-ppds though I'm not sure
[17:07] <mdz> pitti: something is still wrong with usplash on this machine, but it was having problems there before
[17:07] <mdz> cjwatson: none whatsoever
[17:07] <mdz> cjwatson: I had cause to look at it a few days ago and found it  wanting anyway
[17:07] <mdz> it didn't provide much beyond what system-config-printer gives us
[17:07]  * cjwatson is trying to get the list of extra packages pulled into the desktop by Recommends down to something manageable
[17:07] <mdz> cjwatson: I can't speak for hpijs-ppds; that sounds important
[17:07] <mdz> hpijs is the default driver for many printers
[17:08] <cjwatson> hplip (2.8.6-1ubuntu1) intrepid; urgency=low
[17:08] <cjwatson>   * Merge with Debian unstable. No remaining Ubuntu changes.
[17:08] <cjwatson>  -- Till Kamppeter <till.kamppeter@gmail.com>  Mon, 23 Jun 2008 16:37:02 +0200
[17:08] <cjwatson> blink
[17:08] <pitti> but if we haven't installed it by default so far, we can probably do without?
[17:08] <pitti> tkamppeter: ^ that's the point where you should request a sync (but I think I already told you about that one, right)
[17:09] <cjwatson> I'll just do hplip-gui for now; the other at least doesn't pull in a bazillion dependencies
[17:10] <cjwatson> BTW, I'm inventing even more seed syntax for the recommends-by-default thing
[17:11] <cjwatson> I've opted for 'feature follow-recommends' in the STRUCTURE file
[17:11] <cjwatson> 'feature' is followed by a space-separated list of flags
[17:11] <cjwatson> this is the easiest way to keep germinate doing the right thing for <= hardy
[17:16] <tkamppeter> hpijs-ppds is not needed. It is a bunch of ready-made PPDs which are for us generated by the hpijs.drv file coming with the HPIJS package and CUPS DDK.
[17:19] <cjwatson> so the Recommends should be removed altogether?
[17:19] <cjwatson> I mean, there's no point even suggesting it if it's not needed
[17:19] <tkamppeter> cjwatson, you are right.
[17:20] <cjwatson> ok, will do, thanks
[17:22] <cjwatson> file-roller Recommends: rpm. What do we think? Seems not entirely useless
[17:28] <mgross> I'm wondering how to test freedesktop.or Xserver bits on a ubuntu desktop system.  Are there any how to pages?
[17:30] <Riddell> mgross: run them?
[17:30] <pitti> cjwatson: hm, but 1.6 MB..
[17:30] <mgross> Riddell: yup, I can build them but I want to run them without poluting the base install
[17:31] <cjwatson> pitti: Size: 625388
[17:31] <pitti> cjwatson: librpm4 is 1 MB
[17:31] <pitti> I don't think we pull that in by default, do we?
[17:32] <seb128> mdz: if you got bug #126797 on upgrade that's a different case than the one described there because before you stated on the same bug that your issue was not after a package upgrade
[17:32] <seb128> hum, no mdz ;-)
[17:32] <cjwatson> pitti: oh, right
[17:32] <cjwatson> yeah
[17:33] <pitti> seb128: mdz has been intrepified
[17:33] <seb128> I'm pondering doing that to my laptop
[17:33] <cjwatson> mvo: friendly-recovery should recommend gettext-base rather than gettext, right? it's just for gettext.sh? (if so, I have that change in my working tree and can commit/upload)
[17:33] <mvo> mdz: upgrade-finished> yes, another problem, it does not have a "upgrade-finished" prompt when there are failure, fixed in my bzr tree now
[17:33] <cjwatson> oh, no, I can't, it's in ~mvo
[17:33] <mvo> cjwatson: yes, it just needs gettext.sh, thanks for noticing that
[17:33] <seb128> but I've still around 20 hardy updates waiting for approval and I would prefer to still run hardy when those are accepted
[17:33] <cjwatson> mvo: will leave it to you then
[17:33] <seb128> mvo: ENOMDZ
[17:33] <mvo> cjwatson: feel free to push it to ~ubuntu-core-dev
[17:34] <mvo> seb128: heh :) thanks
[17:34] <seb128> ;-)
[17:34] <mvo> cjwatson: ok, I will take care of it
[17:34] <mvo> cjwatson: and push it to ~core-dev
[17:34] <pitti> mvo: you can change the team in the branch details
[17:34] <cjwatson> oh, ok, I was about to :-) but go for it
[17:35] <mvo> mathiaz: note to logout/login is possible with debconf for the upgrade hooks
[17:35] <mvo> pitti: oh, nice
[17:36] <pitti> mvo: I keep mixing up registrant and author (it's not obvious which is which), but one works
[17:36] <mvo> pitti: nice feature, I was not aware of this :)
[17:38] <Riddell> pitti: dbus-1-qt3 in New again if you have time to check
[17:38]  * mvo pushes the new friendly-recovery branch
[17:54] <pitti> Riddell: accepted
[18:01] <Riddell> thanks
[18:10] <sistpoty> cjwatson: out of curiosity, is there a reason to disable autoindent in vim for ubuntu?
[18:12] <Nafallo> sistpoty: it's really annoying when you paste indented code in? ;-)
[18:12] <laga> :set paste
[18:12] <laga> ?
[18:12] <sistpoty> Nafallo: hm...? autoindent doesn't seem to do set for me, at least not while I was working on debian/stable systems
[18:13] <sistpoty> Nafallo: I may be wrong, but imo the effect is just if you type in a line
[18:15] <Nafallo> oh well. I'll live either way :-)
[18:17] <sistpoty> Nafallo: well, it's no biggie, as I can easily override it (and I guess most vim users can so as well *g*)
[18:17] <Nafallo> sistpoty: quite :-)
[18:18] <sistpoty> <- vim novice, due to only 9 years of experience *g*
[18:21] <pitti> "set pastetoggle=<F9>" FTW!
[18:23] <mvo> pitti: I filed #245601 about the liblmdbm-perl" promotion, let me know what/if anything else is required there
[18:23] <pitti> that sounds harmless enough
[18:24] <mvo> great, thanks. its tiny too
[18:33] <cjwatson>   * Don't autoindent by default (Ubuntu: #5602)
[18:33] <cjwatson> sistpoty: ^- (bugzilla reference)
[18:34] <cjwatson> which is bug 12000
[18:35] <cjwatson> that said, it's possible we could drop that now that vim-tiny exists and is installed by default
[18:35] <sistpoty> ah, thanks cjwatson
[18:35] <cjwatson> but at any rate, that's the history
[18:37] <sistpoty> hm.. interesting it still affects the first pasted line
[18:52] <mvo> (offtopic) if someone speaks turkish, could you please check if http://paste.ubuntu.com/25046/ makes sense (i.e. would be understood)?
[18:56] <ogra> mvo, translating your holiday mail while working ? :)
[18:57] <mvo> ogra: exactly :P
[18:59] <tseliot> pitti, mdz: just FYI my patches for the nvidia drivers work in Intrepid. I will test the packages on a 64bit system tomorrow.
[19:00] <sistpoty> tseliot: does that mean we'll have working nvidia blob drivers soon again?
[19:01] <cjwatson> just from my experience of seeing Turkish, I'm sure at least one of those 'i's statistically ought to be undotted
[19:01] <tseliot> ﻿sistpoty: yes :-)
[19:02] <sistpoty> tseliot: excellent, thanks a lot :) (and feel free to ping me, if you need someone to test *g*)
[19:02] <tseliot> ﻿sistpoty: ok ;)
[19:02] <cjwatson> I think I'm bored of chasing Recommends now
[19:03] <cjwatson> germinate change to follow Recommends is in trunk, if anyone wants to try it out
[19:03] <cjwatson> to enable it, put 'feature follow-recommends' at the top of STRUCTURE in a local checkout of the seeds
[19:06] <Lrrr> cjwatson: I can I has germinate documentation? ;D
[19:06] <cjwatson> Lrrr: you can has man page
[19:06] <cjwatson> tell me what's missing, I know it inside-out myself so it's of course hard to know what other people don't :)
[19:08] <Lrrr> Afaik, meta tags in the seed files are not documented anywhere.  I wanted to check the source to see what's supported because I might be missing useful things.
[19:09] <cjwatson> meta tags?
[19:09] <Lrrr> I mean, things such as Task-Seed and Task-Metapackage.
[19:10] <Lrrr> Task-Seeds is in germinate-update-metapackage manpage, fine.
[19:10] <cjwatson> oh, those aren't actually parsed by germinate itself, which is why it doesn't document them
[19:10] <cjwatson> mostly they're for tasksel
[19:10] <cjwatson> but sure, I can document those
[19:10] <Lrrr> Anyway, don't care.  I know my way around germinate source so when it'll bother me enough I'll add it.
[19:11] <Lrrr> I just wish I had time to work seriously on it.
[19:12] <Lrrr> BTW, if you remember I told you LVM preseed possibly did not work with d-i.  I was wrong.  I had not updated enough partman components.  Now it work just fine.
[19:17] <cjwatson> Lrrr: documented now
[19:17] <cjwatson> Lrrr: ah good
[19:18] <Lrrr> man you are fast.
[19:18]  * Lrrr pulls
[19:18] <cjwatson> anything else before I upload 1.3?
[19:18] <Lrrr> No not really.
[19:19] <cjwatson> I suspect the biggest thing germinate(1) needs is some examples
[19:19] <cjwatson> it's all a bit abstract and hard to get one's head around in isolation
[19:21] <Lrrr> I don't know how many people actively use that.
[19:21] <cjwatson> not many I imagine
[19:21] <cjwatson> it's a rather specialist tool, after all
[19:21] <laga> cjwatson: yes.
[19:21] <cjwatson> (cool, but specialist ;-) )
[19:21] <laga> it'd be cool if the whole seeds thing was documented better
[19:22] <Lrrr> Outside of Ubuntu I know just 1 person using it.
[19:22] <laga> what do they do with it?
[19:22] <Lrrr> A custom distro.
[19:22] <Lrrr> And that's pretty much what I do with it too.
[19:22] <cjwatson> somebody was trying to use it to construct Debian CDs a while back
[19:23] <Lrrr> I use it for that purpose.
[19:23] <cjwatson> and I heard of somebody using it to manage metapackages in a similar way to us
[19:24] <Lrrr> I love to subvert Debian and Ubuntu tools for my own world dominative purpose.
[19:27] <cjwatson> http://ubuntu.dustinkirkland.com/manpages/intrepid/man1/germinate.html - seems to format fairly reasonably there
[20:22] <geser> pitti: looking at the last comment on bug #245178, I guess there went something wrong with the sync. Could you check?
[20:28] <Iulian> Riddell: FYI: Giver was uploaded to Debian.
[20:30] <pitti> geser: done
[21:56] <Riddell> Iulian: ok, let me know when it's in and I'll sync
[21:58] <Iulian> Riddell: Sure, thanks.
[22:19] <sebner> te =)
[22:20] <sebner> ah sry
[22:55] <zerwas> Has there been a discussion or feature request about implementing a dialog which allows a user to install the application that can handle a link when he clicks on a protocol in firefox that firefox does not understand by default?
[22:55] <zerwas> hm, hope this question was understandable
[22:56] <nxvl> zerwas: asac is the person to talk to
[22:56]  * Nafallo got confused in the middle somewhere
[22:57] <Nafallo> ah
[22:57] <Nafallo> now I get it :-)
[22:57] <asac> zerwas: look at how the apturl package does it
[22:57] <zerwas> asac, ya i have had a look in it a few months ago
[22:58] <nxvl> Nafallo: yes, i needed to read it 3 times to get it
[22:58] <zerwas> my first question is only if it already had been discussed and perhaps been dropped (due to security issues or so)
[22:58] <nxvl> :P
[22:59] <zerwas> Nafallo, ok easier: a webpage containing an irc:// link. i click on it and a dialog comes which asks me if i want to install an IRC program (xchat)
[22:59] <Nafallo> "The shellcode returned a non zero exit value. Would you like to try as root?" :-)
[23:00] <zerwas> think that would make it much easier for beginners to use IRC when they come across a note of an irc channel
[23:01] <asac> zerwas: that idea is nice. and it can be solved in a upstream fashion (with distro integration) or in a distro-only fashion
[23:01] <asac> zerwas: i am sure that both sides have been proposed at some point
[23:01] <asac> but most likely nobody implemented it
[23:01] <asac> zerwas: the way to get things started is to write a Specification
[23:02] <asac> discuss that; get it approved and find someone who implements it ;)
[23:02] <zerwas> asac, unfortunately i am only a beginner in programming ... but this idea came in my mind a while ago
[23:02] <zerwas> asac, okay that sounds feasible
[23:02] <asac> zerwas: you can even start a specification
[23:02] <asac> and register it in launchpad
[23:03] <asac> maybe someone else will fill in the implementation details
[23:03] <asac> zerwas: you could at least draft the use-cases ;)
[23:03] <asac> zerwas: look in the wiki for a specification template
[23:03] <asac> once you are done you can register your specification in launchpad
[23:04] <zerwas> asac, ok thank you very much for these hints! :-) i may try it
[23:04] <zerwas> or ask some people to help me with it if they agree it would be a nice feature
[23:04] <asac> zerwas: its not a simple thing as more than one component will be involved
[23:05] <asac> zerwas: so better draft a spec first