[01:14] <mikmorg> cjwatson: If you happen to still be around, I was wondering if I can trust Ubiquity to run /usr/lib/ubiquity/target-config AFTER it removes dpkgs based on the manifest diff?
[01:49] <rproenca> hi mpt. when you have a couple of minutes I'd like to talk with you and hear your suggestions for a better naming of some terms used on aptoncd
[02:41] <mpt> rproenca, hi
[02:43] <rproenca> rproenca: Hi. If you don't mind, can we talk about your suggestions?
[02:45] <mpt> sure
[02:46] <rproenca> mpt: To don't flood the -devel with some OT content, you can join with me at #aptoncd, please
[02:46] <mpt> ok
[02:58] <LaserJock> StevenK: you around?
[03:03] <StevenK> LaserJock: Nope. :-P
[04:10] <Hobbsee> morning all
[04:18] <LaserJock> hi Hobbsee 
[04:19] <Hobbsee> :)
[04:19] <Hobbsee> someone's alive :)
[04:22] <LaserJock> somebody is always alive
[04:24] <Hobbsee> LaserJock: it seems quiet today.  really quiet
[04:24] <Hobbsee> i mean, quieter than the weekends usually are
[04:25] <LaserJock> mhm
[04:32] <ScottK> Good morning Hobbsee.
[04:33] <Hobbsee> morning ScottK!
[04:42] <evand> morning Hobbsee, ScottK, LaserJock, others
[04:42] <LaserJock> hi evand and ScottK 
[04:43] <ScottK> Heya LaserJock.
[04:43] <zakame> yo LaserJock 
[04:43] <ScottK> LaserJock: Have you done much with gpg?
[04:43] <LaserJock> ScottK: not other than signing packages
[04:44] <LaserJock> yo zakame 
[04:44] <LaserJock> zakame: how's it going?
[04:44] <ScottK> LaserJock: OK.  Thanks.
[04:45] <LaserJock> ScottK: and I only recently started using seahorse for a key agent
[04:45] <LaserJock> I've always done it the "hard" way
[04:45] <ScottK> Ah, well then you'
[04:46] <ScottK> ...
[04:46] <ScottK> ll be glad to know that debuild will now work with seahorse-agent in Gutsy.
[04:46] <persia> ScottK: It works fine, with no messy .devscripts adjustments.
[04:47] <ScottK> Yep.  Thanks for testing it persia.
[04:47] <ScottK> Thanks StevenK for fixing it.
[04:52] <Hobbsee> heya evand!
[04:53] <zakame> LaserJock: looking at some revus now
[04:53] <zakame> the past couple of days have been terrible, with no electricity and all...
[04:53] <LaserJock> ah
[04:54] <Hobbsee> zakame: check licencing, else Mithrandir will eat you
[04:58] <zakame> Hobbsee: pointers to said eatings?
[04:58] <Hobbsee> zakame: motu mailing list was his annoyed mail
[04:58] <Hobbsee> zakame: he tends to take his victims into his cave, and eat them there, so it wouldnt be public
[04:59] <Hobbsee> persia: yes, eat.  You'll meet Mithrandir one day, i'm sure.
[04:59] <Hobbsee> he likes threatening to eat people :P
[04:59] <zakame> ah, /me syncs
[05:00] <zakame> lolgrue
[05:01] <Hobbsee> oh *darn*.  i remember what i was going to discuss with pitti now.
[05:02] <ScottK> It was the pinentry MIR, wasn't it?
[05:06] <Hobbsee> no
[05:11] <ScottK> Oh well.
[05:12] <StevenK> ScottK: If you recall the "I want a pony" link and picture on fridge.u.c, that used to be MIR. :-P
[05:12] <StevenK> IE: "No MIR for you!"
[05:13] <Hobbsee> hehe
[05:15] <ajmitch> better to eat people than throw them into a pool
[05:15] <ScottK> And don't throw anyone whose eaten someone in the pool until after they've had 30 minutes to digest.
[05:29] <ajmitch> heh
[05:36] <Hobbsee> You know, i wish that part of trademark policy stated that "if you want to make a custom cd distro, please point your bugtracker somewhere else"
[05:37] <LaserJock> heh
[05:37] <ScottK> Hobbsee: What are you getting bugs from?
[05:38] <Hobbsee> ScottK: ubuntu CE, ubuntu lite, ubuntu mint, ubuntu + automatix/...
[05:38] <Hobbsee> the mint ones, particularly
[05:38] <Hobbsee> well, linuxmint.
[05:38] <ScottK> Ah.
[05:39] <LaserJock> Hobbsee: well, Launchpad is supposed to be used by many distros
[05:39] <Hobbsee> LaserJock: true - but they tend to get their bugs filed in the source pacakges of ubuntu
[05:40] <Hobbsee> oh, and that they need to have a custom distro name in their /etc/lsb_release.
[05:40] <Hobbsee> (so we can pick out their bugs)
[05:42] <minghua> Hobbsee: they use Ubuntu in /etc/lsb_release?
[05:42] <minghua> That's really bad.
[05:42] <Hobbsee> not positive..
[05:42] <Hobbsee> i think some of them do - or did
[05:43] <StevenK> Maybe Ubuntu CE needs a bug tracker where they are refered to as 'divine interference' instead of bugs.
[05:43] <minghua> Speaking of LSB, is there a way using lsb tools to differentiate Ubuntu and Kubuntu?
[05:43] <Hobbsee> i like that
[05:44] <fabbione> morning
[05:45] <Hobbsee> morning fabbione!
[05:46] <Hobbsee> minghua: i think kubuntu currently has hte same stuff as ubuntu in the lsb stuff
[05:47] <minghua> Hobbsee: Yeah, I think it should as it use the same lsb* packages as Ubuntu.  Hence my question.
[05:47] <Hobbsee> bug #15739
[05:47] <ubotu> Launchpad bug 15739 in Ubuntu "libgd: new changes from Debian require merging" [Medium,Fix released]  https://launchpad.net/bugs/15739
[05:48] <Hobbsee> minghua: ah right.  it does
[05:49] <LaserJock> minghua: I think most derivs don't even know what /etc/lsb_release is
[05:52] <minghua> :-(
[09:01] <dholbach> good morning
[09:01] <Mithrandir> iz Daniel in many channels
[09:01] <dholbach> hey ccm
[09:02] <LaserJock> hi dholbach 
[09:02] <dholbach> hiya LaserJock
[09:02] <dholbach> hey StevenK
[09:02] <ccm> hey, dholbach 
[09:02] <StevenK> Ooof
[09:02] <StevenK> I hardly know you!
[09:03] <ccm> i am suprised how many karma points launchpads gives you for answering questions
[09:03] <dholbach> that never stopped Mithrandir from doing anything :)
[09:03] <StevenK> pitti!
[09:03] <dholbach> hey pitti
[09:04] <LaserJock> hiya pitti 
[09:04] <pitti> Good morning everyone
[09:05] <StevenK> pitti: Re-run the cruft checker at your leisure, please.
[09:05] <pitti> StevenK: I will; and I'll finally take some time to set up an automatic one
[09:06] <StevenK> Yay!
[09:06] <Hobbsee> morning pitti!
[09:06] <pitti> hey Hobbsee 
[09:06] <StevenK> pitti: The last 45 of 46 mails in my INBOX are Accepted mails, with 1 being a build failure on ia64.
[09:06] <pitti> StevenK: wow, curl? :)
[09:07] <StevenK> Nah, I've been working through flac as best I can.
[09:07] <pitti> erk, I'm sorry for DoSing the PPA buildd: https://dogfood.launchpad.net/+builds/rubidium/+history
[09:07] <Hobbsee> haha
[09:08] <Mithrandir> heh
[09:08] <StevenK> The problem with flac is the API changed in incompatible ways, and worse, the virtual-ness of some objects have changed, which leads to some build failures.
[09:08] <Mithrandir> morning Hobbsee
[09:08] <Hobbsee> morning Mithrandir!
[09:09] <StevenK> pitti: I plan on doing most of curl tonight, if I can.
[09:10] <LaserJock> StevenK: what is it that you're doing?
[09:11] <Hobbsee> he's breaking things
[09:11] <StevenK> LaserJock: A metric shedload of rebuilds for archive cruft. And being pitti's hero in the process.
[09:11] <StevenK> And what Hobbsee said.
[09:11] <LaserJock> oh, excellent
[09:12] <LaserJock> I love those kinds of QAish things
[09:17] <lifeless> StevenK: I don't think thats the *only* problem with flac :)
[09:17] <StevenK> lifeless: Agreed. :-)
[09:18] <sladen> morning all
[09:24] <Hobbsee> hi sladen 
[09:24] <pitti> StevenK: cruft updated
[09:25] <pitti> hey seb218
[09:25] <pitti> hey seb128, too
[09:25] <seb128> hello pitti
[09:26] <StevenK> pitti: Thanks
[09:28] <StevenK> Ugh. oo.org is in the list for libcurl4.
[09:28] <pitti> StevenK: better leave that to doko; unnecessary rebuilds are a pain
[09:28] <StevenK> I was planning on.
[09:29] <StevenK> Given it also seems to take 2 rubber chickens and goat to get oo.org to build sucessfully.
[09:29] <pitti> StevenK: at this point I wonder whether it wouldn't make more sense to have libcurl3 Provide: libcurl4
[09:29] <LaserJock> StevenK: rubber chickens?
[09:29] <pitti> StevenK: instead of going through all this rebuild mess
[09:30] <StevenK> Hrm.
[09:30] <pitti> StevenK: for all practical purposes, ABI 3 and 4 are the same now, right?
[09:30] <StevenK> It's a symlink, so I don't think there are any differences at all.
[09:30] <StevenK> But since libcurl4 has existed before, we can't use versioned Provides.
[09:31] <pitti> StevenK: ok, then maybe introducing a dummy package which just depends on libcurl3
[09:31] <Mithrandir> well, apart from the fact that our packaging system doesn't support versioned provides?
[09:32] <siretart> hrmpf. for some reason, gdm thinks my $HOME was full or not writable. I cannot find a report in launchpad, but wanted to ask if someone has already observed that behavior (current gutsy, that is)
[09:32] <StevenK> Which is then another change away from Debian, and may bite us the next time they update curl.
[09:33] <Mithrandir> StevenK: they won't move to libcurl4, that soname is used now.
[09:33] <seb128> siretart: what permissions do you use for the directory?
[09:33] <siretart> seb128: I tried even with 777 for my home, no change (and disk is NOT full)
[09:33] <StevenK> libcurl4 -> libcurl5 (if it happens) will be a barrel of laughs.
[09:34] <seb128> siretart: the partition didn't get remounted ro due to errors or something?
[09:34] <pitti> StevenK: that's what I mean with 'for all practical purposes' -> upstream has to bump to 5 next time
[09:34] <StevenK> pitti: If you think that's a way out of this mess, I'm happy to upload curl again.
[09:34] <siretart> seb128: no, it is writable. I can work as normal after I got login
[09:35] <pitti> StevenK: let's think about it a bit deeper, wrt. shlibs files and such
[09:35] <pitti> siretart: please ask iwj; he recently did some experiments and changes for handling a full $HOME
[09:35] <siretart> seb128: it's just that gdm complains about .dmrc not writable, and places my XAUTHORITY to /tmp
[09:35] <seb128> siretart: k, so I don't know, you are the first to complain about it on gutsy
[09:35] <StevenK> pitti: By my count there is ~ 40 rebuilds for curl4.
[09:35] <pitti> siretart: maybe he left some piece of testing code somewhere
[09:35] <pitti> StevenK: hm, 40 rebuilds wouldn't be too bad, but it's still a nuisance
[09:35] <seb128> siretart: active debug mode and look to the log maybe
[09:35] <StevenK> pitti: *nod*
[09:35] <siretart> seb128: how to do that?
[09:36] <siretart> gdm.conf?
[09:36] <seb128> siretart: run gdmsetup and click the option
[09:36] <siretart> ah, ok
[09:36] <seb128> it's in the security tab
[09:36] <pitti> StevenK: but I can't see anything wrong with a dummy libcurl4 which depends on libcurl3; if the shlibs point to 3, rebuilds will ignore it, and the installed system should cope because the 4 symlink is in libcurl3
[09:37] <siretart> found it
[09:37] <StevenK> And if packages depend on libcurl4 currently, and get rebuilt, they'll jump over to libcurl3, which is no bad thing.
[09:39] <pitti> StevenK: right, so at the end of gutsy we might get rid of it again
[09:39] <StevenK> Exactly.
[09:40] <pitti> . o O { and if Debian decides to go back to four, we are prepared }
[09:40] <pitti> :)
[09:40] <StevenK> Heh
[09:40] <StevenK> pitti: I'll start on preparing an upload when I get home, and point you at a debdiff.
[09:41] <pitti> StevenK: cool, thanks
[09:41] <siretart> seb128: nope. nothing interesting neither in ~/.Xsession-errors nor in /var/log/gdm/:0.log
[09:41] <seb128> siretart: and /var/log/syslog?
[09:42] <siretart> wow, there's more (and partly localized!)
[09:42] <siretart> Jul  3 09:39:18 faui44a gdm[17695] : WARNING: gdm_slave_session_start: Gruppe hat Schreibzugriff auf /home/siretart. 
[09:43] <seb128> ah, right, gdm doesn't like having user directory writable for other users
[09:43] <siretart> it complains if the group has write access?!
[09:43] <siretart> WTF?!
[09:43] <seb128> it considers it not secure
[09:43] <seb128> it should be +w for your user only
[09:44] <siretart> retrying
[09:44] <siretart> seb128: that did the trick
[09:45] <seb128> ;)
[09:45] <siretart> okay, now I can retitle and correct my just filed bugreport
[09:45] <seb128> 			       _("User's $HOME/.dmrc file is being ignored.  "
[09:45] <seb128> 				 "This prevents the default session "
[09:45] <seb128> 				 "and language from being saved.  File "
[09:45] <seb128> 				 "should be owned by user and have 644 "
[09:45] <seb128> 				 "permissions.  User's $HOME directory "
[09:45] <seb128> 				 "must be owned by user and not writable "
[09:45] <seb128> 				 "by other users."));
[09:45] <seb128> 
[09:45] <seb128> that's the normal error message
[09:45] <seb128> you didn't get it?
[09:45] <siretart> it is NOT writeable by other users
[09:46] <seb128> it was g+w no?
[09:46] <siretart> I have my own user group (named like my username), which has no other users
[09:46] <siretart> so there are no other users with write permissions there
[09:46] <seb128> you mentionned trying 777 before
[09:46] <siretart> the error messages says 'should not' not 'must not'
[09:46] <siretart> that was for debugging, normally I have it set to 775
[09:47] <siretart> TBH, I copied my home directory from my debian system. the gdm over there didn't complain about this
[09:47] <siretart> so therefore I didn't notice that
[09:48] <seb128> we don't change gdm
[09:48] <seb128> so either Debian patch gdm to not display the warning or the upstream behaviour changed in a new version
[09:49] <seb128> right, it happens when the directory is g+w
[09:49] <siretart> I strongly recommend to s/should be owned/must be owned/ in the error message
[09:50] <siretart> because that's closer to the truth
[09:50] <seb128> feel free to update the bug description with suggestions on what you would change ;)
[09:50] <siretart> I rejected the bug for now
[09:51] <siretart> but the behavior on user home set to 775 should get more though. I need to think about it
[09:55] <pitti> Mithrandir: hm, I NEWed the hildon-contol-l10n thing yesterday, but the other package is still not in NEW; it's FTBFS?
[09:56] <Mithrandir> pitti: yes, I fixed it this morning, it should be there in about an hour.
[09:56] <Hobbsee> Mithrandir: did you ever find out what happened to the developer weather report?
[09:57] <pitti> Mithrandir: ah, the symlinks to auto* stuff?
[09:57] <Mithrandir> yes
[09:57] <pitti> Mithrandir: I noticed them, but I thought you would b-dep on autotools or so
[09:57] <Mithrandir> pitti: yes, that would have been bright to do. :-)
[09:57] <Mithrandir> Hobbsee: disappeared into the whole named "ENOTIME", iirc.
[09:58] <Hobbsee> Mithrandir: right.  dont suppose anyone published notes about them somewhere?  i know bdmurray had a lot
[09:58] <Hobbsee> Mithrandir: or that fell into the "ENOTIME" hole too?
[09:59] <Mithrandir> Hobbsee: I think sobby might have eaten them for breakfast.
[09:59] <Hobbsee> tasty.
[10:00] <Hobbsee> then i'll grab them off bdmurray, as i noticed he was writing them in vi.
[10:00] <Hobbsee> or, attempt to
[10:00] <Hobbsee> Mithrandir: you should really make sure you feed sobby a bit more...
[10:00] <Hobbsee> maybe then it wouldnt eat things it's nto supposed to
[10:00] <Hobbsee> hi jono 
[10:01] <persia> There's a patch for sobby eating things on Launchpad.  Anyone want to test it?
[10:01] <lifeless> have we dropped breezy backports ?
[10:02] <Fujitsu> lifeless: Breezy has been dead for a while, so yes.
[10:02] <jono> hey
[10:02] <lifeless> that would explain the conflict checker errors
[10:03] <lifeless> hiya trouble
[10:09] <Fujitsu> Right, why did mysql-server-5.0's postinst cause 
[10:10] <Fujitsu> *cause my kernel to OOPS repeatedly?
[10:15] <lifeless> mvo: conflictchecker is running on macaroni now
[10:16] <lifeless> just need a bzr version thats not prehistoric :)
[10:16] <mvo> lifeless: heh :) good news!
[10:16] <lifeless> in a role account
[10:17] <Hobbsee> lifeless: there's a machine named macaroni?
[10:17] <pitti> doko: does http://packages.qa.debian.org/z/zope3/news/20070625T194326Z.html mean that we can sync now?
[10:17] <lifeless> Hobbsee: :)
[10:17] <Hobbsee> :
[10:17] <Hobbsee> :)
[10:19] <lifeless> http://macaroni.ubuntu.com/~conflictchecker/
[10:25] <Mithrandir> Hobbsee: it's a kind of penguin, so yes, naturally we have a machine called macaroni.
[10:25] <Mithrandir> Hobbsee: more confusing is we have a machine named gentoo..
[10:25] <Hobbsee> Mithrandir: heh
[10:27] <pitti> erk, I never actually uploaded the new hal
[10:27] <lifeless> mvo: progress: http://macaroni.ubuntu.com/~conflictchecker/possible-conflicts.txt
[10:48] <ogra> our kernel source doesnt ship any oss headers anymore, does anyone know if thats an upstream drop ?
[10:55] <shawarma> ogra: Which header in particular are you looking for?
[10:55] <StevenK> pitti: http://wedontsleep.org/~steven/curl.debdiff
[10:56] <ogra> shawarma, ac97.h and soundcore.h from the oss subdir for example 
[10:56] <ogra> shawarma, seems with .21 all of that was dropped, i have a very popular (even though very bad) thin client that only has an oss driver ...
[10:56] <Mithrandir> mvo: did you end up writing a spec about the upgrader for mobile?
[10:57] <ogra> i'd like to have a sis7019-source package so people can at least build the driver ... 
[10:57] <shawarma> ogra: They're still in the kernel source.. Hm.
[10:57] <ogra> and i need to know if its safe to delive the headers inside that package or if the oss headers might come back or something
[10:57] <ogra> shawarma, i only found alsa headers n ym source 
[10:57] <ogra> *in my
[10:58] <ogra> (note there is an ac97 for alsa as well as one for oss)
[10:59] <pitti> StevenK: I would change the "Depends: libcurl3" line to have an (= ${binary:Version}); similar for the Depends: libcurl3-gnutls one
[10:59] <shawarma> ogra: ./sound/oss/ac97.h is in my tree.
[10:59] <StevenK> Ah, good point.
[11:00] <shawarma> ogra: git tree, that is. Not from linux-source-2.6.22. I don't know about that one.
[11:00] <StevenK> pitti: debdiff updated.
[11:00] <ogra> ogra@laptop:/opt/ltsp/i386/root$ ls /usr/src/linux-headers-2.6.22-6-generic/sound/oss/
[11:00] <ogra> dmasound  emu10k1  Kconfig  Makefile
[11:00] <pitti> lol @ "This is a transitional package depending on the older (newer) SONAME of libcurl"
[11:00] <shawarma> ogra: What about /usr/src/linux-headers-2.6.22-6 ?
[11:01] <pitti> or wasn't it the newer (older) one?
[11:01] <StevenK> pitti: :-)
[11:01] <ogra> shawarma, same
[11:01] <StevenK> It's older now, since libcurl3 is the real library and libcurl4 is a symlink
[11:01] <ogra> shawarma, i'm fine if they are gone :) i just dont want to clash
[11:02] <pitti> StevenK: Section: libs -> Section: oldlibs (minor nitpick only)
[11:02] <ogra> i'm also pretty sure there are no oss drivers at all in the archive anywhere
[11:02] <pitti> StevenK: looks good to me otherwise
[11:02] <ogra> so it wouldnt be a loss :)
[11:02] <StevenK> pitti: For both curl4's?
[11:03] <pitti> StevenK: yes, I think so
[11:03] <pitti> StevenK: really just a cosmetical detail, though
[11:03] <doko> pitti: no, zope3 has a different source tarball, unfortunately
[11:03] <doko> did do it manually
[11:03] <pitti> doko: ah, ok
[11:04] <StevenK> pitti: Done, and uploading.
[11:04] <Hobbsee> StevenK: next thing they'll do is probably go to libcurl3.5
[11:04] <ogra> shawarma, 2.6.20 seems to be the last that had them
[11:04] <StevenK> Pity that I just missed the publisher.
[11:04] <Mithrandir> Hobbsee: libcurl3.14.15.9 ?
[11:04] <ogra> (here at least without git)
[11:04] <Hobbsee> Mithrandir: even better.
[11:05] <StevenK> But TeX already has that numbering scheme.
[11:05] <Mithrandir> so somebody is then bound to port curl to TeX
[11:05] <Hobbsee> Mithrandir: and build it with yada.
[11:06] <Hobbsee> Mithrandir: and then request a MIR for it, 
[11:06] <StevenK> curl is already in main.
[11:06] <Hobbsee> oh, damn.
[11:06] <Mithrandir> BAD Hobbsee 
[11:06] <Hobbsee> so it is
[11:06] <Hobbsee> me?  bad?
[11:06] <pitti> hi thekorn 
[11:07] <pitti> thekorn: looking forward to use the new p-lp-bugs API :)
[11:07] <Hobbsee> Mithrandir: i couldnt possibly be bad!
[11:07] <thekorn> hi pitti, thanks for your mail
[11:07] <ogra> hi thekorn , oh what a nice domain :)
[11:08] <Hobbsee> Mithrandir: "tell him he's dreaming, son"
[11:08] <Hobbsee> actually, probably only people like StevenK will get that.
[11:08] <shawarma> ogra: Ah, it seems that nowadays only the .h-files from include/ is put into the linux-header-* packages.
[11:08] <ogra> shawarma, do you know if it will stay that way ?
[11:08] <shawarma> ogra: No clue.
[11:09] <ogra> who would know ? BenC ?
[11:09] <shawarma> ogra: Why doesn't the kernel package build your driver? 
[11:09] <shawarma> ogra: Probably.
[11:09] <ogra> shawarma, there is no package, i have a sis7019.c file, thats all 
[11:10] <shawarma> ogra: I meant our official, normal kernel package.
[11:10] <ogra> shawarma, we dont build/ship/support oss :)
[11:10] <shawarma> ogra: The header files you're missing are still in linux-source-2.6.22, aren't they?
[11:10] <StevenK> Hobbsee: Heh
[11:10] <StevenK> Hobbsee: Great movie. :-)
[11:10] <shawarma> ogra: We ought to for stuff that's not supported by ALSA, I think.
[11:11] <Hobbsee> StevenK: yup :D
[11:11] <shawarma> ogra: that would be the right thing to to.
[11:11] <shawarma> ogra: do, even.
[11:11] <ogra> shawarma, thats would break a lot in our setup i think
[11:11] <ogra> this is a very very rare case, usually there is an alsa driver ...
[11:11] <shawarma> ogra: Just adding an extra driver?
[11:12] <ogra> hmm
[11:12] <shawarma> sounds pretty innocent to me.
[11:12] <ogra> you need to configure it 
[11:12] <ogra> it needs setup in modprobe.d etc
[11:12] <shawarma> ogra: Ah..
[11:12] <ogra> and it needs oss stuff in the back (i.e. ac97_codec for oss)
[11:13] <shawarma> ogra: Right, ok. 
[11:13] <shawarma> ogra: This is not a very common thin client, I suppose?
[11:13] <ogra> i'm fine with either having a source package the users can build with m-a or a binary in universe or so
[11:13] <ogra> it will become a very common one
[11:14] <ogra> shawarma, http://www.compactpc.com.tw/ebox-2300.htm
[11:14] <ogra> you can get it for $80
[11:15] <ogra> its as small as a CD and you can attach it to the back of most flat panels
[11:15] <ogra> (its the wrost HW ever though)
[11:16] <pitti> ScottK: pinentry> it b-deps against glib/gtk 1.2, which we want to get rid of in main; does the package support 2.0 as well? please disable gtk or use 2.0
[11:17] <ogra> if you ever want to see how nautilus draws the background use that thing at 1600x1200 resolution :)
[11:18] <Burgundavia> ogra: I was fixing a pc for friend with a Dell 27" screen. 2560x1600
[11:18] <ogra> Burgundavia, well, but thats wasnt a 200Mhz one with badly supported shared graphics
[11:19] <ogra> i guess
[11:19] <siti> Burgundavia: 30" runs at that res 
[11:19] <Burgundavia> siti: it might have been 30". I was big and I wanted it
[11:19] <siti> :)
[11:19] <seb128> pitti: I've just removed gstreamer0.8 from the archive
[11:20] <pitti> ScottK: https://wiki.kubuntu.org/MainInclusionReportPinentry updated
[11:20] <pitti> seb128: yay!
[11:20] <seb128> ;)
[11:20] <StevenK> seb128: Yay!
[11:20] <ogra> seb128, poor Hobbsee, now she has to explain it to shirish
[11:20] <Hobbsee> ogra: explain what now?
[11:21] <seb128> ogra: lol
[11:21] <Fujitsu> ogra: Hahahah.
[11:21] <ogra> Hobbsee, gstreamr0.8 was just dropped :)
[11:21] <StevenK> ogra: That's naughty.
[11:21] <seb128> ogra: "gstreamer0.8|0.10-swfdec in launchpad" on the mailing list
[11:21] <ogra> yeah :)
[11:22] <Hobbsee> ogra: i realise that, but what's that got to do with shirish?
[11:22] <ogra> Hobbsee, now there is no "gstreamer0.8-swfdec anymore
[11:22] <seb128> Hobbsee: he's the one who sent the mail on the mailinglist
[11:22] <Hobbsee> ogra: ah right
[11:22] <Hobbsee> seb128: yeah, i remember that much.  didnt remember that he was talking about 0.8-swfdec though
[11:23] <Hobbsee> seb128: according to him "You're a good MOTU" iirc :P
[11:23] <Hobbsee> ogra: no, i can just ignore him, on the basis that it's against the COC to tell him what i really think.
[11:23] <pitti> pdflatex: symbol lookup error: pdflatex: undefined symbol: _ZN12GlobalParamsC1EPc
[11:23] <pitti> arrgh
[11:24] <pitti> seb128: ^ poppler love again? :/
[11:24] <seb128> Mithrandir: hildon-control-panel-dbg_1.9.5-1ubuntu3_all.deb ... dbg arch all, doesn't look like it's correct
[11:24] <Fujitsu> Hobbsee: I'm sure you can get an exemption.
[11:24] <ogra> heh
[11:24] <Mithrandir> seb128: ouch, true.
[11:24] <Mithrandir> seb128: can you NEW it anyway and I'll fix it with a new upload?
[11:24] <seb128> Mithrandir: ok
[11:25] <Hobbsee> Fujitsu: no, no.  i dont think so.
[11:26] <Hobbsee> Fujitsu: i'm coping enough crap over telling someone who was harassing me to F$%& off, on the irc mailing list.
[11:26] <StevenK> Neat.
[11:27] <Hobbsee> Fujitsu: it doesnt seem to matter that the guy was harassing me enough, that when the staffers saw the logs from it, they klined him immediately.  no, the problem is that i apparently broke the COC by responding in such a manner.
[11:27] <Hobbsee> go figure.
[11:27] <Hobbsee> the dissenting members have now been enlightened, incidently.
[11:27] <seb128> pitti: bug #121327
[11:27] <ubotu> Launchpad bug 121327 in texlive-bin "pdflatex produces a symbol lookup failure since recent libpoppler upgrade" [Medium,In progress]  https://launchpad.net/bugs/121327
[11:27] <seb128> Mithrandir: accepted
[11:27] <pitti> seb128: oh, thanks
[11:28] <Mithrandir> seb128: thanks
[11:28] <pitti> seb128: erk, that seems to be more than a rebuild
[11:29] <seb128> pitti: yeah, they broke the API again it looks like :/
[11:29] <thom> mvo_: hey, i have a working https transport :-)
[11:29] <minghua> 121327 needs a new patch for texlive
[11:29] <pitti> seb128: they are very good at expressing this with correct SONAMEs, aren't they? :(
[11:29] <seb128> yeah :/
[11:29] <mvo_> thom: woah! great news, care to share your patches :-D
[11:30] <mvo_> thom: I will be happy to apply them
[11:32] <thom> mvo_: attached to launchpad bugs; #109294 and #122294
[11:33] <thom> or just pull http://www.planetarytramp.net/bzr/apt
[11:33] <mvo_> thom: you rock! thanks a lot, merging now
[11:41] <seb128> pitti: could you have a look to libcompizconfig-backend-kconfig in NEW?
[11:41] <seb128> there is some script in admin under LPGL
[11:41] <seb128> but there is no LGPL license in the tarball nor mention to debian/copyright
[11:41] <pitti> seb128: currently evaluating the UGooString poppler issue, in 30 minutes or so?
[11:42] <seb128> pitti: no hurry, I don't accept it from now, but looks like it's something common for KDE packages so I'm not sure if that's ok or not
[11:42] <seb128> another archive admin opinion is welcome ;)
[11:43] <seb128> Mithrandir: ^ if you want to comment ;)
[11:49] <mvo_> thom: it does not merge cleanly, is there anything outside methods/https.cc that needed to be changed? or should I just merge those bits?
[11:56] <Mithrandir> seb128: reject.
[11:57] <seb128> Mithrandir: ok, thanks
[11:57] <seb128> mvo: ^
[11:57] <mvo> seb128: thanks, I will talk to upstream about this
[11:57] <seb128> mvo: danke
[11:57] <Mithrandir> mvo: I wrote it in the email I sent you with the rejection yesterday.
[11:59] <mvo> Mithrandir: I uploaded a new version in the meantime that fixed the missing GPL COPYING file after I talked to upstream. I will talk to upstream again
[12:13] <thom> mvo: i'm quite suprised it didn't merge, since that branch is merged up fully with the ubuntu apt branch...
[12:13] <pitti> fabbione: hmm @ http://launchpadlibrarian.net/8288570/buildlog_ubuntu-gutsy-sparc.strace_4.5.15-1_FAILEDTOBUILD.txt.gz; it built on all other arches
[12:14] <fabbione> pitti: will look in a minute
[12:18] <pitti> fabbione: thanks
[12:22] <pitti> yay, texlive is really alive again
[12:26] <cjwatson> ogra: touching ~/.hwdb is sufficient for oem-config to disable the hardware database client notification on new installs, isn't it?
[12:26] <cjwatson> or do I need to put something in that file?
[12:27] <ogra> cjwatson, hmm i think the client wont work properly if its empty
[12:28] <cjwatson> what will go wrong?
[12:28] <ogra> ah, no, i was clever enought to just run the collection again if no content is found
[12:28] <cjwatson> oh good, that's perfect then
[12:28] <ogra> i'm not sure how it affects the notificatuon though, pitti wrote that part
[12:28] <ogra> pitti, ?
[12:29] <cjwatson> DisplayIf: [ ! -e ~/.hwdb ] 
[12:29] <ogra> ah, perfect
[12:29] <pitti> ogra: hm?
[12:29] <pitti> cjwatson: no, it's mere existance will inhibit it
[12:30] <pitti> confirmed, empty .hwdb doesn't break the client
[12:30] <ogra> cjwatson, can we allocate 30 min or so during the sprint to talk about the edubuntu liveCd and the removal of the edu apps through ubiquity to find some kind of solution ? 
[12:30] <cjwatson> sure
[12:30] <ogra> great :)
[12:40] <fabbione> pitti: feh.. ok i need to look into with deep love...
[12:40] <fabbione> pitti: gonna grab some food first
[12:54] <shawarma> pitti: I think we need to discuss the language pack building stuff on the ppa's..
[01:05] <pygi> hey folks
[01:15] <shawarma> pitti: It's been hogging the ppa's buildd's for 8 hours now.
[01:15] <fabbione> pitti: looking into strace
[01:25] <StevenK> pitti: libcurl can be rescued from NEW, it's built on everything bar sparc, which is underway.
[01:26] <persia> Is a libcurl fix in Debian worth a sync, or would it just make more churn, given the proposed solution.
[01:31] <fabbione> doko: ping?
[01:32] <doko> fabbione: pong
[01:32] <fabbione> doko: i think i found a bug on glibc 2.6 on sparc... could you please try to reproduce it locally?
[01:33] <fabbione> doko: try this: lftp http://url of your choise/
[01:33] <fabbione> it will hang just there
[01:33] <fabbione> if you start stracing lftp it will go
[01:33] <fabbione> stop stracing.. download some files/cd/etc.. will work
[01:33] <fabbione> try to exit and it will hang again
[01:33] <fabbione> start the strace again and it will exit
[01:33] <fabbione> i never seen anything like this with 2.5
[01:37] <doko> fabbione: seems to work for me; any specific URL?
[01:38] <fabbione> doko:  lftp http://archive.ubuntu.com/ubuntu
[01:38] <fabbione> for example
[01:38] <fabbione> are you using Niagara right?
[01:38] <doko> yes
[01:38] <doko> still feisty kernel
[01:38] <fabbione> hmm no
[01:39] <StevenK> persia: Don't tell me libcurl -7 exists in Debian now.
[01:39] <fabbione> i have all gutsy here
[01:39] <StevenK> persia: I. Just. Don't. Want. To. Know. :-)
[01:39] <fabbione> doko: can you try to upgrade and test?
[01:39] <fabbione> doko: i can't downgrade to feisty with this LDOM setup or nothing will work 
[01:40] <fabbione> doko: nevermind.. i found the problem
[01:40] <persia> StevenK: Umm..  No.  More specifically, one of the RC sync candidates I'm looking at is for a package fix for the libcurl4 -> libcurl3 transition, and I didn't know if it was worth syncing just for that, given the new libcurl4 you've been working on.
[01:41] <fabbione> doko: it's NFS going banana
[01:42] <doko> fabbione: ahh, ok. will hopefully be able to upgrade before the sprint
[01:42] <fabbione> doko: thanks for looking into it anyway
[01:42] <StevenK> persia: Ah. Wait for the new libcurl, and then request a sync.
[01:43] <persia> StevenK: OK.  Thanks.
[01:46] <fabbione> pitti: i can see the upstream change that broke strace, but i still can't figure out why it breaks. the change seems sane in respect to the other arches that got the same code 2 years ago
[01:57] <pitti> fabbione: hm, it looked like a problem with linux headers initially; so that's not it?
[01:57] <fabbione> pitti: it doesn't look like...
[01:57] <fabbione> that stuff doesn't include linux headers at all...
[01:57] <fabbione> or at least
[01:58] <pitti> shawarma: right, I discussed it yesterday with celso
[01:58] <pitti> shawarma: it's only the initial build bootstrap that will take long, gutsy will soon be moved to direct archive uploads, and we'll get more buildds soon
[02:03] <fabbione> pitti: i will need to talk to david tomorrow. this is a bit out of my knowledge to do it right
[02:04] <fabbione> pitti: can we leave for a few days without it?
[02:04] <fabbione> pitti: (btw.. it fails on Debian too.. it's not just us)
[02:04] <pitti> fabbione: of course, it's not urgent at all; should be fixed by the final release
[02:04] <fabbione> pitti: i made it build locally but i am not convinced that is the right move
[02:04] <pitti> fabbione: ah, good, then maybe we can just sync the next version :)
[02:06] <fabbione> ok i need to go now
[02:06] <fabbione> pitti: will let you know as usual
[02:07] <pitti> bye fabbione, thanks
[02:07] <fabbione> no problem
[02:19] <zul> morning
[02:21] <Mithrandir> hiya zul
[02:21] <Mithrandir> zul: mind if I reject your application for ubuntu-mobile, at least until you've contributed something?
[02:22] <zul> Mithrandir: no problem
[02:24] <ScottK> pitti: Thanks for the review on the MIR for pinentry.  I'll see what I can do.
[02:29] <Mithrandir> seb128: has evince switched how it paints the documents somehow?  It's very, very slow on this machine (ATI Radeon 8500 with free drivers)
[02:30] <seb128> Mithrandir: I've tried to track the bug but no luck for now, I'm wondering if that's an xorg bug
[02:31] <seb128> Mithrandir: according to sysprof it take > 90% of the time to /usr/bin/Xorg, but there is no function name nor anything
[02:31] <Mithrandir> seb128: it seems related to the graphics driver at least, since it's much faster on my intel-based laptop
[02:31] <Mithrandir> seb128: at the same time, it's only evince, no other applications I've seen
[02:31] <seb128> we received a bug about it, the guy is using a radeon
[02:32] <Mithrandir> is there something I can do to help debug the problem?
[02:32] <seb128> and my desktop does that also, radeon 9600 card
[02:32] <seb128> thanks, but that's ok, I get it on my desktop as well
[02:32] <Mithrandir> with the free driver or fglrx too?
[02:32] <seb128> ati driver
[02:32] <seb128> the open source one
[02:33] <seb128> what is weird is that it doesn't happen running the feisty binary
[02:33] <seb128> evince binary
[02:33] <seb128> so it looks like evince is doing something which makes xorg unhappy
[02:33] <seb128> not sure of what ...
[02:33] <Mithrandir> might be using some other code paths in cairo or something like that?
[02:34] <seb128> right
[02:34] <Mithrandir> (he says, waving his hands around)
[02:34] <seb128> the rendering is done by poppler though
[02:34] <seb128> and it doesn't happen running the feisty evince with the gutsy poppler and cairo
[02:34] <seb128> I'll let you know if I figure something
[02:34] <Mithrandir> hm, weird.
[02:34] <Mithrandir> thanks
[02:35] <Mithrandir> at first, I wondered if I had gone mad, or something
[02:35] <StevenK> pitti: If the new libcurl binaries have been published, can you run cruft again, please?
[02:37] <shawarma> pitti: Alright. Can you tell from the build history list how long it's going to be?
[02:40] <seb128> Mithrandir: according to sysprof (which works today) it spinning a lot in fbComposite
[02:40] <Mithrandir> seb128: hm, maybe try without composite enabled?
[02:41] <seb128> I will
[02:41] <StevenK> pitti: I'm turning my archive cleaning gaze onto apache1 and its remaining offenders.
[02:43] <ScottK> pitti: pinentry has pinentry-gtk and pinentry-gtk2.  If I remove pinetry-gtk and the gtk1 build-dep from the package and lean on upstream to start working on a port to qt4, would that be sufficient to resolve your concerns?  Upstream isn't so much dead as thinking they are done AFAICT.
[02:44] <pitti> ScottK: that sounds fine; if there is already a -gtk2 package, disabling the gtk 1 one sounds like the right thing; thank you!
[02:44] <StevenK> Software is never finished! Those heathens. :-P
[02:44] <pitti> StevenK: cool
[02:44] <ScottK> pitti: Thanks.  There is and I will.
[02:44] <pitti> shawarma: probably still the entire day, but please ping cprov if you need to get something built, then he can bump the build score
[02:44] <pitti> shawarma: sorry for the trouble, I wasn't aware that it'd take so long
[02:45] <StevenK> pitti: We're looking to completly drop apache 1 and related packages?
[02:45] <seb128> Mithrandir: ok, evince changed to use cairo rendering
[02:45] <Mithrandir> StevenK: I sincerely hope so.
[02:45] <seb128> Mithrandir: before they were using a gdkpixbuf
[02:46] <seb128> so that's cairo sucking
[02:46] <Mithrandir> seb128: ah, and that broke it?
[02:46] <seb128> something like http://bugs.freedesktop.org/show_bug.cgi?id=4320
[02:46] <ubotu> Freedesktop bug 4320 in Driver/Radeon "Over from xrgb8888 pictures not fast-pathed in XAA" [Normal,Assigned]  
[02:46] <StevenK> In that case, I'll completly rip out the apache 1 packaging for request-tracker 3.[46] 
[02:46] <Mithrandir> StevenK: fwiw, it's gone from unstable
[02:47] <shawarma> pitti: I'll just build it on my laptop. No worries.
[02:47] <StevenK> (But it's so fun...)
[02:49] <StevenK> Hum. If drop all of apache 1, it leaves request-tracker and probably a few others bits uninstallable and unbuildable (at least in rt's case). On the other hand, it's fun, but it leaves a large diff.
[02:50] <StevenK> Mithrandir, pitti: Opinions, or neither of you care much? :-)
[02:50] <Mithrandir> StevenK: NMU it in Debian and ask for it to be synced? :-)
[02:51] <StevenK> Bugger that, I'd rather file RC bugs saying it doesn't build. :-)
[02:51] <Mithrandir> that'd work too
[02:55] <seb128> Mithrandir: bug #122786 if you want to subscribe and that seems to be due to xorg http://bugs.freedesktop.org/show_bug.cgi?id=4320
[02:55] <ubotu> Launchpad bug 122786 in evince "[gutsy]  very hi cpu usage when scrolling pdf" [High,Confirmed]  https://launchpad.net/bugs/122786
[02:55] <ubotu> Freedesktop bug 4320 in Driver/Radeon "Over from xrgb8888 pictures not fast-pathed in XAA" [Normal,Assigned]  
[03:00] <claviola> has anyone ever had trouble getting pbuilder to install packages that come from security?  I have a feisty chroot and it's failing to build because it won't install a couple of packages that had security updates, but they both show up as 500 on apt-cache policy and are perfectly installable with an apt-get install inside the chroot
[03:01] <StevenK> Oh, they will be buildable, it's installability.
[03:03] <StevenK> Mithrandir, pitti: rt3.4 can probably be killed, and rt3.6 has a serious bug already asking for it to be fixed.
[03:11] <ScottK> pitti: I'm fixing up pinentry now.  Since it's still in universe, I should make MOTU the maintainer, but I was wondering if I should go ahead and just make it core developers since it's about to move?
[03:12] <evand> pitti: Shouldn't restricted-manager be in restricted?  It will not even start without l-r-m.
[03:19] <ion_> E.g. apt-get shouldnt be in restricted just because one can install non-free software with it.
[03:19] <cjwatson> apt-get starts without restricted, though
[03:20] <cjwatson> it's analogous to main vs. contrib in Debian; we've always mapped contrib into restricted/multiverse in Ubuntu
[03:20] <ion_> If i make a fork of apt-get that exits immediately if the Macromedia Flash plugin isnt installed, does it become non-free software? ;-)
[03:20] <cjwatson> restricted-manager's entire purpose is to install restricted-licensing software and if you're the sort of person who turns off restricted then you likely don't want it
[03:20] <cjwatson> ion_: no, and nobody's suggesting it would
[03:21] <cjwatson> we don't have a precise analogue of Debian's contrib, but it's for free software that depends on non-free software
[03:21] <cjwatson> restricted is the best we have
[03:22] <StevenK> pitti: When checkrdepends has stopped spinning here, I'm going to compile a list of apache 1 modules with no rdepends that can be killed from the archive right off, shall I just submit the list as bug?
[03:22] <cjwatson> if you made a fork of apt-get that was specially customised for stuff in the restricted and multiverse components and wouldn't deal with anything else, I'd suggest putting that in the restricted component too, but wouldn't say it was non-free.
[03:38] <claviola> did no one run into this issue with pbuilder before? I came across it while trying to backport pidgin from gutsy to feisty
[03:41] <mvo> claviola: what issues in particular? dependency resolution?
[03:42] <pitti> StevenK: either that, or just tell me
[03:43] <pitti> ScottK: pinentry maintainer> yes, just set it to core developers (it doesn't matter that much, though)
[03:43] <seb128> what's going on with libcurl?
[03:43] <ScottK> pitti: OK.  WIll do.  I've about got the package done (testing things now).
[03:43] <seb128> which version has to be used?
[03:43] <Spads> claviola: I recently discovered that cowdancer's cowbuilder stuff doesn't work in ubuntu because cowdancer itself isn't in main
[03:43] <pitti> evand: r-m> the software itself is GPL and free, so not sure
[03:43] <pitti> seb128: libcurl3 now
[03:44] <seb128> pitti: they downgraded the soname?
[03:44] <pitti> seb128: yes :/
[03:44] <seb128> utch
[03:44] <pitti> seb128: we now have a transitional package in place which depends on libcurl3
[03:44] <seb128> k
[03:45] <evand> pitti: Well in the case of ubuntu-without-restricted, they don't have any restricted software on their system and an application that says "install this restricted software to make this software work"
[03:46] <pitti> evand: it can also install firmware for free drivers like bcm43xx
[03:46] <pitti> evand: but I don't mind much, if it's easier for you when it's in restricted, I'll move it there
[03:47] <cjwatson> pitti: the firmware's non-free though, or we wouldn't need to use that approach :)
[03:47] <evand> pitti: If you have no major objections, I would appreciate it.
[03:51] <pitti> evand: no, I don't see a problem; we can install stuff from restricted on the CDs
[03:52] <pitti> StevenK: why does libcurl4-dev still depend on libcurl4 then? shouldn't there just be a libcurl-dev which depends on -3?
[03:53] <evand> thanks pitti 
[03:54] <pitti> evand: moved to restricted, should land there in 40 minutes
[03:54] <pitti> (after the next publisher run)
[03:56] <ogra> hrm
[03:56] <ogra> if i get mmap():Permission Denied in an app, is there a way to make that work ? 
[03:57] <Mithrandir> chown root /usr/bin/app ; chmod u+s /usr/bin/app ? :-P
[03:58] <ogra> well, its run by root 
[03:58] <ogra> (its pulseaudio trying to run with the oss-mmap module ... i run it with --system so it should behave proper i'd expect)
[03:59] <ogra> i'm not really keen on running pulse suid root :)
[03:59] <evand> thanks
[04:01] <ogra> oh, err
[04:01] <ogra> root@laptop:/# ls -l /usr/bin/pulseaudio
[04:01] <ogra> -rwsr-xr-x 1 root root 35480 2007-06-28 13:51 /usr/bin/pulseaudio
[04:01] <ogra> it *is* suid root ?!?
[04:01] <pitti> ogra: it just checks for pulse-rt membership and drops it
[04:02] <pitti> ogra: if you are in pulse-rt, it runs with higher priority
[04:02] <pitti> but it still runs as user in either case
[04:02] <ogra> pitti, well, i run it with --system ... sho it will ignore that part i guess
[04:02] <ogra> the pulse-rt group stuff i mean
[04:02] <pitti> ogra: right
[04:03] <ogra> ther is no other proper way to use mmap ? 
[04:03] <ogra> any capability i could set or so ? 
[04:04] <ogra> (this crappy thin client drives me nuts here)
[04:04] <pitti> ogra: you should really avoid capabilities for that; mmap shouldn't need particular ones
[04:04] <pitti> ogra: what does it do, just read/write? maybe you have PROT_EXEC?
[04:06] <ogra> pitti, no idea yet, i havent looked at the code ... it took me some days to even get the oss driver to work on that thing ... now i have sound but it gets choppy if i move the mouse or have high net traffic ... module-oss-mma is supposed to fix that ... it seems to function on other distros ... i'll check the source
[04:06] <ogra> *module-oss-mmap
[04:07] <pitti> ogra: if you strace it and note down the mmap() arguments, it should give a hint
[04:07] <ogra> choppy sound is better than no sound though :) 
[04:07] <ogra> right, i'll do tat
[04:07] <ogra> *that
[04:20] <ogra> pitti, i see PROT_READ and _WRITE ... no EXEC
[04:20] <pitti> ogra: hm, and which file does it mmap()?
[04:22] <ogra> well, i only see: "mmap2(NULL, 12288, PROT_WRITE, MAP_SHARED, 7, 0) = -1 EACCESS (Permission denied)"
[04:22] <ogra> no filenames ot paths anywhere 
[04:22] <ogra> *or
[04:22] <pitti> ogra: that's fd 7
[04:23] <ogra> ah
[04:23] <ogra> hmm
[04:23] <pitti> ogra: above in the strace must be an open call with results in "= 7"
[04:23] <pitti> ogra: if that file descriptor is not opened for writing, you should get that
[04:23] <ogra> ah, right
[04:23] <ogra> there is a PROT_READ call above as well that doesnt seem to fail
[04:24] <ivoks> then probably program is not running under sufficient privileges or file is read only
[04:24] <ogra> ah, the read is on -1 then
[04:24] <ogra> well i dont even have /dev/fd/7 
[04:24] <pitti> ogra: so maybe the fd has really been opened with O_RDONLY?
[04:24] <ogra> that should be there, no ?
[04:25] <pitti> ogra: not sure, it might have been closed again already
[04:25] <ogra> ah, k
[04:25] <pitti> ogra: just save the strace into a file and grep for 'open.*= 7'
[04:25] <pitti> (with open() being the most common function for getting an fd; there are others, of course)
[04:26] <pitti> ogra: just grepping for '= 7' should work, too, can't be too many hits :)
[04:27] <ogra> ah
[04:27] <ogra> yeah, lots of O_RDONLY
[04:28] <pygi> we're opening some devices? :)
[04:29] <claviola> mvo: yeah, dependency resolution
[04:29] <mvo> claviola: what package do you see it with, can you please give some advice how to reproduce?
[04:30] <claviola> mvo: will do, running it again now.
[04:30] <claviola> both packages have newer versions in the ubuntu security repository
[04:31] <claviola> I added it to the chroot, they are installable from within
[04:36] <claviola> mvo: alright, here it is
[04:36] <claviola> The following packages have unmet dependencies: libebook1.2-dev: Depends: libebook1.2-9 (= 1.10.1-0ubuntu1.1) but it is not going to be installed libnss3-dev: Depends: libnspr4-dev (= 1.8.0.10-3ubuntu1) but it is not going to be installed
[04:37] <claviola>   Version table:
[04:37] <claviola>      1.10.1-0ubuntu1.1 0
[04:37] <claviola>         500 http://security.ubuntu.com feisty-security/main Packages
[04:37] <claviola>      1.10.1-0ubuntu1 0
[04:37] <claviola>         500 http://br.archive.ubuntu.com feisty/main Packages
[04:39] <seb128> claviola, mvo: I don't know what the bug is in this case, but those bugs are often due to a source package having binaries in main and universe and having security only enabled for main
[04:39] <claviola> I have security enabled for all components
[04:40] <seb128> apt-cache policy libebook1.2-de libebook1.2-9 ?
[04:40] <seb128> apt-cache policy libebook1.2-dev libebook1.2-9 ?
[04:41] <claviola> both candidates are the security versions
[04:41] <mvo> claviola: out of curiosity, does it help if you change /etc/pbuilder/pbuilderrc and there PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-gdebi" ?
[04:41] <claviola> will give it a shot
[04:42] <claviola> is /usr/lib/pbuilder/pbuilder-satisfydepends the standard?
[04:44] <mvo> claviola: yes
[04:44] <claviola> yeah, gdebi was fine
[04:44] <mvo> claviola: that is interessting. I knew it would be faster, its good to know that its more correct too :)
[04:45] <claviola> yeah, *much* faster :)
[04:45] <claviola> I'm trying to figure out why apt is going nuts now
[04:45] <claviola> I don't think anyone would complain
[04:45] <claviola> but I haven't used it at all yet
[04:46] <claviola> this is really weird considering all that happens is that apt-get is ran inside the chroot
[04:46] <claviola> unless there's something else that happens when one runs 'pbuilder login', I'm doing the same thing by hand
[04:47] <mvo> claviola: IIRC (I may be wrong here) satisfydepends does not really runs chroot apt-get but calls with with a bunch of -o DIR:: arguements, is that correct?
[04:48] <claviola> mvo: with a set -x, what I get are calls like "chroot /var/cache/pbuilder/build//29338 /usr/bin/apt-get -s install cdbs debhelper libgtk2.0-dev libxss-dev libmeanwhile-dev libgadu-dev libnss3-dev tcl8.4-dev tk8.4-dev libgstreamer0.10-dev libgtkspell-dev libltdl3-dev libperl-dev libstartup-notification0-dev"
[04:48] <mvo> ok - wrong memory than :)
[04:49] <claviola> I think I've ran into a bug
[04:50] <claviola> with the command line above, apt-get breaks
[04:50] <mvo> claviola: what is the error mesage?
[04:50] <claviola> the same I get with pbuilder
[04:51] <claviola> this happens if I try to apt-get -s install libnss3-dev libebook1.2-dev
[04:51] <claviola> if I try to simulate them both separately, everything is fine
[04:51] <claviola> if not, just the old
[04:51] <mvo> claviola: could you please run it with -o Debug::pkgProblemResolver=true and -o Debug::pkgDepCache::AutoInst=true
[04:51] <claviola>   libebook1.2-dev: Depends: libebook1.2-9 (= 1.10.1-0ubuntu1.1) but it is not going to be installed
[04:51] <claviola>   libnss3-dev: Depends: libnspr4-dev (= 1.8.0.10-3ubuntu1) but it is not going to be installed
[04:54] <ScottK> !pastebin | claviola
[04:54] <ubotu> claviola: pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[04:57] <claviola> I wonder why the hell it needs javascript, but still... http://paste.ubuntu-nl.org/28353/
[05:01] <claviola> this is pretty weird, I get this outside as well. am I the only one?
[05:01] <claviola> outside = of the chroot, on feisty
[05:09] <geser> StevenK: I've reread the scrollback now about curl: upstream is already at so-version 4 so the next one will be 5. Debian managed to restore the API/ABI and went back to libcurl3 to save the transition. libcurl3 installs now libcurl.so.4 and symlinks from libcurl.so.3 to libcurl.so.4 to make the old packages happy (AFAIUI)
[05:10] <axxo> you make that sound like a good thing
[05:10] <cjwatson> I think everyone involved thinks it's a necessary disaster
[05:11] <cjwatson> though I haven't read up on it all
[05:11] <geser> I've only read the discussion on the debian-project ML
[05:12] <geser> Debian didn't want the transition as the many libcurl rdepends would make a transition from unstable to testing very hard and long
[05:22] <claviola> mvo: so the main problem seems to be with libnspr4-dev right now
[05:23] <pitti> mvo: what was the magic option to have apt-get source download the source without asking for version control confirmation?
[05:24] <mvo> pitti: *cough* you mean the option that is about to be added ;) ?
[05:24] <pitti> mvo: ah: "yes | apt-get source apport"
[05:25] <pitti> mvo: that should do for now :)
[05:25] <cjwatson> pitti: --assume-yes seems to do the job too
[05:26] <pitti> cjwatson: yay
[05:27] <ion_> When apt-get source points you to a VCS branch, whats the canonical (no pun intended) way to get the orig.tar.gz?
[05:27] <tkamppeter> pitti, I did some thoughts about the source debian package for automatically rebuilding all drivers from OpenPrinting (see https://blueprints.launchpad.net/ubuntu/+spec/printerdriverautodownload)
[05:28] <pitti> ion_: I'd say, say yes, download the package, and then checkout the bzr
[05:28] <pitti> tkamppeter: ah, will have a look at it
[05:28] <tkamppeter> pitti,I see one problem there:
[05:29] <mvo> ion_: you can use apt-get source --tar-only pkg too 
[05:29] <ion_> Thanks
[05:29] <tkamppeter> The printer driver offered at OpenPrinting are third-party drivers, so they are packaged to be installed in /opt (see http://www.linux-foundation.org/en/OpenPrinting/WritingAndPackagingPrinterDrivers)
[05:30] <pitti> tkamppeter: right
[05:31] <pitti> tkamppeter: that's probably a good thing to avoid package file conflicts
[05:31] <tkamppeter> Now an automatic rebuilding with installation into /usr is not trivial, as the original packager of the distro-independent RPM (which is not necessarily me!) can have hard-coded /opt paths, and can have used very many different methods to introduce paths.
[05:32] <pitti> tkamppeter: right; but if there is a standard PPD search path in /opt, and cups looks for that, it should work, shouldn't it?
[05:33] <tkamppeter> And if I do no conversion, simnply rebuilding the RPM under Ubuntu and then uncompressing the RPM and letting the resulting files and maintainer scripts get packages as Debian package gives a Ubuntu package installing in /opt.
[05:33] <pitti> tkamppeter: ah, wait, we wanted to ship those as an official Ubuntu package, right
[05:33] <pitti> darn
[05:34] <iwj> I remember many years ago trying to kill /opt in FSSTND.  I won too but then later during the FHS merge it rose from the dead.
[05:34] <pitti> iwj: well, if it was /usr/local/, it wouldn't help us either
[05:34] <tkamppeter> pitti, there is a standard PPD path, /usr/share/ppd, and the maintainer scripts of the distro-independent packages link their PPDs to /usr/share/ppd.
[05:34] <iwj> pitti: Yers.
[05:34] <pitti> they do the right thing by *not* installing into /usr
[05:34] <iwj> /opt is better than /usr/local.
[05:34] <pitti> tkamppeter: there should be /opt/ppd or so, too
[05:35] <iwj> You could retarget the package and leave a symlink behind ?
[05:35] <iwj> That way it won't overwrite anything anyone else put in /opt but it will still work.
[05:36] <tkamppeter> pitti, my concept is that all actual files in the distro-independent package install into /opt/<supplier>/ and the maintainer scripts set symlinks to connect the driver appropriately to the system.
[05:37] <tkamppeter> /opt/share/ppd and //usr/local/share/ppd were rejected by two distros, Red Hat (Tim Waugh) and Ubuntu (was it you, pitti?).
[05:37] <pitti> tkamppeter: no, having cups search those directories would be perfectly fine
[05:37] <pitti> tkamppeter: the issue was *shipping* those directories in the packages, not adding it to the cups search path
[05:38] <tkamppeter> Does a .deb create a directory when it is missing?
[05:38] <pitti> tkamppeter: I think there's no way around relocating the files and paths
[05:38] <pitti> tkamppeter: missing in what way?
[05:38] <tkamppeter> RPM does not do it, RPM distros must ship /opt to be able that packages can be installed in /opt.
[05:39] <iwj> root@lalonde:~# pvremove -f /dev/sda11
[05:39] <iwj>   Can't pvremove physical volume "/dev/sda11" of volume group "gtest" without -ff
[05:39] <Chipzz> tkamppeter: I think it does (.deb creating the dirs)
[05:39] <tkamppeter> package contains file /opt/gutenprint/ppds/epsonc80.ppd, distro has no /opt at all, does the package install?
[05:39] <pitti> tkamppeter: if some upstream package wants to install into /opt, it should mkdir /opt if it doesn't exist; otherwise it would be fairly broken
[05:39] <pitti> tkamppeter: however, /opt is there by default anyway
[05:39] <Chipzz> tkamppeter: I even think there is no way to have .deb not create these dirs
[05:40] <pitti> tkamppeter: sure, it will
[05:40] <pitti> tkamppeter: (except that Ubuntu packages must not have files in /opt)
[05:40] <iwj> pitti: normally constructed .debs contain the directories in their fsys tarball so the directories would get automatically created.
[05:40] <pitti> iwj: right
[05:40] <tkamppeter> pitti, and that rule would be broken by the fully auto-rebuilding printer driver package.
[05:41] <pitti> tkamppeter: right, so we need to relocate the files there to /usr/share/ppd
[05:41] <iwj> NB that if the package has  drwxr-xr-x /somedir/  but the system has  lrwxrwxrwx /somedir -> /otherdir  then dpkg will follow the link.
[05:41] <pitti> tkamppeter: and /usr/lib/cups/backend-available/
[05:41] <tkamppeter> pitti, the driver packages do not only contain PPDs.
[05:42] <iwj> tkamppeter: The difficulty is that they might contain programs which would refer to /opt/supplier/somethingorother, right ?
[05:42] <iwj> And it's impractical to fix that.
[05:42] <pitti> tkamppeter: right, those need manually maintained patches, I think
[05:42] <pitti> tkamppeter: preferably the sources would have a configure option for that
[05:42] <iwj> pitti: They might be binary-only nonsense.
[05:43] <pitti> tkamppeter: that might make sense for the spec anyway
[05:43] <iwj> pitti: And the idea is to translate the binary packages, not the sources.
[05:43] <iwj> AIUI
[05:43] <pitti> iwj: I wouldn't repackage and ship those in Ubuntu anyway
[05:43] <iwj> You're sure they wouldn't end up in restricted ?
[05:43] <pitti> iwj: binary translation> oh, was it?
[05:43] <claviola> could someone try installing libnspr4-dev on their feisty box? It seems to be the root of my problems
[05:43] <iwj> pitti: I think so but tkamppeter will know.
[05:44] <tkamppeter> Perhaps we do the follwing, we simply drop everything in /opt/<supplier> into /usr/lib/printdriver/<supplier> (for each <supplier>) and let the maintainer scripts link /usr/lib/printdriver/<supplier> to /opt/<supplier>. After that we run also the original maintainer scripts to complete the symlinking.
[05:44] <pitti> tkamppeter: that would still break the /opt rule
[05:44] <siretart> has anyone tried to boot tribe-2 in qemu?
[05:44] <iwj> pitti: I think it's probably OK if we have a careful thing that just makes one symlink.
[05:44] <siretart> I'm getting dropped to an initramfs shell :*
[05:45] <pitti> iwj: well, it minimizes the evilness, yes :)
[05:45] <pitti> siretart: only in qemu? or also in vmware/real iron?
[05:45] <tkamppeter> Yes, it was some time told that /opt could be mounted from an application server where the local root is not root.
[05:47] <mvo> hey iwj, do you have a opinion about  bug #123757 ?
[05:47] <ubotu> Launchpad bug 123757 in dpkg "Please do not localize error messages send over --status-fd" [Wishlist,New]  https://launchpad.net/bugs/123757
[05:48] <tkamppeter> So probably I have to revise the driver design and packaging HOWTO http://www.linux-foundation.org/en/OpenPrinting/WritingAndPackagingPrinterDrivers that drivers MUST be packaged in a way that if the %install_into_opt macro in their RPM spec file (simply commenting out that line) that they MUST install and work correctly under /usr, like original distro packages.
[05:48] <pitti> tkamppeter: right, that would be helpful for all distros, i guess
[05:48] <claviola> Is there any good reason for libnspr4-dev to conflict with libnspr4?
[05:48] <pitti> tkamppeter: do you know whether, by and large, the drivers have source available?
[05:49] <tkamppeter> Yes, and this only works out where suppliers are willing to provide an SRPMs, binary-only packages often come as RPM only.
[05:49] <pitti> tkamppeter: for binary-only drivers we probably have to bite the bullet and do an /opt symlink
[05:50] <ScottK> pitti: I've done a new upload of pinentry (waiting to build now) and I think answered your comments on https://wiki.kubuntu.org/MainInclusionReportPinentry.  I'd appreciate it if you'd put it back in your queue to look at soon.
[05:50] <pitti> ScottK: I got the wiki change notification mail, will do
[05:50] <ScottK> pitti: Thanks.
[05:51] <tkamppeter> pitti, free drivers will have source available, non-free drivers can have the SRPM available (for example a package which only puts binary files together but does not compiule anything), but it can happen that only RPMs will get delivered.
[05:52] <iwj> mvo: Hi.  I saw that.  It looks really difficult.
[05:52] <iwj> I haven't checked this but AIUI the status fd error messages are just the ones from ohshit and ohshite.
[05:52] <iwj> So you'd have to send up through the status pipe the printf template and the formatted substitution values.
[05:53] <iwj> (And what if the formatted substitution values are already translated?)
[05:53] <mvo> iwj: that is my impression from the code as well, we would have to go over all of them, mark them with N_() and then on display use gettext() only for display and the original one on the pipe (does that make sense)?
[05:53] <mvo> iwj: (the impression that it would be difficult)
[05:54] <iwj> But you can't do gettext after you've done snprintf.
[05:54] <iwj> doorbell
[05:55] <iwj> back
[05:55] <iwj> Perhaps you'd like to explain your problem more fully :-).
[05:56] <mvo> iwj: I see the problem now (haven't looked at ohshit() before too closely)
[05:56] <mvo> iwj: well, the problem is that we want to generate apport bugreports for failures to install/remove etc
[05:56] <iwj> Right.
[05:57] <iwj> But you want the apport reports to be untranslated
[05:57] <mvo> iwj: and it would be good to have the reports not being localized because it makes e.g. dup finding harder
[05:57] <cjwatson> you could put a catgets-style code before each possible error
[05:57] <iwj> Niiice.
[05:57] <cjwatson> E1001: package exploded
[05:58] <mvo> iwj: and reading the report too of course :) it would be cool if apt could just drive dpkg with LANG=C, but that would mean that debconf and friends are not localized too
[05:58] <cjwatson> that wouldn't be ideal for people running apt at a terminal either
[05:58] <iwj> We could make dpkg not call setlocale.
[05:58] <iwj> I mean, optionally.
[05:59] <iwj> Or we could dual-track all of the error message handling code so that there'd always be a translated and an untranslated message.  Urgh!
[06:00] <geser> but wouldn't programms called from postinst still be localized (and their errors too)?
[06:00] <iwj> Yes.
[06:00] <cjwatson> localised errors are fairly rare there ...
[06:00] <cjwatson> well, apart from 'rm: no such file or directory' and such, I suppose
[06:50] <pitti> bdmurray, seb128, asac: do you think it would be useful if apport would add a 'apport-failed-retrace' tag to bugs which do not have an useful stack trace after retracing?
[06:51] <seb128> yes
[06:51] <seb128> it would make an easy list of bugs to triage
[06:51] <pitti> I already have report.has_useful_stacktrace(), so I can implement this trivially
[06:52] <seb128> t-hat would also allow to make stats on how many bugs are broken
[06:52] <asac> pitti: at best add mt-needretrace :)
[06:53] <asac> pitti: for all packages in realm of mozillateam ;)
[06:53] <seb128> I think that's quite a lot at the moment
[06:53] <bdmurray> pitti: that sounds good to me too
[06:53] <pitti> asac: would the MT consider using that tag instead? having multiple ones is too confusing, I think
[06:54] <asac> hmm ... cannot decide right now
[06:55] <asac> pitti: for whom would it be confusing?
[06:55] <bdmurray> asac: wouldn't the apport-failed-retrace end up replacing mt-needretrace?  or are there some cases where mt-needretrace would still get added manually?
[06:55] <pitti> asac: first, for finding the crashes which need manual traces or apport fixes, and second, I don't like hardcoding special cases about teams and source package names into apport
[06:57] <asac> pitti: bdmurray afaik there is not just black and white ... mt-needretrace would probably still be needed
[06:57] <asac> for cases where we need better
[06:57] <pitti> asac: that's fine
[06:58] <pitti> asac: I don't want you to abolish that tag, just asking whether you would get disturbed about apport-failed-retrace
[06:59] <asac> we would probably have to automatically rename it
[06:59] <asac> so go ahead and add it
[06:59] <asac> if you feel you don't want special cases
[06:59] <pitti> asac: well, if you would rename it automatically, then it would be semantically identical to mt-needsretrace; but you just said that it's for cases which need manual checks?
[07:00] <pitti> asac: we can still introduce them later if we externalize the mapping for it, but I'd rather have common tags so that other people don't need to be aware of those special cases when looking for bugs
[07:00] <asac> pitti: mt-needretrace subsumes apport-failed-retrace ... but not the other way around i guess
[07:01] <pitti> ah, right
[07:01] <asac> so renaming to mt-needretrace is safe ... while the other way might not be right.
[07:01] <asac> pitti: how can we improve backtraces
[07:01] <asac> pitti: shall i try to remove omit-frame-pointer optimization?
[07:02] <pitti> asac: is this something ffox specifically turns on in debian/rules?
[07:02] <pitti> asac: it's worth a try at least
[07:02] <asac> pitti: problem is we cannot really reproduce what your retracers do ... otherwise we would evaluate on our own
[07:02] <pitti> asac: today I fixed the Contents.gz scanning
[07:02] <asac> pitti: no its standard -O2 optimization
[07:02] <pitti> asac: i. e. things which are loaded dynamically and need extra packages now actually work :)
[07:03] <asac> ah ok ... lets wait another few days then
[07:03] <pitti> asac: hm, then I don't see why it specifically fails for ffox; it works for other packages after all
[07:03] <asac> another thing ... i get lots of signal 5 crashes?
[07:03] <asac> why that? we never had that signal before?
[07:03] <claviola> so, does anyone know if there is a good reason for libnspr4 to conflict with libnspr4-dev on feisty?
[07:03] <asac> claviola: yes
[07:03] <asac> claviola: libnspr4-dev ships files that are in libnspr4
[07:04] <pitti> asac: the other thing is bug 74691, that might be a reason, too
[07:04] <ubotu> Launchpad bug 74691 in linux-source-2.6.22 "Unable to debug under 2.6.22 on i386: Failed to read a valid object file image from memory" [High,Confirmed]  https://launchpad.net/bugs/74691
[07:04] <pitti> asac: signal 5> that's usually a glib assertion
[07:04] <claviola> asac: and why is this the case
[07:05] <claviola> like, usually it is pretty common for someone to install an accompanying -dev package...
[07:05] <asac> claviola: they don't belong together
[07:05] <asac> claviola: libnspr-dev + libnspr4
[07:05] <asac> claviola: or libnspr4-dev + libnspr4-0d
[07:05] <asac> those are the pairs
[07:06] <claviola> okay, will try.
[07:06] <asac> so for developing the transition is not really perfect
[07:06] <asac> but its old cruft we have to deal with
[07:06] <claviola> well, the thing is
[07:07] <asac> you don't need to go on
[07:07] <claviola> I'm trying to build pidgin on feisty
[07:07] <asac> its bearable for developers ... setup a chroot
[07:07] <claviola> funny thing, because this is what I'm doing.
[07:07] <claviola> and it still fails on the chroot
[07:07] <asac> the non-dev packages can be installed side by side
[07:07] <asac> claviola: yeah ... what does pidgin build-depend on?
[07:07] <claviola> because, as I was going to say, there's a conflict between libnspr4-dev and libebook1.2-dev
[07:11] <claviola> well, I guess libnss3-dev is the culprit.
[07:12] <asac> claviola: what are you trying to do?
[07:12] <asac> backport pidging to feisty?
[07:12] <claviola> yes.
[07:12] <asac> claviola: if so, you are probably best of changing build depends to libnspr-dev and libnss-dev
[07:14] <claviola> I need to read more on the changes to those two
[07:16] <asac> claviola: it should just work
[07:17] <asac> claviola: if not ping me
[07:17] <claviola> it's fine now, but it drove me nuts earlier today :P
[07:17] <asac> ok ;)
[07:18] <claviola> I just realized I'll have to setup a mini repository to host my own pidgin-dev so I can build plugins against it
[07:18] <claviola> sigh, what is an easy to maintain one? mini-dinstall?
[07:18] <asac> claviola: we have those libs in mozillateam archive
[07:18] <asac> !moztest
[07:18] <ubotu> The Mozilla-testing repos can be found at: https://wiki.ubuntu.com/MozillaTeam/PreviewArchives. Please remember these are testing repos, the packages in these repos are not stable and may break things on your system. Use with caution. Please report bugs found from these packages to: https://wiki.ubuntu.com/MozillaTeam/PreviewArchives/Bugs.
[07:19] <claviola> asac: I'll just need my own pidgin-dev package
[07:19] <claviola> now I'm just wondering about what "mini dak" to use
[07:20] <asac> just push everything to one directory and run dpkg-scanpackages and dpkg-scansources
[07:20] <thom> or just apt-ftparchive
[07:21] <asac> yeah
[07:28] <iwj> Oh, of course, I bet I've been bitten by the ginormous menu.lst bug.
[07:33] <Keybuk> iwj: collecting kernels? :p
[07:33] <pitti> my menu.list is regularly prolonged with having Ubuntus in other partitions
[07:34] <pitti> "Ubuntu, kernel 2.6.22-7-generic (on /dev/hda2) (on /dev/hda3) (on /dev/hda2)"
[07:34] <Keybuk> I just use VMware for that kind of thing :p
[07:34] <pitti> well, sometimes it's useful to test on real iron :)
[07:34] <iwj> Yes, what pitti said.
[07:35] <iwj> -rw-r--r-- 1 root root 156137 2007-07-03 18:08 /mnt/boot/grub/menu.lst
[07:35] <iwj> If it's >64K then grub crashes when it tries to show the menu.
[07:35] <pitti> erk
[07:35] <Keybuk> pitti: bah, that's what users are for :p
[07:35] <pitti> Keybuk: just gotta love your QA approach :-P
[07:36] <Keybuk> pitti: most of the testing I do tends to require unreal iron in order to replicate the bugs
[07:36] <Keybuk> it's much easier to cause race conditions in VMware
[07:37] <pitti> sure :) (I meant CD image testing, actually)
[07:38] <Keybuk> pitti: trouble with that is you're testing the install alongside an existing Ubuntu install
[07:38] <Keybuk> so you're offsetting the "real iron" with an "unusual scenario"
[07:38] <iwj> I have a caddy for that so I can do `wipe disk' installs etc.
[07:39] <pitti> yeah, but I hope that a combined vmware + real iron multi-installs will cover enough
[07:40] <pitti> iwj: getting one of these 4 GB SRAM IDE disks would be really cool for that, I think
[07:40] <pitti> boot or install Ubuntu in 20 seconds or so :)
[07:40] <kylem> it takes more than 20 seconds to boot ubuntu?
[07:40] <kylem> :)
[07:41] <Keybuk> kylem: oddly enough, I was going to say the same thing <g>
[07:41] <pitti> sad as it is, we are still quite a bit behind Windows :(
[07:41] <kylem> er.
[07:41] <kylem> really?
[07:41] <Keybuk> a fresh or little-used Windows install, maybe
[07:41] <pitti> I saw xp boot on an old 800 MHz Celeron in 30-odd seconds
[07:41] <Keybuk> not a real one
[07:41] <kylem> it takes a good minute for my machine to boot XP, versus like 15 seconds to a running gnome session.
[07:41] <Keybuk> my partner's laptop takes over three minutes to boot XP
[07:42] <pitti> Keybuk: that is the desktop system of a friend of mine
[07:42] <pitti> kylem: well, that's still faster than Ubuntu :)
[07:42] <kylem> i'd time it, but the only time i boot windows is to boot civ3, and i don't have time...
[07:42] <pitti> I disabled a lot of services, and it takes some 1:30 minutes to an usable desktop, even with autologin
[07:43] <pitti> kylem: and I don't have Windows to test, but I saw quite a few
[07:43] <kylem> dunno. in my experience, macosx is only just barely faster than ubuntu.
[07:44] <Keybuk> the gnome login time of Ubuntu is kinda interesting
[07:44] <pitti> hmm, I only used that two or three times and I wiped it years ago, I don't remember any more
[07:44] <Keybuk> I did some comparisons with F7 a few weeks back
[07:44] <Keybuk> (which is stunningly fast to login)
[07:44] <sn0> when i was in school we had risc os StrongARM based systems that booted from rom in a second :)
[07:45] <kylem> Keybuk, on a fresh install of gutsy using vesa (unsupported until about 5 minutes from now) on my 3ghz c2d box, gnome starts moments after i finish my password... no splash screen.
[07:45] <Keybuk> I know that they're shiny, but do we really need 2.5MB of default desktop background and startup sound?
[07:45] <Keybuk> kylem: it shouldn't, there's a lot of cruft we load
[07:45] <kylem> Keybuk, seriously...
[07:45] <Keybuk> why no splash screen?
[07:45] <Keybuk> we haven't disabled that yet?
[07:46] <Keybuk> (oddly, the splash screen itself adds about 1.5s to the login time)
[07:46] <kylem> Keybuk, because the desktop loads so damned fast.
[07:46] <mjg59> Gnome is very fast to start up, assuming a warm cache
[07:46] <Keybuk> kylem: you disabled it yourself?
[07:46] <mjg59> It's entirely the i/o that's killing us
[07:46] <Keybuk> mjg59: not entirely
[07:46] <Keybuk> the fact we're using far more I/O than we need to is a major factor
[07:46] <ion_> AFAIK Windows rearranges HDD blocks to boot faster and load oftenly used software faster.
[07:46] <ijuz__> on my shinny new laptop Vista (without _anything_ installed) takes 35sec from grub to login and additional 15 sec for login
[07:46] <mjg59> Keybuk: If I log out and then log in on a 1.2GHz machine, I'm at a desktop in a couple of seconds
[07:46] <Keybuk> and the fact we load huge amounts of Python (multiple python interpreters) in our default login doesn't help either
[07:47] <Keybuk> mjg59: sure, because the big bits are cached <g>  I'm not saying a warm cache doesn't help; I'm saying that we can be much faster with a cold cache than we are
[07:48] <mjg59> Keybuk: Uhm. Isn't that what I said?
[07:48] <Keybuk> mjg59: no, you said it's entirely the i/o - which it isn't
[07:48] <pitti> mjg59: right, second gnome login is fast here, too
[07:48] <Keybuk> I put together a login that's faster on a cold cache than our default is on a warm cache
[07:48] <Keybuk> so it's not entirely cache
[07:49] <mjg59> Keybuk: The warm cache case is sufficiently fast that it's not a problem. 
[07:49] <Keybuk> mjg59: the warm cache is sufficiently rarely seen that it *IS* a problem
[07:49] <Keybuk> people primarily login on a cold cache
[07:49] <Keybuk> because they've just booted their machine
[07:49] <mjg59> Yes. But we're not spending time on the CPU, we're spending time in i/o
[07:49] <Keybuk> they tend to logout when they're rebooting it or turning it off
[07:49] <mjg59> So we need to reduce the i/o
[07:49] <Keybuk> we're spending a lot of time in both actually
[07:49] <Keybuk> lots of Python uses the CPU a bit
[07:49] <mjg59> No, because we can log in from a warm cache in a couple of seconds
[07:50] <mjg59> The contribution of CPU time is tiny compared to the amount of time spent in i/.o
[07:50] <Keybuk> but we never login from a warm cache
[07:50] <Keybuk> it's cold ;)
[07:50] <mjg59> Keybuk: Yes. But even if we spent no time on the cpu, the best we could save (on a slow machine) is a couple of seconds
[07:50] <Keybuk> ?
[07:51] <Keybuk> have you compared Ubuntu and F7
[07:51] <Keybuk> the difference is quite staggering
[07:51] <Keybuk> even on slow hardware
[07:51] <mjg59> Keybuk: The amount of time spent in cpu is independent of whether something is in cache or not, right?
[07:51] <Keybuk> right
[07:51] <ion_> F7? Fedora Core?
[07:51] <mjg59> So, if I can log in in two seconds from a warm cache, the amount of time spent in cpu cannot be more than 2 seconds
[07:51] <Keybuk> ion_: Fedora 7
[07:51] <Keybuk> mjg59: indeed; but we can reduce that to near-zero seconds
[07:52] <mjg59> If we reduced that time to 0, the most we could remove from the login time would be 2 seconds
[07:52] <ion_> Whats the difference? I.e. which one is faster?
[07:52] <Keybuk> mjg59: err? we could remove more
[07:52] <mjg59> But I'm spending 20 seconds in i/o
[07:52] <mjg59> Keybuk: Only if I can log in in negative time
[07:52] <Keybuk> ?
[07:52] <mjg59> Keybuk: Total CPU time spent during login, regardless of whether the cache is warm or not, is two seconds
[07:53] <mjg59> So reducing the amount of CPU time used cannot reduce the amount of time taken to log in by more than two seconds
[07:53] <Keybuk> yes
[07:53] <iwj> Keybuk: This USB modem is a Conexant softmodem :-(.  Looks like we should be telling people to get a USB serial dongle and a real modem.
[07:53] <mjg59> So we're dominated by i/o, not cpu use
[07:53] <Keybuk> yes, the majority of time is i/o
[07:53] <iwj> Shame you can't discover this before you buy it.
[07:53] <mjg59> We can either improve throughput (by reducing seeking) or reduce the number of programs started
[07:53] <Keybuk> you said "entirely" :-)
[07:54] <Keybuk> we can also reduce the I/O by reducing the size of some of the files we load simply for effect
[07:54] <Keybuk> (startup sound, desktop background, etc.)
[07:54] <mjg59> Keybuk: Two seconds is within the noise threshold for a typical login for me
[07:54] <mjg59> And 2.5MB is still only about 0.1 of a second
[07:54] <ogra> iwj, just carry a liveCD with you to the shop ... and ask if you can test it ...
[07:54] <Keybuk> ?
[07:55] <iwj> ogra: Mmm.
[07:55] <ogra> in good shops that usually works
[07:55] <mjg59> Keybuk: My (1.8") drive is capable of over 20MB/sec
[07:55] <Keybuk> so you think we load about 500MB on gnome login?
[07:55] <mjg59> Keybuk: No, I think the majority of the time is spent seeking
[07:55] <iwj> ogra: Except we don't really have such things in Cambridge.  Either very upmarket shops or the likes of Maplin.  I normally do everything mail order.
[07:55] <mjg59> Which isn't a problem when you're talking about two files
[07:56] <iwj> Hmm.  I wonder if this can be made to work with sl-modem-daemon.
[07:56] <mjg59> iwj: The Conexant ones? Not as far as I know.
[07:56] <Keybuk> perhaps, but by shrinking those and removing a couple of things from the autostart, I reduced my cold cache startup time to <5s
[07:56] <ogra> iwj, yeah, it's indeed hard to test in advance that way :)
[07:56] <Keybuk> (from about 20s)
[07:56] <mjg59> Keybuk: If the background and startup sound are adding significant time to login, that indicates a bug we should fix rather than anything else
[07:56] <iwj> mjg59: It's a conexant-based USB thing.
[07:56] <mjg59> iwj: Yes
[07:57] <iwj> Hmm.
[07:57] <mjg59> Linuxant provided drivers at some point, I believe
[07:57] <iwj> Yes, they still do I think.
[07:57] <mjg59> Certainly for the Apple ones
[07:57] <iwj> Payware.
[07:57] <iwj> I bet they work with this too but I think testing that is a bit out of scope.
[09:10] <RainCT> Hey, a little question. Is it ok to create a page in wiki.ubuntu.com about a program I'm creating if it's not directly Ubuntu related?
[09:17] <LaserJock> cjwatson: got a minute now? :-)
[09:17] <axxo> i have a full hour!
[09:27] <asac> any idea how i can get the same affect as physically unplugging and plugging in an usb device programmatically from userspace?
[09:29] <pitti> StevenK: erk, libcurl3-gnutls has files from old libcurl4-gnutls, but doesn't Conflicts:/Replaces: it
[09:39] <asac_> i was offline ... in the unlikely case that anyone answered my usb question ... please repeat :)
[09:40] <Kmos> anyone answered
[09:41] <pitti> Kmos: no, nobody did
[09:41] <pitti> ^ asac_ 
[09:41] <pitti> asac_: I might have an idea, let me try
[09:41] <asac_> pitti: but you certainly know, right ;)
[09:42] <asac_> like echo 1 > /....
[09:42] <asac_> :)
[09:44] <pitti> asac_: this works for me:
[09:44] <pitti> cd /sys/block/sda/device/driver; echo -n '1:0:0:0' | sudo tee unbind; echo -n '1:0:0:0' | sudo tee bind
[09:44] <asac_> samn ... what does that do?
[09:45] <asac_> damn
[09:45] <pitti> asac_: sda is the block device you want to 'replug'
[09:45] <Kmos> pitti: crazy geek
[09:45] <Kmos> lol
[09:45] <pitti> asac_: and '1:0:0:0' is the single directory in /sys/block/sda/device/driver/
[09:45] <asac_> ok lets see ;) if i can project that for my case
[09:46] <pitti> asac_: it essentially tells the driver (which is the sd module in this case) from unbinding and binding to the device 1:0:0:0 (on the USB bus, which is sda here)
[09:46] <pitti> s/from unbinding/to unbind/
[09:46] <asac_> its not a block device though
[09:46] <asac_> some mtp device (ouch)
[09:47] <pitti> asac_: if I do that here, I get the automount magic back
[09:47] <pitti> asac_: doesn't matter, you just need a convenient way to find the device in /sys
[09:47] <pitti> asac_: what's mtp?
[09:47] <asac_> http://libmtp.sourceforge.net/
[09:47] <asac_> mtp is an implementation of Microsoft's Media Transfer Protocol (MTP)
[09:48] <pitti> asac_: look in /sys for the various groupings of devices (by block device, bus, kernel module name, etc.)
[09:48] <asac_> sucky mp3 player
[09:48] <pitti> asac_: aah, that's more or less raw USB
[09:48] <asac_> that cannot be reset/closed by libusb
[09:48] <pitti> asac_: well, just try unload and reload the particular USB module
[09:48] <asac_> it works pretty well, but once you try to release it it will not get back to a usable state
[09:49] <pitti> asac_: unloading a module is often bad, though, which is why unbinding/rebinding is better
[09:49] <asac_> ehci_hcd is the only module used
[09:49] <asac_> no idea if its good to do that
[09:49] <pitti> asac: rmmoding that will kill *all* your USB devices
[09:49] <asac> pitti: ok how can i find the proper device node? does lsusb help?
[09:49] <pitti> or, it won't even work
[09:49] <asac> yeah
[09:50] <asac> thats what i thought
[09:50] <pitti> asac: lsusb might help
[09:50] <pitti> asac: then look in /sys/bus/usb/devices/ for the device number
[09:52] <pitti> asac: /sys/bus/usb/devices/<usb port number>/driver/ -> there you have the driver for that device again
[09:53] <asac> let me see .... :)
[09:54] <asac> pitti: http://paste.ubuntu-nl.org/28389/
[09:55] <asac> on top is lsusb -t of that device
[09:55] <asac> how do i figure the port number ... i can guess which one it is
[09:55] <asac> but ...
[09:56] <asac> i would guess that its 1-1
[09:57] <sladen> StevenK: your libcurl*-{,gnutls} uploads are barfing on install
[09:58] <pitti> asac: hm, just check */idVendor and */idProduct for your device
[09:59] <RainCT> nobody knows if it's ok to create a page in wiki.ubuntu.com about a program that is not directly Ubuntu related?
[09:59] <pitti> RainCT: in general, wiki.u.c. should have Ubuntu related things
[10:00] <sladen> RainCT: the page would make sense if it's about using that program on ubuntu
[10:01] <RainCT> ok, thanks. do you know of any other open source related wiki where I could create a page for that purpose then?
[10:08] <sladen> RainCT: what's the program you had in mind?
[10:08] <sladen> RainCT: there are likely to be wiki's (eg. audio, graphics, GNOME, KDE) where the page would fit neatly
[10:26] <RainCT> sladen: https://launchpad.net/qttube
[10:29] <sladen> RainCT: that's an interesting issue.  currently launchpad is semi-hardcoded to point to (a particular) external wiki
[10:32] <RainCT> sladen: so do you know any wiki where I could create a page for that program?
[10:35] <mruiz> hi all
[10:49] <holycow> hi guys
[10:59] <LaserJock> lifeless: what is the conflict checker specifically checking for?
[10:59] <lifeless> missing conflicts:/replaces: stanzas
[10:59] <lifeless> LaserJock: across tim
[11:00] <lifeless> *time*
[11:00] <LaserJock> ahhh
[11:00] <lifeless> two packages with the same file must do one of: divert, conflict, or replace.
[11:01] <LaserJock> I noticed a bunch of tex related ones
[11:02] <LaserJock> lifeless: will those cause dpkg errors when upgrading?
[11:03] <lifeless> LaserJock: some of them will; some of them wont because we lie to dpkg when its used from apt/synaptic