[02:17] <Hobbsee> morning all
[02:34] <calc> Hobbsee: hi
[02:34] <Hobbsee> hey calc, how's it going?
[02:36] <calc> Hobbsee: doing pretty good, still haven't finished closing on my condo :\
[02:36] <Hobbsee> awww
[02:36] <calc> found out my bank screwed up so i can't even get bank statements for the past 2 years due to some weird account crap they pulled on me
[02:36] <calc> but they are going to send a letter to my lender to clear up anything
[02:36] <calc> so whatever works :)
[02:37] <Hobbsee> heh
[02:53] <keescook> evenin' folks.  time for some dinner.  :)
[03:00] <ajmitch> hey keescook 
[05:17] <persia> Could I ask an archive-admin to forcibly reject webboard 0.2.1-0ubuntu4 before it is compiled and released?  I'd like to release a replacement -0ubuntu4 instead (and maintain a clean changelog).  Apologies.
[05:18] <Hobbsee> persia: just upload another
[05:18] <Hobbsee> dont think the archive admisn are awake
[05:19] <persia> Hobbsee: OK.
[07:22] <pitti> Good morning
[07:22] <Burgundavia> morning pitti
[07:24] <Mithrandir> morning, pitti 
[07:26] <Hobbsee> hey pitti, Mithrandir 
[07:30] <Mithrandir> morning, Hobbsee 
[07:31] <Hobbsee> morning :)
[07:34] <Hobbsee>  00:34:01 up 18:22,  1 user,  load average: 3.70, 3.07, 2.37
[07:34] <Hobbsee> so far
[07:35] <Hobbsee>  00:35:16 up 18:23,  1 user,  load average: 4.10, 3.33, 2.51 once it properly starts
[07:35] <Mithrandir> just build more of them?
[07:35] <Hobbsee> that's with 3 at once
[07:36] <Hobbsee> 8 done, or almost done, 10 more to do.
[07:36] <ajmitch> morning Mithrandir 
[07:52] <ubotu> Launchpad bug 110724 in openoffice.org "OpenOffice runs as root for all users" [Undecided,Rejected]  https://launchpad.net/bugs/110724
[07:53] <ajmitch> pitti: it is a bit crazy, isn't it?
[07:53] <Hobbsee> pitti: is that another bug for the wall of shame?
[07:53] <pitti> a proprietary Samsung printer driver which chmod u+s soffice.bin? That's *hilarious*
[07:53] <pitti> Hobbsee: indeed, fortunately not our wall
[07:53] <pitti> I don't want to know what crazy stuff 3rd party drivers do on windows
[07:54] <Hobbsee> heh
[07:54] <Hobbsee> pitti: https://bugs.launchpad.net/ubuntu/+bug/116344 was the first candidate, if you were wondering.
[07:54] <ubotu> Launchpad bug 116344 in Ubuntu "Sifilinaptic Package Error for 3 days" [Undecided,Rejected]  
[07:55] <racarr> I still love that
[07:55] <pitti> Sifilinaptic?
[07:56] <racarr> Synaptic was with a gentoo package frontend and caught a rather unpleasant bacterial infection?
[07:56] <racarr> bad pun :/
[07:57] <pitti> Hobbsee: well, I'd still not throw 'PEBCAK' at reporters; they might have used automatix and such, which is still PEBCAK, but on a level where they cannot relate it to the bug any more :-/
[07:57] <Hobbsee> pitti: i only did due to the arrogance of the bugreporter.
[07:57] <Hobbsee> when you're going to be that rude, then no, sorry, you're not going to get much of a reply
[07:57] <pitti> I agree, it was a stupid report
[07:57] <Hobbsee> and the actual part of that bug is already filed
[07:58] <pitti> Hobbsee: oh, what was it? a proprietary Canon printer driver this time? :-P
[07:59] <Hobbsee> no, that synaptic is dying over a malformed repository, rather than just ignoring it
[07:59] <Hobbsee> and giving an unclear "file a bug" warning
[07:59] <pitti> ah, right; I meant, is it actually known what adds 'sudo' lines to sources.list?
[08:00] <pitti> heh
[08:00] <Hobbsee> haha
[08:00] <pitti> 'Use case: if you cannot configure your system in a rescue root shell, you do not deserve to.'
[08:01] <StevenK> Actually, echo sudo >> /etc/apt/sources.list won't work, since the shell will try and open sources.list for writing and fail.
[08:01] <StevenK> It could be a botched script.
[08:01] <racarr> Yeah. You have to use tee
[08:01] <Hobbsee> i did wonder if it was tee.  that was the other one coming to mind
[08:01] <ajmitch> StevenK: blame automatix?
[08:01] <pitti> StevenK: that's what I was afraid of; there might be some automatix-like thing which screws it up
[08:01] <pitti> that's why I'm interested in finding dups of that
[08:01] <StevenK> pitti: Yup.
[08:02] <Hobbsee> yay, automatixcrack.
[08:02] <pitti> that reminds me...
[08:02] <tepsipakki> automatix et al should just use /etc/apt/sources.list.d/ ..
[08:04] <tepsipakki> why not make sources.list read-only and force people to put other stuff in .d :)
[08:05] <Hobbsee> haha
[08:07] <ajmitch> tepsipakki: immutable, or hard-coded?
[08:09] <tepsipakki> ajmitch: hmm, what's the difference there?
[08:16] <ajmitch> tepsipakki: immutable being change by chattr
[08:19] <tepsipakki> ok, immutable then.. but don't take that too seriously ;)
[08:21] <minghua> I bet you'll get a flood of bugs with a read-only immutable /etc/apt/sources.list
[08:21] <ajmitch> back later
[08:23] <tepsipakki> or, reverse the logic; put distro-sources in s.l.d, and leave sources.list empty for the user :)
[08:41] <dholbach> good morning
[09:11] <dholbach> who of you would be interested in doing ubuntu-dev mentoring?
[09:11] <dholbach>  it'd be nice to have some mentors available once I announce the new mentoring process
[09:45] <Hobbsee> !logs
[09:46] <ubotu> Channel logs can be found at http://people.ubuntu.com/~fabbione/irclogs
[09:59] <pitti> hi seb128
[09:59] <seb128> hey pitti!
[10:00] <pitti> seb128: ah, http://merges.ubuntu.com/d/dbus/dbus_1.0.2-5.patch now separates the dbus Xsession.d script; that should get us rid of a few bugs :)
[10:01] <seb128> pitti: cool ;)
[10:02] <pitti> mvo: can you please remove the dbus-1-utils dependency from update-notifier? the package is going away (merged into dbus itself)
[10:03] <dholbach> hey seb128
[10:03] <seb128> hi dholbach
[10:04] <Hobbsee> TB meeting looks interesting.
[10:05] <mvo> pitti: sure
[10:07] <dholbach> hahaha... http://launchpad.net/~ubuntu-clusterfuck
[10:07] <dholbach> awesome
[10:09] <highvoltage> hehe
[10:09] <dholbach> hey highvoltage
[10:09] <highvoltage> good morning dholbach 
[10:09] <dholbach> highvoltage: I updated reception-data (with input of persia and TheMuso)
[10:11] <highvoltage> dholbach: excellent. I saw in the diffs that were emailed by launchpad.
[10:11] <dholbach> super
[10:20] <mvo> pitti: the retracer seems to ignore #101926 (need-i386-retrace is set). could you please have a look?
[10:25] <mvo> pitti: same for #81048 (but that one is probably too old :)
[10:26] <seb128> bug #101926
[10:26] <ubotu> Launchpad bug 101926 in update-notifier "update-notifier_apt-check" [Undecided,Confirmed]  https://launchpad.net/bugs/101926
[10:26] <pitti> mvo: ValueError: URL does not contain DistroRelease: field
[10:26] <pitti> 05/21/07 09:42:55: retracing bug 101926 exit status: 1
[10:27] <seb128> mvo: not sure if it works with the monolithic format
[10:27] <pitti> mvo: same for 81048
[10:27] <pitti> no, it doesn't work with the edgy format
[10:27] <seb128> pitti: that's not the edgy format, that's people attaching the crash file from /var/crash rather than using apport to send the bug I think
[10:27] <mvo> ok, thanks
[10:28] <cjwatson> pitti: apport 0.80 changelog> POSIX sh should have '.'
[10:31] <seb128> Hobbsee: nice changelog entry on bug #115538 :p
[10:31] <ubotu> Launchpad bug 115538 in dealer "Please sync dealer (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/115538
[10:31] <dholbach> hehe
[10:31] <Hobbsee> seb128: haha, yes.  i blame debian.
[10:31] <seb128> ;)
[10:32] <Hobbsee> seb128: fix debian, kthxbye.
[10:32] <seb128> Hobbsee: I'm doing the sync no need to bother ;)
[10:32] <Hobbsee> seb128: hehe.  you appear to trust me. strange person :P
[10:33] <Hobbsee> seb128: and i do kde stuff.
[10:34] <Hobbsee> seb128: and i'm different from everyone else, so couldnt be expected to be rational :P
[10:34] <Mithrandir> shouldn't you be a blue alien then?
[10:34] <pitti> cjwatson: right, that seems to be a quirk of zsh; I quickly changed this when siretart used that script on his server, and now I fixed it harder
[10:34] <cjwatson> pitti: I would advise ignoring bugs due to using zsh as /bin/sh - that's definitely not recommended
[10:35] <Hobbsee> Mithrandir: azure :P
[10:35] <cjwatson> bash really shouldn't be needed just for ''
[10:35] <Hobbsee> Mithrandir: there are no other green aliens, anyway
[10:35] <cjwatson> '.'
[10:36] <siretart> cjwatson: I don't have /bin/sh -> /bin/zsh. I only executed that script
[10:36] <pitti> siretart: well, we copy&pasted commands from it to your sh
[10:36] <siretart> yeah
[10:37] <cjwatson> siretart: but you ran the script with zsh, right?
[10:37] <siretart> indeed
[10:38] <cjwatson> http://www.opengroup.org/onlinepubs/009695399/utilities/dot.html mandates '.' in a sh implementation - if zsh doesn't understand it, that's zsh's problem
[10:39] <cjwatson> I didn't think zsh really claimed POSIX sh compatibility though
[10:39] <siretart> hmm. it seems that zsh's '.' command expects a full pathname to the script to source, and doesn't like it in the current directory
[10:39] <siretart> '. .alias' fails, but '. ~/.alias' works
[10:40] <cjwatson> ah, now that is actually a bash bug I think - '.' is supposed to use $PATH, not the current directory
[10:40] <siretart> according to your link, '.' is supposed to look in $PATH. I surely don't have '~' in my path
[10:41] <cjwatson> so if apport's relying on cwd, it should use '. ./file'
[10:41] <siretart> interesting
[10:41] <siretart> which would work in zsh as well :)
[10:42] <jmg> hey all whatever happened about upstart replacing cron?
[10:43] <siretart> jmg: that needs to be implemented in upstart. there has been a discussion on the upstart mailing list about that
[10:49] <pitti> siretart: hm, that's a really weird and nonintuitive thing, using $PATH for command line arguments
[10:50] <pitti> yay for Unix consistency :)
[10:50] <siretart> pitti: seems to be a unix standard however.. I admit that this is news to me
[10:51] <pitti> siretart: hm, in this case I agree with bash TBH; sourcing something that could be anywhere in $PATH seems actively dangerous and error prone to me
[10:52] <pitti> hm, bash still looks at $PATH for the argument, though
[10:52] <siretart> pitti: I can imagine that there is somewhere a switch for zsh to enable this behavior
[10:52] <siretart> aah, so bash just 'adds' '.' to the $PATH for sourcing? that's nasty
[10:53] <siretart> does bash prepend or append '.' to $PATH for '.'?
[10:53] <pitti> no
[10:53] <pitti> erm, sorry
[10:53] <pitti> siretart: append
[10:53] <siretart> wow
[10:54] <siretart> this smells really fishy
[10:55] <cjwatson> pitti: '.' is analogous to normal command execution
[10:55] <cjwatson> IMO
[10:55] <pitti> hm, then we seem to have a completely different view about what sourcing is supposed to do
[10:56] <mvo> is librarianl.lp.net not working currently?
[10:56] <cjwatson> "execute the stuff in that file in the context of the current shell" is how I think of it
[10:56] <pitti> I have always regarded it as kind of #include for shell
[10:56] <pitti> and had expected to give a path to a file name to it, not a command
[10:57] <cjwatson> well, the path you give it doesn't have to be executable
[10:57] <pitti> right
[10:58] <cjwatson> I know of some things that rely on . looking in $PATH to useful effect
[10:58] <cjwatson> e.g. '. gettext.sh'
[11:04] <pitti> tkamppeter: ghostscript FTBFSed again, still stumbling over gtk
[11:05] <seb128> pitti: what?
[11:05] <pitti> seb128: don't worry, gtk is fine, it just complains about not finding the gtk .pc (it doesn't build depend on gtk-dev and isn't meant to)
[11:05] <seb128> ah, k
[11:06] <seb128> :)
[11:10] <tkamppeter> pitti, I have seen the Ghostscript problem. It is an upstream problem of the original GPL GS not being able to be compiled as libgs without GTK. ESP GS had fixed it and now I am moving this fix to upstream. Then I will make the Ubuntu package with an updated upstream tarball.
[11:11] <pitti> mvo: argh, u-n has a versioned depends on dbus-1-utils, so the Provides: won't be enough
[11:12] <Mithrandir> tkamppeter: are you upstream for ghostscript?
[11:14] <mvo> pitti: I will upload a new u-n today, I think the -1-utils is really no longer needed
[11:14] <pitti> mvo: right, and the next dbus will have dbus-monitor anyway
[11:15] <pitti> mvo: today would be good, then I'll wait with the NEWing until that happened
[11:21] <pitti> seb128: yay, things work well without the dbus Xsession.d script
[11:22] <seb128> \o/
[11:22] <pitti> seb128: I'll add a preinst transition bit that removes an unmodified script on upgrade
[11:22] <seb128> pitti: GNOME works fine, but how is that going to work for other environments?
[11:23] <pitti> seb128: they need to depend on dbus-x11
[11:23] <seb128> ok
[11:23] <pitti> Riddell, Hobbsee: do you know whether KDE needs a session dbus, and if so, will it start one by itself? or does it need /etc/X11/Xsession.d/75dbus_dbus-launch?
[11:23] <mvo> pitti: ok, I wil ldo it before lunch
[11:24] <Hobbsee> :)
[11:25] <pitti> Hobbsee: an experiment: just move this script away, log into KDE and check whether things are still working
[11:25] <Hobbsee> yay, double hug!
[11:25] <pitti> Hobbsee: at least in Gnome things work better than before
[11:25] <pitti> Hobbsee: or, simply check 'ps ux | grep dbus' whether you have a session dbus running
[11:25] <pitti> (before and after moving the script)
[11:28] <tkamppeter> Mithrandir, yes, I have gotten SVN write access, as I was also developer of ESP Ghostscript (ESP GS was by 95 % done by Mike Sweet and me) and so with the ESP GS merger Mike and me got also merged into GPL GS.
[11:30] <Riddell> pitti: KDE 3 doesn't seem to need it, and I can't think why it would need it.  KDE 4 I'm almost certain will need it, I'm not sure if it has a way of starting it itself
[11:30] <Riddell> pitti: why don't you want the dbus Xsession.d script?
[11:32] <pitti> Riddell: if dbus is started from gnome, it gets some additional environment variables that some programs rely on
[11:32] <pitti> Riddell: such as gnome-power-manager recognizing the keybindings for the power off button etc.
[11:32] <pitti> Riddell: this is of course a bug in those apps, but it's easier to fix like this
[11:33] <pitti> Riddell: if KDE4 needs it and doesn't start one on its own, we just need to add dbus-x11 to kubuntu-desktop, or make it a dependency of, say, kdebase
[11:33] <mvo> pitti: can bug #61730 be closed now? 
[11:33] <ubotu> Launchpad bug 61730 in update-notifier "No indication to the user that a core dump is in progress" [Low,Confirmed]  https://launchpad.net/bugs/61730
[11:33] <Riddell> pitti: and that brings in the Xsession.d/75dbus_dbus-launch script?  won't that then break gnome again?
[11:34] <pitti> Riddell: yes, for the case that someone installs both KDE and Gnome in parallel
[11:34] <pitti> Riddell: as I said, it's not a good solution, but a quick one, and Debian split out the package, so I'd like to follow that
[11:35] <Riddell> ok
[11:37] <Riddell> ah, that is the 75.. script
[11:47] <gon> hellllllllo
[11:48] <seb128> Hobbsee: isn't the gtk2-engines-gtk-qt transitionnal package required for dapper upgrades?
[11:49] <Hobbsee> seb128: errr....i'm not sure, i'd have to check that
[11:50] <Hobbsee> seb128: yes.  damn.
[11:50] <Hobbsee> didnt think of that
[11:51] <seb128> Hobbsee: I've removed the binary from gutsy for now since it's not longer built from the source package
[11:51] <seb128> feel free to add it again if it's required
[11:51] <Hobbsee> seb128: right. 
[11:51] <seb128> Provides should really be versionned
[11:51] <Hobbsee> seb128: would have thought a replaces: on the engines gutsy package would suffice, no?
[11:52] <seb128> so we would not have to keep all those dummy packages only for upgrades
[11:52] <Hobbsee> er, with the dapper version, presumably?  or the version where it changed?
[11:52] <seb128> Hobbsee: well, it'll not install gtk-qt-engine when you try to update gtk2-engines-gtk-qt on dapper
[11:52] <pitti> seb128: we need dummy packages for upgrades anyway, regardless of versioned provides
[11:52] <seb128> pitti: why?
[11:53] <pitti> until the next LTS
[11:53] <seb128> right, because Provides are not versionned
[11:53] <pitti> seb128: if you have a installed, and then a is removed from the archive and b Provides: a, then apt- won't automatically install b
[11:53] <Hobbsee> pitti: then surely that's a bug in apt?
[11:53] <pitti> Hobbsee: not really IMHO
[11:54] <pitti> Hobbsee: first, it would be pretty expensive to guess which package to install, and also pretty error prone
[11:54] <Mithrandir> pitti: I doubt you'll be able to upgrade without using the dist-upgrader, but no need to make it harder than we have to.
[11:54] <seb128> pitti: that's because the provides is not newer than the real package because it's not versionned, no?
[11:54] <pitti> Hobbsee: for example, if there are several replacements
[11:54] <Hobbsee> good point
[11:54] <Mithrandir> Hobbsee: that'd break if I had, say, a custom mta installed locally and apt would continually try to install another one because it didn't see my custom one in a repo.
[11:54] <pitti> seb128: no, an upgrade will update the versions of installed pacakges, not install new packages out of thin air
[11:55] <pitti> seb128: right, that too
[11:55] <seb128> pitti: so the problem is not the versionning, is that we need a new field "deprecates"
[11:55] <pitti> seb128: with versioned provides, apt could grab the latest available one, but I'm not sure whether this woudl break anything else
[11:55] <seb128> which means "install that package instead of this old one"
[11:56] <seb128> I think it's stupid to create zillion of dummy packages for that
[11:56] <pitti> seb128: and if two packages deprecate the old one?
[11:56] <Keybuk> I'm going to modify bzr to send the bazaar folks an e-mail, instead of nagging me about bzr-gtk being out of date
[11:56] <seb128> that should really we a package field
[11:56] <pitti> seb128: well, keeps us from renaming more pacakges than we really have to :)
[11:56] <Hobbsee> Mithrandir: point
[11:56] <seb128> pitti: don't use the "deprecate" then
[11:56] <seb128> pitti: there is plenty of case where we keep a dummy package just for upgrade
[11:56] <pitti> seb128: it should be something that points from the old package to the new one, not the other way round
[11:56] <seb128> that's cluttering the apt index, the archive, etc
[11:57] <pitti> seb128: I agree
[11:57] <seb128> pitti: the old package you can't update
[11:57] <seb128> usually you upload new packages, not old ones ;)
[11:57] <pitti> right, that's why we currently use transitional packages :)
[11:57] <pitti> whoops
[11:57] <seb128> which sucks
[11:58] <pitti> well, it's the renaming of packages that sucks
[11:58] <seb128> I don't get what why a new "deprecates" would not work
[11:58] <pitti> if it would be made easier, it would happen a lot more often, I figure, and create more problems
[11:58] <pitti> seb128: if it would be used carefully, it certainly would
[11:58] <seb128> you can create mess with transitional packages as well
[11:59] <pitti> seb128: and you don't even need a new field for this; C/R/P is meant for this purpose
[11:59] <pitti> you just need to teach apt to automatically replace those
[11:59] <seb128> well it doesn't work
[11:59] <pitti> but I can think of use cases where this would break
[11:59] <pitti> (alternatives, like gs-esp vs. gs-gpl or so)
[11:59] <seb128> if you have gaim on edgy and apt-get install gaim with gutsy source it'll not install pidgin without a transitional package
[12:00] <seb128> right
[12:00] <seb128> it'll would be mainly for renaming
[12:00] <seb128> not for packages replaced by something else
[12:01] <pitti> still, having a transitional package in debian/control instead of a new field isn't that much more work IMHO
[12:02] <seb128> no, it's just ugly and increase apt index noise
[12:02] <pitti> right
[12:04] <Keybuk> it's an utter arse if you ever want to rename back though
[12:04] <Keybuk> the trouble with transitions like that is that they are permanent
[12:04] <Keybuk> consider the esd/polypaudio crack change
[12:06] <pitti> Hobbsee: well, LTS->LTS upgrades are kind of an important use case
[12:06] <Hobbsee> true
[12:06] <highvoltage> LTS is a touchy and difficult subject.
[12:06] <pitti> but in gutsy+1 we can drop a *lot* of transition bits :)
[12:06] <Hobbsee> :D
[12:06] <pitti> s/in/after/
[12:07] <Hobbsee> highvoltage: how so, in particular?  i wasnt aware of anything beyond a "having to keep all the transitional packages" POV
[12:07] <Keybuk> pitti: no, we can't
[12:07] <Keybuk> since gutsy+1 is the LTS, it needs all the transitions bits
[12:07] <Keybuk> we can drop some in gutsy+2
[12:07] <pitti> Keybuk: <pitti> s/in/after/ :)
[12:09] <pitti> Hobbsee: I agree, keeping the transitional bits for so long is the main pain ATM; the rest is mainly political, I guess ;)
[12:16] <Hobbsee> oh well, i know for next time, at least.
[12:23] <pitti> Rejected:
[12:23] <pitti> Unhandled exception processing upload: HTTP Error 502: Proxy Error
[12:23] <pitti> ??
[12:24] <pitti> seb128: you recently saw something like this as well, right?
[12:24] <seb128> pitti: yeah, syncing was broken this way and it automagically fixed (or somebody did)
[12:25] <seb128> pitti: oh, no, that was Bad Gateway for me
[12:25] <seb128> you get that when uploading?
[12:26] <pitti> seb128: yes
[12:27] <tkamppeter> pitti, new 0ubuntu3 ghostscript packages are uploaded to the usual place. They contain the needed upstream fix. Can you please upload them? Thanks.
[12:27] <pitti> tkamppeter: sure
[12:31] <pitti> tkamppeter: hm, the changelog says 'new upstream release', but it's actually not
[12:31] <pitti> tkamppeter: it's -0ubuntu3 and uses the same orig.tar.gz as before, and no debian/patches/svn-fixes.diff either
[12:31] <Mithrandir> hi adilson
[12:32] <agoliveira> Mithrandir: good morning
[12:36] <dholbach> can I tempt anybody to join the ubuntu-dev mentors? I'd like to announce the new process soon and it'd be nice to have some more people who are willing to take on contributor or two and help them on their first steps :)
[12:38] <tkamppeter> pitti, the source tarball is a new SVN snapshot, only the name is the same. I have replaced the _source.changes file by one with "-sa" now.
[12:39] <pitti> tkamppeter: that doesn't work, you have to bump the version name
[12:40] <pitti> indeed, the .dscs for ubuntu2 and 3 have a different md5sum for the orig.tar.gz
[12:40] <pitti> tkamppeter: the old orig.tar.gz is already in the archive, it cannot be overwritten with a new one
[12:40] <tkamppeter> pitti, so I have to change the upstream version name for a new SVN release. How are the conventions, so that I can start over with the right versioning scheme?
[12:40] <pitti> tkamppeter: if the changes are relatively small, doing the svn fixes in debian/patches might be preferable
[12:41] <pitti> tkamppeter: the other convention would be something like 8.60.dfsg.2 or 8.60.dfsg.1+svn20070523
[12:41] <pitti> tkamppeter: the latter is more common, but since the old orig.tar.gz has an distro specific suffix anyway (.1) you could just as well increase that
[12:42] <tkamppeter> And if I go for 8.60.dfsg.1+svn20070523 how should I name the final 8.60 release?
[12:43] <pitti> tkamppeter: hmm
[12:43] <pitti> tkamppeter: in retrospective, you should have used 8.60.dfsg~beta1 or so
[12:44] <pitti> tkamppeter: now, just going to .2 should be fine
[12:44] <pitti> tkamppeter: oh, btw, what did you have to remove for DFSG compliance?
[12:45] <tkamppeter> So then I will take 8.60.dfsg.1+svn7997 for now and 8.60.dfsg.2 for final?
[12:45] <tkamppeter> This is already done by the Debian folks, they remove Resource/Cmap because they consider that non-free.
[12:49] <pitti> tkamppeter: sounds good
[12:49] <pitti> tkamppeter: ah, is that a binary file without source, or sth. like that?
[12:50] <tkamppeter> pitti, what do you mean?
[12:51] <pitti> tkamppeter: for example, some upstreams ship PDF files in their GPLed tarballs without a 'source' (such as an OpenOffice or LaTeX document)
[12:51] <pitti> tkamppeter: don't worry for now, I was just curious
[12:51] <pitti> tkamppeter: btw, I changed all the seeds from gs-esp-x to ghostscript-x yesterday
[12:51] <tkamppeter> No, the problem is that the CMap directory contains files with licenses for only verbatim redistribution.
[12:52] <pitti> tkamppeter: I'll do the meta uploads and the removals once the new gs is actually in gutsy
[12:52] <pitti> tkamppeter: ah, I see
[01:02] <tkamppeter> pitti, now I redownloaded 0ubuntu2 from launchpad and did the standard uupdate approach to get to the new source tarball.
[01:03] <tkamppeter> The new version will be 8.60.dfsg.2-0ubuntu1. Will the archive accept this one?
[01:06] <pitti> tkamppeter: yes, that's fine; the final version will be .3 (or .4 or whatever) then?
[01:08] <tkamppeter> Yes, so with every SVN update I will simply bump that number by 1. So if the final of 8.60 will take some time but we need the bug fixes they do earlier it can end up in 10 or 20 ...
[01:09] <tkamppeter> For later versions I will directly start with something like 8.61~svnXXXX. Can one then use 8.61 for the final?
[01:10] <pitti> tkamppeter: yes, you can
[01:10] <pitti> tkamppeter: ~ is a special operator introduced for exactly this use case
[01:10] <pitti> tkamppeter: it means 'smaller than the version before it'
[01:11] <pitti> tkamppeter: so 1~1 << 1~2 << 1
[01:12] <tkamppeter> Thank you very much, making use of this for the ghostscript package is not possible any more, but I will use it in later, similar use cases.
[01:13] <Mithrandir> this means you can have positive version numbers smaller than 0.
[01:14] <Hobbsee> that's...stuffed.
[01:14] <pitti> yes, you can have negative versions :)
[01:14] <pitti> 0~1 < 0
[01:14] <highvoltage> aaah
[01:15] <tkamppeter> pitti, packages are on their way to my web space now: 8.60.dfsg.2-0ubuntu1.
[01:16] <pitti> tkamppeter: will take a look later
[01:16] <tkamppeter> pitti, thanks for all, tell me as soon as you have any questions or results.
[01:28] <slomo> pitti: you might want to merge hal 0.5.9-3 (on incoming now i guess), it also uses a real init script now
[01:30] <tkamppeter> pitti, upload of the new source files has completed.
[01:31] <Keybuk> slomo: doesn't HAL depend on D-BUS anymore then?
[01:37] <slomo> Keybuk: it still uses dbus... but stuff like hal and avahi got moved from /etc/dbus-1/event.d scripts to real init scripts
[01:37] <Keybuk> any particular reason?
[01:38] <slomo> Keybuk: afaik only consistence... every other daemon is in /etc/init.d and you could disable it with rc-conf for example
[01:38] <Keybuk> fair enough
[01:57] <pitti> tkamppeter: I'm back
[01:59] <pitti> slomo: yep, will do that
[02:02] <tkamppeter> pitti, all files are in place for a new upload now I hope the version numbering is correct now.
[02:03] <pitti> tkamppeter: yep, it looks good; downloading right now
[02:09] <pitti> slomo: that leaves us with dhcdbd, NetworkManager, and system-tools-backends
[02:13] <nuu> does anybody know why s2disk (uswsusp) doesn't support screen width/height (-x and -y) params anymore ? that breaks hibernate.sh in acpi-support 0.95
[02:14] <Mithrandir> because it's not needed?
[02:14] <Mithrandir> acpi-support should just be fixed not to pass them
[02:15] <slomo> pitti: i guess mbiebl will care for NM and dhcdbd soon... for s-t-b let's ask the debian maintainer :)
[02:15] <StevenK> I uploaded uswsusp, should I fix acpi-support?
[02:16] <nuu> StevenK: well from what i can tell, you could remove the whole usplash.conf checking if-fi block altogether from hibernate.sh
[02:17] <nuu> ie just check for -x on s2disk, and run it without further ado
[02:17] <StevenK> nuu: Would you mind filing a bug against acpi-support if you haven't already?
[02:17] <nuu> sure, will do
[02:17] <StevenK> nuu: Thanks!
[02:17] <nuu> yw
[02:30] <jsgotangco> it can?
[02:30] <bhale> jsgotangco: how many mails to the center of a evolution core dump?
[02:31] <ogra-classmate> jsgotangco: sure
[02:31] <ogra-classmate> it just gets extremly slow the first time it has to pull down all the imap headers
[02:31] <jsgotangco> i mean is it like functioning as expected or awfully slow
[02:31] <jsgotangco> ahh
[02:31] <ogra-classmate> but once thats done it behaves 
[02:32] <jsgotangco> ahh but would kids be expected to use evo? heh
[02:32] <ogra-classmate> seb128: one thing i always notice is that evo seems to queue *every* click even if its unresponsive for a minute or so ... we should limit this queue 
[02:32] <pochu> jsgotangco: And would kids be expected to have 22k messages? :)
[02:33] <ogra-classmate> jsgotangco: no idea, its an app we ship so i need to test if it works
[02:33] <kylem> pochu, kids reading lkml?
[02:33] <pochu> kylem: nice kids, then :)
[02:33] <bhale> kylem: i read it when i was 16, that is why i am brain damaged
[02:33] <ogra-classmate> using my personal inbox and seeing it work *somehow* is enough of a stresstest i think ;)
[02:33] <seb128> ogra-classmate: stop clicking like a mad man when the app doesn't react ;)
[02:34] <ogra-classmate> seb128: i dont, but sometimes i'm in the overview list without noticing and scroll up or down
[02:34] <jsgotangco> poor kids, i'll make sure my 5 year old won't use one then heh
[02:34] <ogra-classmate> so it tries to display 50 msgs in a row
[02:35] <ogra-classmate> having the queue limited to the last 5 or so would increase performance imho
[02:42] <nuu> StevenK: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/116411
[02:42] <ubotu> Launchpad bug 116411 in acpi-support "wrong s2disk parameters invoked by hibernate.sh in acpi-support 0.95 when /etc/usplash.conf is present" [Undecided,Unconfirmed]  
[02:42] <StevenK> nuu: Excellent, thanks.
[02:42] <nuu> you're very welcome
[02:44] <pitti> tkamppeter: uploaded, thank you!
[03:00] <aquarius> Is there some documentation somewhere on what services packages.ubuntu.com provides (i.e., what /cgi-bin/download.pl does, etc)? Or, more particularly, can I jump to "the latest version of vlc in feisty" through some nice URL like p.u.c/feisty/graphics/vlc/download without getting the vlc page and parsing it myself for the deb link?
[03:01] <persia> aquarius: You probably want http://launcpad.net/ubuntu/+source/vlc
[03:01] <aquarius> persia: ah, not really; what I want to do is point someone at a "download this package by clicking here" link which won't break if there's a patch release.
[03:02] <aquarius> So http://packages.ubuntu.com/cgi-bin/download.pl?arch=i386&file=pool%2Funiverse%2Fv%2Fvlc%2Fvlc_0.8.6.release-0ubuntu4_i386.deb&md5sum=f10ad4197a89c79069a7a9eab73a5f0d&arch=i386&type=main (the get-a-deb link from p.u.c) is no good because if there's a new release of that package inside feisty, that link won't be to the most recent version.
[03:04] <aquarius> and launchpad also links directly, so http://librarian.launchpad.net/6873078/vlc_0.8.6.release-0ubuntu4_i386.deb as a link is no good either.
[03:10] <aquarius> I don't know whether the source to packages.ubuntu.com is available anywhere; I looked, but couldn't find it.
[03:13] <Keybuk> it's the same as packages.debian.org
[03:13] <aquarius> Keybuk: yeah, but #debian are being unresponsive and I can't find source for p.d.o either :)
[03:14] <Keybuk> probably in their websuite source somewhere
[03:15] <Keybuk> try mailing the debian-www e-mail lsit
[03:15] <Keybuk> it must be available since someone else set up packages.ubuntu.com
[03:15] <aquarius> yeah. I'll mail if I have to, I just figured asking on irc would be quicker...
[03:17] <aquarius> ...and I was wrong ;)
[03:17] <Ng> aiui packages.u.c is run by the same guy as packages.d.o, so it may be that only he has the source
[03:19] <Keybuk> aquarius: djpig is apparently the person you need to ask
[03:23] <aquarius> Keybuk: aha, yep, http://www.djpig.de/projekte/ has a (broken) link to a CVS repos...
[03:48] <cjwatson> aquarius: IIRC the source used to be in debian-www CVS
[03:48] <cjwatson> aquarius: http://cvs.debian.org/packages/?root=webwml
[03:49] <cjwatson> doesn't seem to have moved to svn yet
[03:51] <cjwatson> aquarius: a.k.a. 'cvs -d :pserver:anonymous@cvs.debian.org:/cvs/webwml co packages'
[03:52] <cjwatson> in fact, there's an ubuntu branch there
[03:53] <cjwatson> cvs -d :pserver:anonymous@cvs.debian.org:/cvs/webwml co -r ubuntu -d ubuntu-packages packages
[03:58] <aquarius> cjwatson: aha! cool.
[04:14] <mc44> was there a reason ndiswrapper was dropped from the feisty desktop CD?
[04:14] <ogra-classmate> is there any way to restrict the amount of tmpfs to be used for varrun varlock etc ? TMPFS_SIZE seems to be completely ignored
[04:15] <ogra-classmate> intrestingly SHM_SIZE isnt ...
[04:15] <ogra-classmate> Keybuk: ?? ^^^
[04:18] <Keybuk> ogra-classmate: no, but then they don't grow large anyway
[04:19] <ogra-classmate> Keybuk: well, doesnt it allocate the maximum in ram?
[04:20] <mjg59> It's not allocated until used
[04:20] <ogra-classmate> ah, cool
[04:20] <ogra-classmate> but still, setting 
[04:20] <ogra-classmate> TMPFS_SIZE shouldnt be ignored
[04:21] <mc44> on what package should I file a bug about the seeds?
[04:21] <ogra-classmate> the fun stuff is that its apparently read by the initscript
[04:21] <Keybuk> ogra-classmate: it's just swap space, usually
[04:21] <ogra-classmate> well, i'm on a swpless system
[04:22] <ogra-classmate> and try to get the last out of the ram
[04:22] <Keybuk> ogra-classmate: where have you found this TMPFS_SIZE variable?
[04:22] <ogra-classmate> its mentioned in /etc/default/tmpfs
[04:22] <Keybuk> if there's too much in /var/run or /var/lock, limiting the size won't help you -- that'll just break the boot
[04:22] <Keybuk> it is?
[04:22] <Keybuk> only SHMFS_SIZE is mentioned there for me
[04:22] <ogra-classmate> and apparently thats sourced by the initscripts
[04:23] <tkamppeter> pitti, everything of ghostscript has successfully built now. Thank you.
[04:23] <mjg59> Keybuk: # SHM_SIZE sets the maximum size (in bytes) that the /dev/shm tmpfs can use.
[04:23] <mjg59> # If this is not set then the size defaults to the value of TMPFS_SIZE
[04:23] <mjg59> # if that is set; otherwise to the kernel's default.
[04:23] <mjg59> (feisty)
[04:23] <cjwatson> mc44: ubuntu-meta is usually good enough if they're the Ubuntu seeds (otherwise substitute as appropriate)
[04:23] <Keybuk> right, SHMFS_SIZE sets the size of /dev/shm
[04:23] <ogra-classmate> right, thats what i have as well
[04:24] <Keybuk> I can only see it get used by that
[04:24] <mjg59> Right, but it implies that there's a TMPFS_SIZE that can be set somewhere
[04:24] <Keybuk> that does indeed refer to a TMPFS_SIZE which is defined to "" in the same init script
[04:24] <ogra-classmate> TMPFS_SIZE=
[04:24] <ogra-classmate> [ -f /etc/default/tmpfs ]  && . /etc/default/tmpfs
[04:24] <ogra-classmate> from mtab.sh
[04:24] <Keybuk> I don't think it's useful to limit the size of /var/run or /var/lock though
[04:24] <Keybuk> ogra-classmate: why do you disagree?
[04:24] <ogra-classmate> the same is in mountvirtsubfs.sh
[04:25] <Keybuk> ? there is no mountvirtsubfs
[04:25] <mc44> cjwatson: thanks
[04:25] <ogra-classmate> well, if its not allocated before usage i dont care much, but the variable not being used seems inconsistent
[04:25] <Keybuk> it makes sense to limit /dev/shm, since that's POSIX shared memory
[04:25] <Keybuk> and there's a defined behaviour for that being unavailable
[04:25] <ogra-classmate> Keybuk: devsubfs indeed
[04:26] <Keybuk> if you limit the size of /dev, /var/run or /var/lock, you just break important things
[04:26] <desrt> tmpfs mounts default to half of physical memory
[04:26] <ogra-classmate> yeah, so lets drop the variable 
[04:26] <Keybuk> ogra-classmate: I think the variable has largely been dropped, and one instance of it was missed :p
[04:26] <ogra-classmate> its just confusing and makes you think you can influence anything with it
[04:27] <ogra-classmate> well, fine then :)
[04:27] <Keybuk> otoh, it would make sense to limit the size of /tmp, if we mounted that as a tmpfs
[04:27] <desrt> Keybuk; if you're gonna do that, please write something in the login-without-free-space blueprint
[04:28] <desrt> Keybuk; since that would trivialise that entire spec :)
[04:28] <Keybuk> desrt: do which?
[04:28] <desrt> Keybuk; there's a spec from uds for logging in when all free space is used
[04:28] <desrt> Keybuk; gdm falls back to writing xauthority into /tmp.  we're creating /var/overflow (1MB tmpfs) for it to write into.
[04:28] <desrt> Keybuk; if /tmp is tmpfs (and not, say, part of a filled /) then we can just leave it in /tmp
[04:30] <desrt> i think some apps do stuff like generate iso images and .wav files for CD burning in /tmp, though :)
[04:30] <mc44> cjwatson: bug 116436
[04:30] <ubotu> Launchpad bug 116436 in ubuntu-meta "wrong version of ndiswrapper in ship-live seed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116436
[04:32] <cjwatson> desrt: please can it be /var/somethingthatisactuallyinthefhs
[04:33] <desrt> cjwatson; :)
[04:33] <cjwatson> desrt: ideally /var/run or /var/lock - otherwise the installer has to have code changes to create yet another tmpfs on the root filesystem
[04:33] <cjwatson> /var/run seems perfectly good for this
[04:33] <desrt> cjwatson; the problem is that it has to be a world-writeable (sticky) location
[04:34] <desrt> cjwatson; and having such a location in /var/run or /var/lock would easily allow a user to pwn the system by filling it up
[04:34] <cjwatson> so create an appropriately-permissioned directory in /var/run in an init script
[04:34] <desrt> and when joe-random-user fills /var/run with junk and your daemons can no longer start...?
[04:34] <cjwatson> then they could do the same with /var/overflow and /tmp and stop gdm from starting?
[04:35] <cjwatson> DDTT
[04:35] <ogra-classmate> just move /tmp to a tmpfs by default :P
[04:35] <cjwatson> also you could make /var/run/gdm or whatever be group gdm, so they couldn't
[04:35] <desrt> cjwatson; /var/overflow is only used in the emergency case
[04:35] <cjwatson> desrt: /var/run/gdm should do just as well. please do not make the installer have to do more work here
[04:35] <desrt> cjwatson; an interesting idea... but i suspect xauthority is created after the permissions drop
[04:35] <cjwatson> there is no possible reason why /var/overflow can be superior to /var/run
[04:35] <desrt> cjwatson; but it's worth checking out
[04:36] <cjwatson> either can be filled up maliciously in exactly the same ways
[04:36] <cjwatson> aside from the blatant FHS violation
[04:36] <desrt> but 99.9% of the time if you fill /var/overflow nobody will care
[04:36] <desrt> it's merely a fallback
[04:36] <desrt> it's only used if every last block of space is occupied in ~
[04:36] <cjwatson> it is still a bogus name
[04:36] <desrt> i agree
[04:37] <cjwatson> also, 83.6% of statistics are made up on the spot ;-)
[04:37] <desrt> i'll look into the gdm-group xauthority thing
[04:37] <desrt> cjwatson; fwiw, the real number is more than 99.9% :p
[04:37] <cjwatson> having had to fix bemused people's systems when their root filesystem filled up, I disagree
[04:37] <desrt> fewer than 1 in 1000 logins will fail due to there being exactly 0 blocks free on the partition that holds ~ :)
[04:38] <cjwatson> it may be numerically small, but the impact is large
[04:38] <desrt> ahah.  now you discover the "damned lies" aspect of statistics :)
[04:38] <cjwatson> people care when they cannot log in and there is no indication whatsoever as to why
[04:38] <cjwatson> or how to fix it
[04:39] <desrt> it's really two separate cases, though
[04:39] <desrt> if the user intentionally fills /var/overflow then to hell with them
[04:39] <cjwatson> same goes for /var/run
[04:39] <desrt> but if, on a server, say, the user is permitted to fill /var/run then we have trouble
[04:39] <cjwatson> anyway, you can always mount another tmpfs under /var/run
[04:39] <desrt> true.
[04:39] <cjwatson> which solves the FHS issue
[04:39] <desrt> it's a better place for it.
[04:42] <cjwatson> having /tmp on tmpfs is a bit controversial (unfortunately?)
[04:42] <cjwatson> and certainly making it be that way on upgrades would be a significant headache
[04:42] <cjwatson> if you're on a low-memory but reasonable-disk system, /tmp on tmpfs can be a loss if you're used to dumping fairly big temporary things there
[04:43] <ogra-classmate> yeah, firefox can get quite painful
[04:43] <ogra-classmate> caching stuff in /tmp
[04:43] <cjwatson> I have /tmp on a tmpfs on my under-RAMmed server, and mutt has problems dealing with mailboxes that are bigger than available RAM
[04:43] <cjwatson> since it can't write the whole thing to /tmp
[04:44] <mjg59> Do we default to /tmp being tmpfs?
[04:44] <cjwatson> I set a different tmpdir to work around it, but it's pretty annoying
[04:44] <cjwatson> mjg59: no
[04:44] <mjg59> Didn't think so
[04:44] <ogra-classmate> mjg59: nope
[04:48] <desrt> cjwatson; gdm-group-writeable isn't good enough for creating xauthority.  it really needs to be 777.
[04:50] <pitti> doko, dholbach: hm, launchpadBugs/HTMLOperations.py keeps throwing 'libxml2mod.so: undefined symbol: xmlTextReaderSetup' at me
[04:50] <dholbach> URG
[04:51] <dholbach> pitti: which version and what is are you doing? :)
[04:51] <pitti> dholbach: gutsy apport retracer chroots
[04:51] <dholbach> can you give me a use case or something?
[04:51] <dholbach> I doubt it's a python-lp-bugs bug
[04:52] <pitti> right, so do I; either it's something strange in python-libxml2, or a side effect of fakechroot
[04:52] <dholbach> but it'd be nice if I could reproduce it - the bughelper reports generator thing does not have problems like that in its logs
[04:54] <pitti> dholbach: happens at importing it: python -c 'launchpadBugs.HTMLOperations import Bug'
[04:55] <pitti> dholbach: in libxml2.py, 'import libxml2mod'
[04:55] <dholbach> hrm, let me create a chroot and try it there
[04:56] <pitti> it doesn't happen on my desktop system
[04:56] <dholbach> (it works on all of my machines - let's see what the chroot says)
[04:56] <pitti> yeah, don't worry
[04:59] <slomo> bdmurray: it's not necessary to ask for retraces of mono applications... they're completely useless anyway, same for the apport stuff
[05:18] <bdmurray> slomo: what makes them useless?
[05:19] <mvo_> pitti: I have a couple of hundreds apport processes runing on my box that DoS it currently
[05:19] <seb128> bdmurray: any reason you tag bugs which have been closed as duplicates to retrace them?
[05:20] <mvo_> pitti: are they supposed to run in parallel?
[05:20] <pitti> mvo_: well, not exactly forbidden, but certainly not several hundreds
[05:20] <pitti> mvo_: can you send me /var/log/apport.log?
[05:20] <pitti> (and kill them afterwards)
[05:20] <mvo_> pitti: once the system is under control I will
[05:20] <bdmurray> seb128: I've been going through the mailing list and it seems some duplicate messages aren't showing up
[05:21] <slomo> bdmurray: because stuff runs in a vm and you will only get random addresses without symbols, maybe some addresses with symbols from native libraries but it's just useless ;) better ask the people to give the terminal output of mono
[05:21] <seb128> bdmurray: how do you tag the bugs? do you open them in a browser?
[05:21] <bdmurray> seb128: no
[05:21] <dholbach> pitti: hum, that works nicely in a chroot
[05:21] <dholbach> (clean chroot)
[05:21] <pitti> dholbach: hm, thanks; so I have to leave the gutsy chroots disabled for now
[05:22] <bdmurray> seb128: I've been using mutt and it's ability to pipe messages to a command.  Sorry for any noise.
[05:22] <seb128> no problem
[05:22] <seb128> I was just wondering why I get all those tagging mails for closed bugs
[05:22] <dholbach> pitti: what does      python -c "import libxml2mod"     say?
[05:23] <pitti> dholbach: that error message
[05:23] <dholbach> just 'libxml2mod.so: undefined symbol: xmlTextReaderSetup'?
[05:24] <pitti> root@ronne:/# python -c "import libxml2mod"
[05:24] <pitti> Traceback (most recent call last):
[05:24] <pitti>   File "<string>", line 1, in <module>
[05:24] <pitti> ImportError: /tmp/tmpZMeAaO/var/lib/python-support/python2.5/libxml2mod.so: undefined symbol: xmlTextReaderSetup
[05:24] <dholbach> pitti: which version of  {python-,}libxml2  is that?
[05:24] <pitti> 2.6.28.dfsg-1ubuntu1
[05:24] <dholbach> both?
[05:25] <pitti> yes
[05:25] <dholbach> HRM
[05:26] <mdz> bdmurray: I think the duplicate email thing may be a "feature"
[05:26] <dholbach> for me the path is: /usr/lib/python-support/python-libxml2/python2.5/libxml2mod.so
[05:26] <pitti> that should be a symlink
[05:26] <seb128> pitti: ldd /tmp/tmpZMeAaO/var/lib/python-support/python2.5/libxml2mod.so | grep xml ?
[05:26] <pochu> python 2.6? Is that new? :)
[05:26] <mdz> bdmurray: I recall there was talk about reducing the spam caused by bugs with many duplicates, mailing all subscribers and reporters
[05:26] <dholbach> pochu: that's the libxml2 version
[05:26] <pochu> err, libxml2, oks :)
[05:26] <bdmurray> mdz: if it is that makes it challenging to use the mailing list
[05:26] <mdz> bdmurray: I agree, it's probably an oversight
[05:27] <mvo_> pitti: ok, the problem is that apport calls apt-cache. if that crashes that causes apport to go wild (my local version has a bug apparently that I introduced this afternoon)
[05:27] <mdz> bdmurray: something to raise on the launchpad list, make sure that the bug contact still gets emailed
[05:27] <pitti> seb128: ldd does not work with fakechroot, sorry
[05:28] <bdmurray> mdz: will do
[05:28] <seb128> pitti: and "nm -D /usr/lib/libxml2.so.2 | grep xmlTextReaderSetup" ?
[05:28] <pitti> # nm -D /tmp/tmpLUYmfr/var/lib/python-support/python2.5/libxml2mod.so | grep xmlTextReaderSetup
[05:28] <pitti> 0000000000038860 T libxml_xmlTextReaderSetup
[05:28] <pitti>                  U xmlTextReaderSetup
[05:28] <seb128> $ nm -D /usr/lib/libxml2.so.2 | grep xmlTextReaderSetup
[05:28] <seb128> 000ce6c0 T xmlTextReaderSetup
[05:28] <pitti> similar here
[05:28] <seb128> weird that it doesn't find the symbol
[05:28] <seb128> it's present
[05:28] <seb128> is there an another libxml2.so.2 to /usr/local or something?
[05:28] <pitti> it's probably something really weird with fakechroot
[05:29] <pitti> seb128: no, just that
[05:29] <seb128> weird
[05:32] <seb128> how did you fix it?
[05:33] <pitti> so,  only feisty chroots for now, but crashed gutsy tags won't get lots (I changed launchpad-crash-digger to test that and skip them)
[05:33] <pitti> seb128: I didn't
[05:33] <ogra-classmate> hmm, epiphany seems a lot less memory hungry ...
[05:33] <pitti> but I need to do something else first before I try that again
[05:34] <seb128> ogra-classmate: than what?
[05:34] <ogra-classmate> and it scales the pages way better on this little display
[05:34] <ogra-classmate> seb128: than ff
[05:34] <seb128> ah
[05:34] <seb128> yeah, epiphany is nice ;)
[05:34] <ogra-classmate> i cant use evo and ff at the same time here
[05:34] <ogra-classmate> but ephi and evo get along very well it seems
[05:35] <desrt> classmate seems quite evil.
[05:35] <ogra-classmate> i wouldnt even mind to have ephi by default in the classmate image
[05:35] <ogra-classmate> but there is always the need for firefox as well, which brings me two menu entries 
[05:39] <keescook> mornin' folks
[05:40] <desrt> i have a question, security dude
[05:40] <keescook> desrt: sure! wup?
[05:40] <keescook> er sup?
[05:40] <desrt> when you push security updates, why don't you merely push the single binary package that is actually affected by the issue instead of all of the binary packages from the source package that was affected?
[05:41] <keescook> desrt: as I understand it, it's a limitation of Debian packaging.  pitti may be able to answer better than me.
[05:42] <desrt> seems like something that it might be worth fixing
[05:42] <pitti> desrt: that would mean that we would need to support a concept of multiple current source versions
[05:42] <pitti> (and binary)
[05:42] <desrt> pitti; or a concept of equivalent binary version
[05:42] <pitti> desrt: nope, you cannot assume that they are equivalent
[05:42] <desrt> pitti; or a concept of binary versions != source versions
[05:43] <pitti> merely rebuilding a source package can lead to binaries with different behaviour
[05:43] <pitti> (different toolchain, different library ABIs you build against, etc)
[05:43] <desrt> it's true... but probably not in a security-update context....
[05:43] <pitti> desrt: sadly it is
[05:43] <desrt> the platform is quite stable by this time
[05:43] <pitti> desrt: because we do not rebuild the entire archive against itself right before release
[05:43] <desrt> oh.
[05:43] <desrt> right.  good point.
[05:44] <pitti> so the binaries in a stable release might be built against an older toolchain, etc.
[05:44] <mdz> desrt: all of the binaries need to be built by the same source, to preserve sanity
[05:45] <mdz> desrt: there is a concept of binary versions != source versions, called "binary NMU"
[05:45] <mdz> but this is legacy stuff which should be avoided; it's the cause of much pain
[05:46] <desrt> arf
[05:47] <desrt> rebuilding the entire tree in the week before release would probably be an extremely fun way to screw yourself :)
[05:47] <keescook> does someone here have irc op powers?  someone's client went crazy on #ubuntu-mythtv
[05:47] <desrt> keescook; better to ask in #freenode
[06:01] <pitti> desrt: and you would need to rebuild it at least twice (more if you are not strict on the ordering) :)
[06:03] <pitti> tkamppeter: ghostscript NEWed
[06:09] <Keybuk> kyle: can I ask a really tedious question? :P
[06:14] <kylem> yes.
[06:17] <Keybuk> kylem: I'm already asking it on #c
[06:17] <Keybuk> :p
[06:17] <kylem> ok.
[06:17] <kylem> :P
[06:25] <Keybuk> ok, compiz just reached a massive milestone
[06:25] <Keybuk> I switched to it to have a fiddle, it lost some of my preferences *but* I was able to set them back again
[06:26] <Keybuk> I can almost think of using this as my window manager <g>
[06:26] <ion_> :-)
[06:26] <ion_> Which version?
[06:26] <kylem> is it smart enough to suck out your metacity prefs yet?
[06:29] <Keybuk> gutsy
[06:29] <Keybuk> not yet
[06:30] <Keybuk> and the hold-down-Super-and-drag-windows doesn't work
[06:30] <Keybuk> and I'm not sure, but I can't change the list of plugins; might be a gconf-editor bug
[06:33] <Keybuk> ah no, it keeps editing the plugin list back to fix its order and missing out the one I added
[06:34] <Keybuk> super-and-drag => conflicts with screenshot/allscreens/options/initiate_button
[06:47] <dsk> hi
[06:47] <dsk> how do i distinguish between a PAE kernel or a non-PAE kernel?
[06:47] <dsk> 2) ubuntu 7.04 has non-PAE kernel by default.. right?
[06:48] <kylem> dsk, correct.
[06:48] <kylem> zgrep CONFIG_HIGHMEM64G /proc/config.gz
[06:48] <dsk> ummm config.gz is not enabled :(
[06:49] <kylem> anyway, i think the only flavour is server-bigiron with PAE on.
[06:49] <dsk> correct ...
[06:49] <dsk> but it raises a big doubt then
[06:50] <dsk> ubuntu has xen-hypervisor and xen-hypervisor-pae
[06:50] <dsk> but xen-image is single
[06:50] <zul> the server config for xen has PAE enabled
[06:50] <dsk> and we know that we can't mix pae and non-pae kernels
[06:51] <dsk> zul: but hypervisor can be pae / non-pae but xen-image is single package
[06:51] <dsk> you see my point here, right?
[06:51] <zul> xen-image server flavour
[06:51] <dsk> xen-image-2.6.19-4-generic  xen-image-2.6.19-4-server
[06:51] <dsk> now which one is pae and which non-pae ?
[06:52] <zul> yes the second one works with pae
[06:52] <dsk> and the first one is non PAE then ?
[06:52] <zul> correct
[06:52] <dsk> zul: cool ... now i get it ...
[06:52] <dsk> means of i install xen-image server then automatically i will also install xen hypervisor pae one... right?
[06:53] <zul> no..install the ubuntu-xen-server metapackage
[06:53] <dsk> ok lemme try
 ummm config.gz is not enabled :( <-- for ubuntu kernels config can be found in /boot/config-*
[06:54] <dsk> Seveas: right but i was thinking of determining that from the vmlinuz files themselves!
[06:54] <Seveas> dsk, ah
[06:54] <dsk> because i have a lot of kernels lying around
[06:54] <dsk> FC6 ones :(
[06:55] <Seveas> heh
[06:55] <dsk> which don't have the corresponding configs :(
[06:56] <dsk> Found Xen hypervisor 3.0-i386-pae,  kernel: /boot/vmlinuz-2.6.19-4-generic
[06:56] <dsk> Found Xen hypervisor 3.0-i386,  kernel: /boot/vmlinuz-2.6.19-4-generic
[06:56] <dsk> :(
[06:57] <dsk> how come the same kernel is getting used, i am unable to understand that
[06:57] <zul> dsk: ask in #ubuntu-xen
[06:57] <zul> this channel isnt for support
[06:57] <dsk> zul: right
[06:58] <dsk> zul: nobody there  :)
[07:10] <HlTMAN> hi
[07:15] <pitti> seb128, bdmurray: ^ :)
[07:18] <pitti> many of them are useless due to obsolescense, sorry; but with the new auto-tagging it should improve now
[07:19] <pitti> but it generally works, see bug 114994
[07:19] <ubotu> Launchpad bug 114994 in brasero "[apport]  brasero crashed with SIGSEGV in g_str_hash()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114994
[07:32] <pitti> slomo: yay, we can finally sync texlive-bin
[07:32] <slomo> pitti: yep, i already asked seb128 to sync it ;)
[07:33] <pitti> (from incoming)
[07:33] <pitti> slomo: I'll do it tomorrow if seb128 doesn't get to it today; it's not that urgent
[07:33] <slomo> pitti: thanks, i just don't want to forget about it :)
[07:33] <pitti> it won't magically cure the ia64 FTBFS, though
[07:34] <slomo> no... does amd64 build now?
[07:34] <slomo> at least those two build failures look like something broken in the toolchain
[07:34] <pitti> lamont: btw, do you still care for ia64? I don't have a porter box login; texlive-bin FTBFSes due to a weird libtool issue, and it is a transitive build-dep for quite a lot of stuff
[07:34] <ion_> Is libkpathsea already built from texlive? I didnt get around to doing that yet. :-\
[07:34] <seb128> pitti: I'll sync it, I've just been lazy to do the extra steps to sync from incoming ;)
[07:34] <pitti> slomo: hm, indeed; 6ubuntu1 built
[07:35] <seb128> now we need to get a gutsy crash bug ;)
[07:35] <pitti> seb128: the retracer just grinded through a dozen of them
[07:35] <pitti> it's still enabled for Kubuntu :)
[07:35] <seb128> waouh
[07:35] <seb128> ah, k
[07:35] <pitti> and for people who flipped the gconf key
[07:35] <seb128> because we got no desktop ones
[07:35] <seb128> most of people attach the crash from /var/crash
[07:36] <slomo> pitti: will you enable SIGABRT again for gutsy in apport? :)
[07:36] <pitti> seb128: 112579, 116399, 113295
[07:36] <lamont> pitti: ia64 ubuntu?
[07:36] <pitti> lamont: yes, gutsy
[07:36] <lamont> I'll look at tetexlive-bin
[07:36] <pitti> lamont: (texlive-bin, not tetex)
[07:37] <pitti> lamont: that would rock, thanks
[07:37] <pitti> seb128: hm, if you suffer from that, maybe we should flip it on again?
[07:37] <seb128> pitti: those 3 examples are b0rked :(
[07:37] <slomo> ion_: yes, i enabled it a week ago or something and it's enabled in debian too now
[07:37] <pitti> seb128: we still don't have a dup detector, nor automatic rejection for bad retraces
[07:37] <pitti> seb128: yep, too old :/
[07:38] <pitti> anyway, I have to run to Taekwondo now; cu tomorrow!
[07:38] <seb128> pitti: no, thanks, I've just spent a full week catching up on bugs, I need to get other things done
[07:38] <seb128> apport can wait
[07:38] <seb128> pitti: have fun, see you
[07:38] <pitti> 'k
[07:38] <ion_> slomo: Alright.
[08:01] <Keybuk> what does the compiz plane plugin do?
[08:02] <ogra-classmate> makes your laptop hover by using the fans ?
[08:05] <mc44> Keybuk: it does the sliding viewports instead of a cube
[08:05] <mrsn0> the plane is quite nice, not sure about compiz but in beryl you can drag + drop from each "window"
[08:06] <Keybuk> they're not sliving though
[08:06] <Keybuk> sliding either
[08:06] <Keybuk> they just fade from one to the other
[08:15] <Keybuk> *giggle* lots of silly bugs
[08:15] <Keybuk> nautilus and the panel only appear on the first desktop
[08:15] <Keybuk> the ssh-askpass window vanishes on login
[08:15] <Keybuk> etc.
[08:15] <Keybuk> getting better though
[08:25] <highvoltage> mdz: when you said "avoid no-op meetings", did you mean no-op as in no IRC ops, or as in http://en.wikipedia.org/wiki/NOP? if it was both, then it's a very nice pun. NOOP meetings suck :)
[08:28] <mdz> highvoltage: the latter
[09:12] <hughsie> hey guys. just wondered what was the plan for gutsy with pm-utils?
[09:16] <seb128> Keybuk: 
[09:16] <seb128> cd: 236: can't cd to /sys/class/net
[09:16] <seb128> dpkg: error processing udev (--configure):
[09:16] <seb128> Keybuk: some builds are breaking on this error
[09:28] <Keybuk> seb128: oops
[09:29] <Keybuk> eh?
[09:29] <Keybuk> why does that fail the buildds
[09:29] <Keybuk> it's
[09:29] <Keybuk> cd /sys/class/net || return
[09:30] <Keybuk> oh, needs to be return 0
[09:30] <Keybuk> how idiotic
[09:31] <Keybuk> seb128: uploaded fix
[09:31] <seb128> Keybuk: thanks ;)
[10:31] <mvo> cjwatson_: I updated the AptFirefoxFileHandler spec based on your suggestions. thanks again, I think its easier and cleaner now