[02:20] <bddebian> Heya
[04:53] <hardaway_> when will openoffice 2.1 be in feisty
[05:12] <jdong> in 5..4...3...2...1....
[05:13] <jdong> 0.5....0.25.....
[05:13] <bddebian> heh
[05:14] <Hobbsee> 42!
[05:16] <jdong> it's there now!
[05:16] <jdong> (ha ha, made ya look)
[05:18] <_ion> hobbsee: 1405006117752879898543142606244511569936384000000000
[05:19] <Hobbsee> :P
[05:20] <jdong> aha, that's 42!
[05:21] <jdong> (yeah, I'm a bit slow this evening)
[05:23] <_ion> And it's m6jperiu2qj2escmbvoo5edc000000000 in base-36!
[05:25] <_ion> Actually quite interesting that the final nine digits are zeros in both base-10 and base-36.
[05:30] <cjwatson> true for any multiple of 180^9 with no further factors of 5 or 18
[05:30] <cjwatson> but yes :)
[05:30] <cjwatson> er, just no further factors of 10 or 36 I guess
[05:45] <Hobbsee> Mithrandir: ping?
[05:49] <Hobbsee> Mithrandir: is http://librarian.launchpad.net/5372957/buildlog_ubuntu-feisty-i386.sylpheed-claws-gtk2_2.6.0-1ubuntu1_CHROOTWAIT.txt.gz known about?  i seem to ge tit on most arches
[06:00] <MoronShrek> I just got a $300,000us year contract
[06:00] <MoronShrek> w00t!
[06:08] <deltab> congratulations!
[06:17] <fabbione> morning
[06:20] <Hobbsee> hey fabbione!
[06:21] <fabbione> hi Hobbsee 
[06:25] <Laser_away> hi Hobbsee and fabbione 
[06:26] <fabbione> hi
[06:26] <Hobbsee> hey Laser_away 
[06:27] <Hobbsee> STUPID LAUNCHPAD!  DO WHAT I WANT!
[06:36] <Laser_away> Hobbsee: easy now
[09:00] <pitti> Good morning
[09:00] <_ion> Hi
[09:03] <pitti> hi _ion 
[09:04] <_ion> What's up?
[09:12] <proppy> hi
[09:24] <fabbione> pitti: wget is not that bit and we can strip busybox wget from being built
[09:24] <fabbione> pitti: we already pull in libssl for other stuff anyway
[09:24] <fabbione> so the size bloat would be minimal
[09:24] <pitti> fabbione: ah, if we do have a libssl udeb, then maybe you should just have a wget udeb then, with ssl support?
[09:25] <fabbione> pitti: that was the idea.. yes
[09:25] <pitti> right, that's what I meant
[09:25] <fabbione> i need to talk to cjwatson first
[09:25] <fabbione> adding udebs at random can be dangerous
[09:26] <fabbione> specially when replacing "known to work" busybox commands
[09:30] <Mithrandir> fabbione: I suspect that gnu wget is way bigger than busybox wget.
[09:40] <pitti> Mithrandir: hm, seems that your postgresql-8.2 sync went to Nirvana :/
[09:40] <Mithrandir> pitti: maybe it just went to NEW.
[09:41] <pitti> just checked the queue, it's not there
[09:41] <pitti> Mithrandir: does the sync stop completely if an error occurs/
[09:41] <pitti> s_/_?_
[09:41] <fabbione> Mithrandir: well it can be made optional only for system-integrity-check
[09:41] <fabbione> we don't necessarely need to replace wget in busybox by default
[09:42] <Mithrandir> pitti: hmm, let me investigate.  And hope I didn't sync it into edgy or something.
[09:43] <Fujitsu> Hahah.
[09:46] <pitti> slomo_: I wonder whether we actually need to carry this dbus at_console patch -- it's broken, and we don't use it after all
[09:49] <owh> Just wondering what the protocol is for editing/adding/removing tags. I've been searching for bugs with the word ThinkPad in them and tagging them accordingly - seeing that I have one of those, and I figured I could help out in a small way. In the process I've also edited tags where the majority of the tags were plural and a few singular.
[09:49] <owh> Should I cease and desist this, or am I doing an appropriate thing>
[09:49] <owh> s/>/?/
[09:52] <dholbach> good morning
[09:54] <pitti> hey dholbach 
[09:54] <Mithrandir> seb128: https://wiki.ubuntu.com/FeistyReleaseSchedule ; can you take a look at the herd milestones and tell me you don't go "aiee"? (wrt gnome's releases, etc)
[09:55] <dholbach> heya pitti
[09:55] <dholbach> hey Mithrandir
[09:55] <dholbach> hey seb128
[09:55] <seb128> sure
[09:55] <seb128> hi dholbach
[09:55] <seb128> hi Mithrandir
[09:55] <Mithrandir> mornining Daniel
[09:55] <Mithrandir> morning Sebastien
[09:55] <seb128> Mithrandir: Herd-2, aiee
[09:55] <dholbach> morninigningningning everybody else :)
[09:56] <seb128> Mithrandir: herd-4, aiee
[09:57] <seb128> Mithrandir: well, tarball are due on monday and usually we are done with packaging on wednesday, so it you don't freeze too soon that's fine
[09:58] <Mithrandir> seb128: we'll be aiming for a thursday release in the common case, but I'd like to not have the world falling down on wednesday.
[09:58] <seb128> Mithrandir: we can be done on tuesday evening, not before though
[09:58] <cjwatson> fabbione: I'd rather patch wget/https into busybox; minimal impact
[09:59] <seb128> Mithrandir: if that works for you ...
[09:59] <seb128> Mithrandir: http://live.gnome.org/TwoPointSeventeen for reference
[09:59] <Mithrandir> seb128: we could move all the herds out one week if that'd make it better for you?
[10:00] <fabbione> cjwatson: i phear a lot of code there and tons of bugs.. 
[10:00] <cjwatson> fabbione: might need to dlopen libssl though, or something like that, otherwise we'll pull libssl into the initrd
[10:00] <fabbione> cjwatson: yes that too...
[10:01] <seb128> Mithrandir: I'm happy to keep like that if you are happy to freeze on tuesday evening, that makes us ship with almost crack of the day new GNOME for herds ;)
[10:02] <seb128> Mithrandir: otherwise shifting one week would be better, though it would conflict with the distro sprint by example
[10:03] <Mithrandir> seb128: no, I'd move them out, as in, a week later.
[10:03] <cjwatson> I suppose a wget-udeb isn't impossible; it could be /usr/bin/wget.gnu or something
[10:03] <fabbione> cjwatson: the latter is what i was thinking
[10:03] <Mithrandir> seb128: but CotD sounds excellent to me.
[10:03] <fabbione> cjwatson: a lot less code and only pulled in if rescue is selected
[10:03] <Mithrandir> seb128: we can at least try it for the first one and if it's too painful, we move the herds.
[10:03] <seb128> ok
[10:03] <fabbione> cjwatson: so it's not too much overhead in code or size
[10:04] <cjwatson> not rescue in general surely?
[10:04] <cjwatson> just s-i-c?
[10:04] <fabbione> cjwatson: well rescue will pull in s-i-c unconditionally
[10:04] <fabbione> cjwatson: given that's a menu hook.. etc .etc .etc
[10:05] <fabbione> brb
[10:08] <fabbione> re
[10:11] <pitti> cjwatson: dapper/edgy-proposed langpacks are out for 8 days now, and got some feedback (Russian tsclient continues to be broken, but not any different than before, and all other people just reported improvements)
[10:11] <pitti> cjwatson: can you give an ack for an -updates upload, or only mdz?
[10:12] <pitti> hi doko
[10:12] <doko> good morning
[10:12] <cjwatson> pitti: I can. What happened to getting the process onto the SRU wiki page?
[10:35] <pitti> cjwatson: there's still no formally agreed-on process yet, I should bring this up in the next TB meeting
[10:35] <pitti> cjwatson: so far it was just 'propose, collect feedback on the -translators ML, test yourself, go'
[10:55] <seb128> dholbach: did you do any launchpad change which makes me receive universe sponsorship mails now?
[10:55] <pitti> carlos: could you please take a look at bug 68646?
[10:55] <Ubugtu> Malone bug 68646 in tsclient "Russian l11n in tsclient is broken" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68646
[10:55] <carlos> pitti: sure
[10:55] <pitti> carlos: the Russian tsclient.po contains just garbage
[10:56] <pitti> msgid "Connect to a remote computer"
[10:56] <pitti> msgstr "   "
[10:56] <pitti> carlos: it's a bit weird
[10:56] <pitti> carlos: the letters are all perfectly cyrillic, but they do not make sense at all
[10:56] <carlos> is it specific for Rosetta?
[10:56] <pitti> carlos: and some strings are fine
[10:56] <pitti> carlos: let me look into the upstream source
[10:57] <carlos> I mean, I guess the upstream translation is not broken that way, is it?
[10:57] <carlos> pitti: in Edgy, most translations come from upstream
[10:58] <pitti> carlos: upstream translations are in KOI8-R, I msgconv and check
[10:58] <pitti> carlos: msgconv -t UTF-8 po/ru.po |view - looks fine
[10:58] <dholbach> seb128: no, I'm not aware of what might cause that
[10:59] <seb128> dholbach: some team change apparently, I'm getting mails for the universe sponsors team
[10:59] <seb128> am I the only one?
[11:00] <pitti> carlos: http://people.ubuntu.com/~pitti/tmp/tsclient.ru.po <- original file from upstream
[11:00] <carlos> pitti: don't worry, I got it from apt
[11:00] <dholbach> ajmitch: can you deactivate 'ubuntu-dev' in 'ubuntu-universe-sponsors'?
[11:01] <dholbach> ajmitch: http://launchpad.net/people/ubuntu-universe-sponsors/+members
[11:02] <dholbach> seb128: ^ - ajmitch or Hobbsee can fix that
[11:02] <pitti> carlos: I added a comment to the bug and mangled it a bit, FYI
[11:02] <seb128> dholbach: thank you
[11:02] <dholbach> de rien
[11:02] <carlos> ok
[11:04] <carlos> pitti: That's weird, I guess the problem broke the encoding of that file uploading it in Rosetta
[11:04] <carlos> pitti: we could track it now, but that was a year ago or so
[11:04] <pitti> carlos: so could we just reimport the upstream file into Rosetta?
[11:04] <carlos> so I cannot tell you who did it. The only thing I could do is to revert to whatever upstream has
[11:04] <carlos> pitti: yes
[11:05] <carlos> let me ask something in the bug report first 
[11:05] <pitti> carlos: that shouldn't kill the strings that were added to Rosetta proper, right?
[11:05] <carlos> no
[11:05] <carlos> but I think the additions are also broken
[11:05] <carlos> so I need to check one of those with someone that knows Russian
[11:05] <carlos> (that's what I'm going to ask in the bug report)
[11:05] <pitti> carlos: I can tell you
[11:06] <pitti> carlos: I can read Russian and understand it a bit
[11:06] <carlos> pitti: Do you know Russian?
[11:06] <carlos> ok
[11:06] <carlos> ;-)
[11:06] <pitti> carlos: in any case I can tell you whether something makes sense or not
[11:06] <carlos> pitti: https://translations.launchpad.net/distros/ubuntu/edgy/+source/tsclient/+pots/tsclient/ru/4/+translate
[11:06] <pitti> carlos: for example, this one isn't present upstream and is fine:
[11:06] <pitti> msgid "New Connection..."
[11:06] <pitti> msgstr " "
[11:06] <carlos> ok
[11:06] <carlos> that's exactly what I wanted to know ;-)
[11:07] <pitti> hehe
[11:07] <carlos> pitti: I guess that means that wiz was not the one breaking translations ;-)
[11:07] <pitti> carlos: great, thanks
[11:08] <proppy> Mithrandir: Chroot problem changed to Need building
[11:08] <cjwatson> proppy: it wasn't Mithrandir's problem; infinity fixed it
[11:09] <proppy> oh ok
[11:09] <proppy> nice
[11:09] <Mithrandir> proppy: you don't need to tell me about any state changes for packages in the archive. :-P
[11:09] <proppy> sorry
[11:10] <proppy> i'm diing to see a green bar, on it since one week :)
[11:10] <pitti> meh @ evolution crashing
[11:21] <fabbione> cjwatson: so can i spend sometime to make that wget-udeb or do you prefer to investigate other solutions?
[11:22] <cjwatson> go ahead
[11:22] <fabbione> ok.. wget.gnu it is..
[11:25] <cjwatson> fabbione: done the modules -> anna/choose_modules alias in my d-i tree; I'm just checking upstream to ensure no-one objects violently to that name
[11:25] <fabbione> cjwatson: great thanks
[11:33] <iwj> cjwatson: Morning.
[11:34] <iwj> cjwatson: re this `Breaks' SRU.  The basic bug is this: edgy's apt-get dist-upgrade breaks if there are unsatisfiable Breaks relationships.
[11:34] <iwj> There is a one-line fix which I haven't yet double-checked for safety.
[11:35] <iwj> We can either 1. fix this bug in edgy-updates; 2. make update-manager edgy->feisty use feisty's apt (depends on soyuz change and generally a bit of a palaver) or 3. use Breaks only in and referring to main.
[11:36] <iwj> If you don't think (1) is a daft idea then I'll do some more checking and make a proper SRU proposal.
[11:38] <cjwatson> dist-upgrade breaks as in falls over in a heap and refuses to continue?
[11:38] <mvo> iwj: did you got my mail? I just prepared a SRU for this (and two other trivial fixes)
[11:38] <cjwatson> I'm happy to consider a one-line fix for this
[11:38] <cjwatson> though note that I'm fairly sure 2. doesn't actually depend on a soyuz change, although it remains a bit of a palaver
[11:43] <mvo> cjwatson: yes, dist-upgrade fails over and refuses to continue
[11:43] <cjwatson> fabbione: your os-prober changes look fine to me
[11:44] <fabbione> cjwatson: ok can i upload or do you have more stuff in the queue?
[11:44] <fabbione> or do you prefer to upload?
[11:44] <fabbione> (all works for me..)
[11:46] <cjwatson> fabbione: nothing from me. just use debcommit --release after updating the changelog and commit to bazaar.launchpad.net when you upload
[11:46] <fabbione> debcommit ?
[11:46] <cjwatson> (dunno if you use debcommit --release normally; I like to standardise on that for installer work because, lacking bzr tags, it makes releases easier to find)
[11:46] <cjwatson> it's in devscripts
[11:47] <fabbione> reading...
[11:47] <pitti> cjwatson, Mithrandir: for apache2.2, we need to promote 'apr' to main; it's just a split-out from the former apache package, are you fine without an MIR?
[11:47] <cjwatson> fabbione: oh and please use -I.bzr to dpkg-buildpackage if you don't normally
[11:47] <Mithrandir> pitti: yes, as well as for apr-util.
[11:47] <fabbione> cjwatson: i usually add -i that does the same
[11:47] <cjwatson> fabbione: not for native packages
[11:47] <cjwatson> -i is only for the .diff.gz
[11:47] <fabbione> ok
[11:48] <iwj> mvo: No, I haven't read my mail this morning yet.
[11:48] <mvo> iwj: ok, its just that I prepared a sru for apt for two unreleated bugs and added this fix as well to my proposal
[11:49] <iwj> mvo: Makes sense.
[11:49] <pitti> cjwatson: do you want the langpack SRU process blessed from TB before this update, or is the informal feedback enough?
[11:49] <pitti> hi slomo__
[11:50] <slomo__> pitti: i would be fine with dropping it, especially when considering that it's insecure... but at least avahi is using it...
[11:50] <pitti> slomo__: then we should teach avahi not to
[11:50] <cjwatson> pitti: no, it's fine. do you have the updates prepared?
[11:50] <pitti> cjwatson: yes, I have, sources are on rookery
[11:51] <cjwatson> path?
[11:51] <pitti> rookery:/srv/language-packs.ubuntu.com/{dapper,edgy}-updates-proposed-20061205/sources-update/*sources.changes
[11:51] <iwj> mvo, cjwatson: OK, I've just double-checked the code and it very clearly has absolutely no effect in the absence of any Breaks fields so the worst case is that it breaks upgrades to feisty (but that's what it's actually fixing, of course).
[11:51] <slomo__> pitti: right... but are you really sure nothing else uses it? what about n-m for example? and how would the solution for avahi look like? it's only a dbus method that allows setting the zeroconf hostname and was requested by n-m upstream
[11:51] <cjwatson> scp: /srv/language-packs.ubuntu.com/dapper-updates-proposed-20061205/sources-update/*sources.changes: No such file or directory
[11:51] <cjwatson> scp: /srv/language-packs.ubuntu.com/edgy-updates-proposed-20061205/sources-update/*sources.changes: No such file or directory
[11:51] <cjwatson> pitti: ^--
[11:51] <fabbione> cjwatson: debcommit --release in this case will commit straight to LP
[11:51] <cjwatson> fabbione: fine
[11:52] <pitti> cjwatson: argh, s/sources/source/, my bad
[11:52] <fabbione> cjwatson: so update changelog .. debcommit --release .. upload
[11:52] <fabbione> cjwatson: ok all worked fine i guess
[11:52] <fabbione> cjwatson: thanks for the guidance
[11:52] <pitti> slomo__: but for avahi, our modified at_console would be actively wrong
[11:53] <cjwatson> pitti: ah yes
[11:53] <cjwatson> fabbione: yes
[11:53] <pitti> slomo__: so perhaps we should modify our dbus patch to just behave like libpam-console, i. e. at_console matches everyone being logged in locally, not just the currently active session
[11:54] <slomo__> pitti: what does n-m do to prevent unrestricted access to the interfaces?
[11:54] <pitti> slomo__: for programs where the difference matters (like g-v-m and g-p-m) we can just continue using their patches which check the forground console themselves
[11:56] <pitti> slomo__: allows access to at_console=true and context=default
[11:56] <pitti> slomo__: the context=default scares me
[11:56] <pitti> slomo__: in the long run, the difference (at_console and current_console) just has to be added/fixed upstream
[11:56] <slomo__> pitti: ok, so n-m has exactly the same problem... hm, i have to leave for ~1 hour or something... let's talk about it again when i'm back, ok? :)
[11:57] <pitti> slomo__: so ATM our nm-applet doesn't work correctly with or without the dbus at_console patch
[11:57] <pitti> slomo__: yes, let's
[12:00] <sivang> hmm, n-m works quite nicely here, no issues so far (I followed some nice howto somewhere)
[12:01] <pitti> sivang: probably just out of coincidence, that two nm-applet's will do the same thing at the same time
[12:02] <sivang> pitti: maybe, at least it's working far better then the ifupdown setup I had before
[12:02] <sivang> pitti: also nicely supports all of my WAP-PSK networks
[12:02] <sivang> (e.g. auto-detects that a key is required, asks for them, sets up and connects)
[12:03] <pitti> infinity, Mithrandir: was there a specific reason to rename apache2-common to apache2.2-common? this is a real PITA for correct upgrades (which maintain enabled modules, etc.)
[12:04] <pitti> infinity, Mithrandir: for example, we want to enable mod_userdir by default for fresh installs, but telling apart a fresh install from an upgrade isn't trivial
[12:05] <Mithrandir> pitti: yes, apache2-common and apache2.2-common aren't ABI compatible
[12:06] <Mithrandir> the alternative is the biggest conflicts line the world has seen
[12:06] <pitti> Mithrandir: enabling mod_userdir is our only Debian delta, btw, and IIRC infinity wanted to fix that in Debian, too
[12:06] <pitti> Mithrandir: but anyway, Debian's version a2enmod's a lot of stuff by default
[12:06] <pitti> Mithrandir: does that mean you are fine with deliberately changing the users' configuration on upgrades?
[12:06] <Mithrandir> pitti: uh, Debian doesn't enable mod_userdir?  That's easily enough fixed.
[12:06] <pitti> that breaks the Golden Rule
[12:07] <pitti> Mithrandir: no, just tried (built the Debian package and installed it from scratch)
[12:07] <Mithrandir> pitti: it upgrades fine in the trivial case; people do too much weird shit with their apache configs in a lot of cases than we can reasonably handle.
[12:08] <Mithrandir> so in those cases, we just throw our hands up in the air and leaves the admin to fix.
[12:08] <pitti> Mithrandir: ok
[12:08] <Mithrandir> like, there's no reasonable way we can do the authn/authz split automatically.
[12:08] <Mithrandir> I'm sure thom'd love to elaborate further. :-)
[12:08] <pitti> Mithrandir: I just feel a bit nervous about automatically enabling security relevant stuff like userdir without telling the admin
[12:09] <pitti> Mithrandir: but I'm happy to merge it for now and discuss this further in a Debian bug
[12:09] <Mithrandir> pitti: you can check whether /etc/apache2/mods-available/userdir.load exists and if not assume that the userdir module didn't exist before.
[12:09] <Mithrandir> pitti: actually, #debian-apache on OFTC is a better place to discuss the development.
[12:09] <Keybuk> pitti: non root processes notifying users => isn't this what dbus is for?
[12:09] <pitti> Mithrandir: right
[12:10] <pitti> Keybuk: s/non//
[12:10] <pitti> Keybuk: right
[12:10] <pitti> Keybuk: but you need something in the user's session that actually listens to dbus
[12:10] <Mithrandir> pitti: it's a low-traffic channel and it sometimes takes a bit of time to get responses for people, but it's a useful place for discussions.
[12:10] <pitti> Keybuk: e. g. it would be possible to talk to notification-daemon (with some su wrapping, etc.)
[12:11] <pitti> Mithrandir: thanks, will do that
[12:11] <thom> (the list of modules enabled on 2.0 is more or less meaningless compared to 2.2 in a lot of cases, so the upgrade will almost never work right, as tollef pointed out)
[12:11] <pitti> Keybuk: but the problem is that at boot time (when avahi might already get disabled), there's no user session yet
[12:11] <pitti> Keybuk: thus I needed to decouple the process: the dhcp script sets the tag, and the user session picks up the tag
[12:12] <pitti> Mithrandir: hm, checking for the presence of the file wouldn't work for fresh installs
[12:12] <pitti> anyway, /me moves to #d-a
[12:13] <Keybuk> oh, complicated
[12:22] <Riddell> pitti: did you get to look at exiv2?
[12:23] <pitti> Riddell: just finished dealing with apache, will donow
[12:23] <pitti> s/donow/do now/
[12:28] <pitti> Riddell: approved, with some bad gut feeling about maintenance overhead due to soname
[12:33] <Riddell> Keybuk: able to move exiv2 source and libexiv2-dev, libexiv2-0.12, libexiv2-doc sources to main?  just approved by pitti
[12:36] <Keybuk> Riddell: one moment
[12:36] <cjwatson> fabbione: partman-auto-lvm's in bzr now, in case you need to touch it again
[12:37] <Keybuk> Riddell: all binaries
[12:37] <Keybuk> ?
[12:37] <fabbione> cjwatson: great thanks. is ddaa handling the imports?
[12:37] <fabbione> cjwatson: it would be nice to have silo-installer too
[12:37] <Keybuk> Riddell: oh, sorry, you meant "binaries" :p
[12:38] <Keybuk> Riddell: there's several packages still depending on the old version of libexiv2
[12:38] <cjwatson> fabbione: ddaa is generally helpful for imports when I need them, yes
[12:38] <Keybuk> can you fix those
[12:38] <cjwatson> fabbione: OK, I'll see if I can get you silo-installer
[12:38] <cjwatson> may take a while though
[12:39] <fabbione> cjwatson: no hurry as usual. thanks
[12:39] <Keybuk> Riddell: done
[12:51] <pitti> oh dear, now that I finally figured out how to enable this compiz thing in the first place, I have to see that it totally sucks :(
[12:51] <cjwatson> fabbione: import requested
[12:51] <fabbione> cjwatson: cheers dude
[12:52] <pitti> brb
[01:11] <fabbione> seb128, dholbach: ping?
[01:11] <dholbach> fabbione: pong
[01:11] <fabbione> dholbach: http://people.ubuntu.com/~cjwatson/testing/feisty_probs.html
[01:12] <fabbione> dholbach: can you please tell me what did FTBFS in the sparc/gnome world so we can get something to actually install?
[01:12] <dholbach> I'm sure most of them are due to the buildd problems
[01:12] <fabbione> they were there even before that
[01:12] <fabbione> like yesterday morning
[01:12] <fabbione> even before doko did break gcc
[01:13] <Mithrandir> fabbione: mono is broken, but you know that, right?
[01:13] <dholbach> eel would probably resolve nautilus and nautilus-cd-burner
[01:13] <fabbione> Mithrandir: yes mono i know.. i am talking about all the other gnome stuff
[01:13] <bhale> Mithrandir: there is a bug upstream
[01:13] <fabbione> bhale: about sparc?
[01:13] <bhale> yes
[01:13] <Mithrandir> fabbione: eel2 too, but it looks transitional so I'll just give it back.
[01:14] <bhale> http://bugzilla.ximian.com/show_bug.cgi?id=80027
[01:14] <Ubugtu> Ximian bug 80027 in io-layer "[Linux/SPARC]  Segfault in System.IO.FileSystemInfo.Refresh" [Unknown,Reopened]  
[01:14] <bhale> fabbione ^
[01:14] <dholbach> not sure what gnome-{applets,panel,mount,volume-manager} are waiting for
[01:14] <fabbione> bhale: unlikely to get fixed if either david miller or I will fix the code
[01:17] <dholbach> fabbione: a bit hard to figure out with no sparc machine to test it on
[01:17] <dholbach> most of the stuff that is not installable and causes build failures built fine itself
[01:18] <dholbach> http://librarian.launchpad.net/5167973/buildlog_ubuntu-feisty-sparc.gnome-applets_2.16.2-0ubuntu1_FAILEDTOBUILD.txt.gz shows such a build failure
[01:20] <dholbach> https://launchpad.net/distros/ubuntu/+source/gnome-python/2.16.2-0ubuntu1 failed on all archs
[01:21] <Mithrandir> dholbach: ImportError: No module named gnomevfs
[01:21] <Mithrandir> in the tests.
[01:21] <Mithrandir> I suspect that might be culprit
[01:22] <dholbach> yeah, saw that - investigating
[01:22] <fabbione> Mithrandir: can you perform a massive give-back for sparc?
[01:22] <fabbione> or just those gnome-crap packages? :P
[01:22] <Mithrandir> fabbione: I can do single give-backs, I don't have any nice tools to do mass give-backs, so please give me a list of packages.
[01:23] <fabbione> dholbach: can you give that list to Mithrandir once you have done the investigation? i suspect the usual unversioned B-D thingy
[01:23] <dholbach> unversioned b-d?
[01:24] <dholbach> fabbione: there are only a few that failed to build and it's a bit hard for me to figure out without having any means of trying to test install those packages
[01:24] <fabbione> dholbach: you can use faure chroots to figure that out
[01:25] <fabbione> dholbach: you or seb often upload pkg foo that needs bar-dev in version X or higher but you don't express this B-D properly and just rely on the fact that buildd will be fast enough to make bar-dev available before you upload foo
[01:25] <fabbione> dholbach: that's often cause of these kind of FTBFS
[01:25] <dholbach> no, I don't
[01:26] <dholbach> i always check the diff of configure.{in,ac} before
[01:26] <fabbione> well it did happen in the past so it might still happen now and you just don't notice...
[01:26] <fabbione> anyway.. it's enough Mithrandir get a list of things to retry
[01:27] <dholbach> uh huh... I'll see if I can resolve that ftbfs i found
[01:28] <Keybuk> dholbach: I've still not managed to get gossip-telepathy to login to google talk; is there some trick to this?
[01:28] <Keybuk> I get odd errors like "Connection Refused" or "Non-specific protocol error"
[01:28] <dholbach> Keybuk: I'm afraid, I don't know - I didn't try it and there's a bug open about it - I'll try to find out
[01:29] <Zdra> dholbach: there is a bug about that ?
[01:29] <Zdra> Keybuk: did enabled ssl support and set port 5223 ?
[01:30] <dholbach> sorry, that was cohoba - bug 70215
[01:30] <Ubugtu> Malone bug 70215 in cohoba "Audio of Google Talk does not work" [Medium,Needs info]  http://launchpad.net/bugs/70215
[01:36] <Keybuk> Zdra: that seemed to be the trick, yes
[01:37] <twb> Mithrandir: ping?
[01:37] <Mithrandir> hi Trent
[01:37] <twb> Mithrandir: so I've been getting the hang of bzr doing merges of casper and casper/debian.
[01:37] <Mithrandir> twb: yay
[01:38] <Mithrandir> does that mean you have shiny branches for me to merge?
[01:38] <twb> One thing the debian branch does is move debian/changelog to debian/changelog.upstream, and then use that file iff the host is Ubuntu.
[01:38] <twb> i.e. one you merge my branch, you'd need to edit changelog.upstream instead of changelog.
[01:38] <twb> Is this a problem, ideologically?
[01:39] <seb128> fabbione: I would start by doing a retry on every of those
[01:40] <Mithrandir> twb: they seem to install it unconditionally.  I'd probably merge it, move the file back and rm the debian one.
[01:40] <dholbach> seb128: he left
[01:40] <twb> Well that's what I was doing, but the debian/rules file appears to (AFAICT) install the appropriate file depending on what host you build the .deb under.
[01:40] <twb> Same for the control file.
[01:41] <cjwatson> pitti: sorry, I screwed up slightly while processing the language packs and caused a few mails to -changes; I think only three or four or so
[01:41] <pitti> cjwatson: that won't hurt; thanks a lot for processing!
[01:42] <Mithrandir> twb: it seems to install the .upstream file unconditionally?
[01:42] <cjwatson> I managed to ctrl-c before it got too far
[01:42] <twb> Mithrandir: no.
[01:42] <Keybuk> Ctrl-C worked?
[01:42] <Keybuk> Normally I Ctrl-\ Soyuz :p
[01:42] <twb> Mithrandir: 
[01:42] <twb> ifeq ($(BUILD_SYSTEM),Debian)
[01:42] <twb> 	dh_installchangelogs -a debian/changelog.upstream
[01:42] <twb> else
[01:42] <twb> 	dh_installchangelogs -a
[01:42] <twb> endif
[01:42] <cjwatson> twb: the packaging toolchain relies on the version you're building being at the head of debian/changelog, so that won't work for us at all
[01:43] <seb128> dholbach: what do you mean? he's still on the chan, he'll probably read whenever he's in front of IRC again
[01:43] <twb> cjwatson: it works for me.
[01:43] <cjwatson> i.e. if you have to edit debian/changelog you'll get a source package with the wrong version number.
[01:43] <cjwatson> twb: have you tried dpkg-buildpackage?
[01:43] <twb> If I build it, I get version 1.79
[01:43] <twb> Yes.
[01:43] <dholbach> seb128: right, I meant to say that he's *currently* not there
[01:43] <cjwatson> what's at the head of debian/changelog and debian/changelog.upstream respectively?
[01:43] <twb> ==> changelog <==
[01:43] <twb> casper (1.68+debian-3) unstable; urgency=low
[01:43] <twb> 
[01:43] <twb> ==> changelog.upstream <==
[01:43] <twb> casper (1.79) UNRELEASED; urgency=low
[01:44] <Mithrandir> twb: I can't say I'm happy about renaming debian/changelog at all, but reverting that is easy enough to do.
[01:44] <Keybuk> you'll get 1.79 binaries, but a 1.68+debian-3 source
[01:44] <Keybuk> and probably a totally bogus changes file
[01:44] <cjwatson> what Keybuk said
[01:44] <twb> Keybuk: nope.
[01:44] <cjwatson> debian/changelog is hardcoded for source uploads
[01:44] <Keybuk> twb: yes.
[01:44] <seb128> dholbach: well, I pong with context, I don't need a reply now
[01:44] <twb> Well, dpkg-buildpackage gives me a 1.79 tar.gz
[01:45] <cjwatson> where is your branch?
[01:45] <Keybuk> twb: only if you've built it previously
[01:45] <Keybuk> twb: unpack the source fresh, and then run dpkg-buildpackage in it
[01:45] <Keybuk> twb: you'll get a 1.68+debian.tar.gz
[01:45] <dholbach> seb128: right...
[01:45] <twb> Keybuk: ok
[01:45] <Keybuk> debian/changelog is completely hardcoded
[01:46] <twb> Keybuk: again, I only get 1.79 files.
[01:46] <Mithrandir> Keybuk: (it's not, dpkg-genchanges can be passed -l)
[01:46] <cjwatson> Keybuk: ctrl-c ctrl-\ I think - I do it automatically nowadays so don't notice
[01:46] <cjwatson> Mithrandir: but isn't by our buildds
[01:46] <twb> cjwatson: http://twb.ath.cx/~twb/scratch/casper
[01:46] <twb> cjwatson: but it has unresolved conflicts
[01:46] <Keybuk> twb: can you upload this package somewhere for me to try?
[01:46] <twb> Keybuk: one moment.
[01:47] <Keybuk> oh, is that URL it?
[01:47] <twb> That's the bzr branch
[01:47] <twb> All I did was `bzr branch .../casper && cd casper && dpkg-buildpackage -rfakeroot'
[01:48] <twb> Note: that branch isn't properly cleaned up (yet), so actually installing it is a bad idea.
[01:48] <twb> Use dpkg -x to look inside it.
[01:48] <twb> That is, inside the .deb
[01:48] <cjwatson> dpkg -c
[01:49] <twb> That, too.
[01:52] <Keybuk> twb: the top revision in your debian/changelog is 1.79
[01:52] <cjwatson> that branch has no debian/changelog.upstream
[01:52] <Keybuk> and there's no changelog.upstream
[01:52] <twb> Perhaps bzr is behaving differently for you because you're doing a branch over http.
[01:52] <twb> Let me commit the merge, then try again.
[01:53] <Keybuk> you have to commit, yes :)
[01:53] <cjwatson> branch over http = branch over sftp
[01:53] <cjwatson> or locally or whatever
[01:53] <Keybuk> make sure you 'bzr add' any new files, etc.
[01:53] <LarstiQ> but uncommited changes can't be reached remotely :)
[01:54] <Keybuk> or locally :p
[01:54] <twb> LarstiQ: but they can if I branch locally over the filesystem? >confused<
[01:54] <Keybuk> twb: no, if you branch locally they can't be reached either
[01:54] <cjwatson> the files are available by http on twb's website, but no invocation of bzr, local or remote, will fetch them
[01:54] <Keybuk> bzr branch will only branch the committed changes
[01:54] <LarstiQ> Keybuk: there you have more leeway, like merge --uncommitte
[01:54] <Keybuk> of course, if you use "cp -a" to "branch locally", it'll copy the uncommitted changes
[01:55] <LarstiQ> right.
[01:55] <twb> http://twb.ath.cx/~twb/scratch/casper-merged/
[01:55] <cjwatson> pitti: langpacks done
[01:55] <pitti> \o/ cheers
[01:55] <LarstiQ> twb: sorry to confuse you, a `bzr branch` will not copy them.
[01:56] <twb> Hmm.
[01:56] <twb> I must have been looking at the wrong working tree when I was checking debian/changelog etc.
[01:57] <Keybuk> quest casper% dpkg-parsechangelog | grep Version
[01:57] <Keybuk> Version: 1.68+debian-3
[01:57] <Keybuk> quest casper% dpkg-parsechangelog -ldebian/changelog.upstream | grep Version
[01:57] <Keybuk> Version: 1.79
[01:57] <Keybuk> quest casper% dpkg-buildpackage  
[01:57] <Keybuk> dpkg-buildpackage: source package is casper
[01:57] <Keybuk> dpkg-buildpackage: source version is 1.68+debian-3
[01:57] <Keybuk> dpkg-buildpackage: source changed by Marco Amadori <marco.amadori@gmail.com>
[01:57] <Keybuk> dpkg-buildpackage: host architecture amd64
[01:57] <Keybuk> dpkg-buildpackage: source version without epoch 1.68+debian-3
[01:58] <Keybuk> generates 1.68+debian-3 sources
[01:58] <Keybuk> and 1.68_debian-3 debs
[01:58] <twb> You're right.
[01:58] <cjwatson> the more usual approach is to just change the files and let bzr remember what the other side has, rather than carrying around silly .debian and .ubuntu files
[01:59] <cjwatson> I believe Tollef has had debates with the Debian casper people about their packaging already ...
[01:59] <twb> So I should bzr rm the .debian file and bzr mv the .ubuntu one back to just debian/changelog?
[02:00] <Mithrandir> cjwatson: their first diversion is a commit with a diffstat of:  31 files changed, 957 insertions(+), 253 deletions(-)
[02:00] <cjwatson> yeah, same with debian/control if you haven't already
[02:00] <Mithrandir> somehow, I've put off merging that for a while. :-P
[02:00] <twb> OK.
[02:00] <cjwatson> (I see there's some weirdness there already, but debian/control is another hardcoded file and messing with it in the build process is a bad idea unless you REALLY know what you're doing)
[02:00] <twb> What will bzr do when the next merge from casper/debian tries to edit the (now deleted) file?
[02:01] <Keybuk> cjwatson: debian/control.in should be punishable by death
[02:01] <cjwatson> twb: I believe nothing (edit ignored) but at worst you get to resolve a conflict
[02:01] <twb> All the more reason to make debian/ a Scheme program instead of flat files! ^_^
[02:01] <twb> cjwatson: good-o.
[02:04] <twb> What about the stuff outside of debian/ that checks for Debian or Ubuntu at boot time?
[02:04] <twb> Should I leave it in, or revert it?
[02:05] <Mithrandir> twb: I'm fine with keeping that.
[02:05] <twb> Righto.
[02:06] <twb> Is there a convention for casper for recording GNU Coding Standards-style commit messages?
[02:06] <twb> (From bzr log, it appears not.)
[02:06] <Mithrandir> twb: no.  Just use what you put in debian/changelog.
[02:06] <tkamppeter> doko, ping
[02:06] <doko> tkamppeter: pong
[02:07] <twb> Hmm.  So for every commit I should put a note in debian/changelog?
[02:07] <tkamppeter> doko, can you have a look at bug 67892?
[02:07] <Ubugtu> Malone bug 67892 in hplip "HPLIP failed to start PyQt/Qt missing" [Medium,Confirmed]  http://launchpad.net/bugs/67892
[02:08] <tkamppeter> I have made a suggestion there about how to package HPLIP to fix the problem of Python/Qt not being there by default. WDYT?
[02:09] <Mithrandir> twb: make sure that every commit is documented in debian/changelog, yes.  Unless it's just fixing up an earlier commit in the same upload and the previous changelog entry covers it.
[02:09] <twb> OK.
[02:10] <doko> tkamppeter: the extra desktop file seems to be a merge error
[02:10] <twb> When I'm merging in casper/debian changes, it is sensible to put integrate their changelog entries into debian/changelog, or should I just add a single-line note `merged casper/debian rNNN' to the latest entry?
[02:11] <tkamppeter> doko, is somewhre an automatic mechanism which removes the "NoDisplay=true" lines in the .desktop files if Python/Qt is there?
[02:13] <Mithrandir> twb: in that case, I'd merge both the changelog entry and note it in the latest one too.
[02:13] <twb> OK.
[02:13] <doko> tkamppeter: what do you mean?
[02:15] <tkamppeter> doko, if we take the hplip.desktop away, as it is there in error, there remain 3 .desktop files (for hp-toolbox, hp-sendfax, and hp-fab) which all contain a line "NoDisplay=true". This means the entries do not get visible in the menus.
[02:15] <doko> tkamppeter: yes, that's intended
[02:16] <tkamppeter> Now if the user has Python/Qt on his system (either a Kubuntu or package installed manually) the menu entries still tay invisible.
[02:16] <tkamppeter> This would mean that the user has to open the menu editor to make them visible.
[02:16] <geser> doko: I overlooked your sync request for wireshark and did a merge. should i close the sync request?
[02:17] <pitti> geser: depends on whether the remaining ubuntu delta is actually relevant
[02:18] <Mithrandir> pitti: if it's merged, it can't be synced until a new version is uploaded into debian
[02:18] <doko> geser: well, that sync request is obsolete, independent of the the merge was necessary or not.
[02:18] <simontol> hi
[02:18] <pitti> Mithrandir: right, but we should keep track that it can be synced on the next possibility
[02:18] <simontol> anyone here who tried Feisty-Herd1 CD?
[02:18] <tkamppeter> I am asking now whether there is an automatic mechanism somewhere which removes the "NoDisplay=true" lines when Python/Qt is/gets installed.
[02:18] <doko> tkamppeter: no
[02:18] <Mithrandir> simontol: yes, people test it before it's released.
[02:19] <simontol> I can't install... It freezes just after selecting keyboard type
[02:20] <simontol> Is there a way to install w/out GTK installer?
[02:20] <Mithrandir> simontol: use the alternate CD?
[02:20] <tkamppeter> So no I am suggesting in that bug report instead of using "NoDisplay=true" lines moving the .desktop files into a separate package named "hplip-gui" which requires Python/Qt.  If the user installs "hplip-gui" Python/Qt gets automatically installed.
[02:20] <Mithrandir> seb128: libslab0 should go to main, I presume?
[02:20] <simontol> Does alternate CD have PPP support ? 
[02:21] <seb128> Mithrandir: yep, gnome-control-center Depends on it
[02:21] <Mithrandir> seb128: cheers, thanks.
[02:21] <seb128> Mithrandir: thank *you* for looking at it ;)
[02:22] <Mithrandir> seb128: oh, no trouble.  Figured I'd do a bit of NEW.
[02:23] <simontol> Mithrandir : I can install edgy and then upgrade too , do you agree?
[02:23] <Mithrandir> simontol: yes, that would work too.
[02:24] <Mithrandir> simontol: but you really don't want to run feisty unless you are interested in the development of Ubuntu, it's not ready for end-user usage.
[02:24] <simontol> Yes I'll keep Edgy on separate parttiton
[02:24] <simontol> *partition
[02:27] <tkamppeter> pitti, have you already uploaded splix (bug 59829 and bug 44407)?
[02:27] <Ubugtu> Malone bug 59829 in Ubuntu "No driver for Samsung ML-1610 printer" [Wishlist,Needs info]  http://launchpad.net/bugs/59829
[02:27] <Ubugtu> Malone bug 44407 in foomatic-db "Samsung clp510 not working" [Medium,Needs info]  http://launchpad.net/bugs/44407
[02:27] <cjwatson> simontol: this is a known problem with some graphics cards (we think); it's still under investigation
[02:29] <simontol> I thought It was GPU rpoblem...
[02:29] <Mithrandir> simontol: does it work for you if you go to the console with ctrl-alt-f1 and then back with alt-f7?
[02:30] <Mithrandir> cjwatson: speaking of this; I see the same on simira's laptop, so if there's anything I can do to help debug it usefully..
[02:30] <simontol> I tried to restart X several times but I freezes every time just after keyboard type selcting (step 4 of7)
[02:31] <Mithrandir> simontol: don't restart X, just change to another virtual console and then back.
[02:31] <simontol> I'll try this.
[02:32] <simontol> So You're saying there is no other method then gtk-installer to setup with desktop-cd
[02:33] <Mithrandir> yes
[02:33] <simontol> I'll reboot now  and try your  solution, see you later ... Thanks
[02:34] <bhale> -
[02:34] <bhale> < simontol> So You're saying there is no other method then gtk-installer to setup with desktop-cd
[02:34] <bhale> ugh, sorry
[02:34] <bhale> (morn all)
[02:34] <Mithrandir> morning, tseng
[02:37] <Mithrandir> Adri2000: please tell the homebank upstream author to update the FSF address in the source (including all the GPL header blurbs)
[02:42] <cjwatson> Mithrandir: bug 73955 has a reduced test case; maybe you could dig down through that?
[02:42] <Ubugtu> Malone bug 73955 in console-setup "Clobbered X screen state during installation" [High,Confirmed]  http://launchpad.net/bugs/73955
[02:42] <elkbuntu> Mithrandir, cjwatson, i dont have complete x freeze/warp/whatever, cjwatson's seen my pics of it.. but what you suggested works here fwiw
[02:43] <Mithrandir> cjwatson: I see it again and again for the later pages as well, iirc.
[02:43] <Mithrandir> cjwatson: I'll ask her to test when she's back.
[02:48] <twb> Well, the merging the first casper/debian-only revision doesn't work, because casper-snapshot doesn't exist.
[02:49] <twb> How can I look to see when that file was added, in the debian branch?
[02:49] <twb> It exists in the tip.
[02:49] <Mithrandir> dholbach: please tell gnome-specimen upstream to update the FSF address in the package.
[02:51] <Mithrandir> twb: unsure, try doing a binary search for it.
[02:52] <twb> This seems to work:
[02:52] <twb> bzr annotate casper-snapshot | grep -o '^ *[0-9] \+' | sort -n | uniq | head -1
[03:18] <cjwatson> Mithrandir: that's even weirder
[03:27] <truz_`24> So, if someone says "my ubuntu box keeps locking up, when i restart it, it takes a while to come back up" what do you look at first?
[03:27] <truz_`24> Logs don't seem to suggest any problems :-(
[03:29] <twb> truz_`24: binary drivers
[03:47] <simontol_>  Mithrandir : I'm back your ctrl-alt-F1 + alt-F7 suggestion worked
[03:47] <simontol_>  Thanks
[03:47] <Mithrandir> simontol_: cool, thanks.
[03:47] <simontol_> I have another question ... Don't know if this is the right place...
[03:48] <simontol_> I have to patch usbserial module in kernel 
[03:48] <simontol_> Do I have to compile all from sources to do this?
[03:48] <dholbach> Mithrandir: will do - did you reject it because of that?
[03:49] <Mithrandir> dholbach: no, I rejected decibel because of no licence in the orig.tar.gz, gnome-specimen was accepted.
[03:50] <dholbach> Mithrandir: will chase upstream up - thanks a lot
[03:50] <Mithrandir> dholbach: I don't reject packages based on having the old FSF address in the GPL blurb.  I don't have _that_ much free time. :-)
[03:51] <dholbach> I'm glad to hear that. ;-)
[03:51] <Mithrandir> dholbach: tapioca-qt should have its FSF address updated too
[03:52] <dholbach> alrighty - will try to check the next packages before they hit NEW :)
[03:52] <Mithrandir> don't let it hold you up; but if you'd chase upstream up about it -- excellent
[03:52] <dholbach> yeah no prob
[04:01] <ogra> pitti, when did you approve gobby ? its listed under approved on the main inclusion queue
[04:01] <pitti> ogra: oh, long time ago, when you kept asking me about it :)
[04:02] <ogra> hmm
[04:02] <ogra> i was under the impression you never approved it ... weird ...
[04:02] <ogra> so time to add it to the seeds, thanks :)
[04:04] <bddebian> Heya
[04:05] <ogra> slomo_, so your fix to bug 65690 makes sure the gstreamer db is regenerated on every login so that the right sink is selected if i switch from being logged in on the server (alsa/dmix) to a ltsp client (esd) ?
[04:05] <Ubugtu> Malone bug 65690 in ltsp "should select the esdsink for LTSP_CLIENTs" [High,Fix released]  http://launchpad.net/bugs/65690
[04:07] <ogra> (pulse isnt used in edubuntu yet, and surely wont be used for local users, only for ltsp)
[04:09] <ogra> pitti, ^^^^ ?
[04:09] <ogra> (just saw your mail)
[04:10] <pitti> ogra: right, but if you use it for LTSP by default, then the bug is settled, right?
[04:10] <ogra> the explanation slomo_ gave in the bug doesnt look like it ...
[04:10] <ogra> thats why i asked
[04:11] <ogra> "Order is (if installed) pulse > alsadmix > esd > alsa > oss..."
[04:11] <pitti> ogra: we just ditched the patch since it was broken anyway
[04:11] <ogra> i dont care about the order ...
[04:11] <pitti> ogra: if you want to continue using esound for ltsp, then we need to write a new patch
[04:11] <ogra> i care about dynamically swit5ching the sink based on where i'm logged in
[04:11] <pitti> ogra: but if you use pulse, then it should just work now
[04:11] <BenC> Can someone push linux-source-2.6.20 through NEW processing please?
[04:11] <ogra> pulse is the plan... but not there yet ...
[04:11] <twb> Mithrandir: what's the policy on bashisms in #/bin/sh scripts in casper?
[04:12] <Mithrandir> twb: /bin/sh => no bashisms allowed.
[04:12] <twb> quite a few export PATH=blah's.
[04:12] <pitti> ogra: ok, if you need that dynamic switch, we need to add an ltspesdsink
[04:13] <Mithrandir> twb: that's POSIX, or at least supported by dash
[04:13] <twb> Hmm, OK.
[04:13] <Mithrandir> The shell allows the value of a variable
[04:13] <Mithrandir>             to be set at the same time it is exported by writing
[04:13] <Mithrandir>                   export name=value
[04:13] <ogra> pitti, well, i'm fine with it as long as it switches dynamically ... i dont think we'll need any esd crap, but i cant test the patch before pulse is integrated
[04:13] <Mithrandir> BenC: main, I presume?
[04:13] <BenC> Mithrandir: yes please :)
[04:14] <twb> Mithrandir: one of the debian changes makes it only honor the last access=X boot parameter.
[04:14] <pitti> ogra: it won't; if you have pulse installed, it'll always use the pulse sink
[04:14] <ogra> hmm
[04:14] <twb> Mithrandir: it is likely that someone would want something like access=m1 access=v1?
[04:14] <ogra> pitti, even if i dont use pulse ? 
[04:14] <ogra> i.e. if its not running
[04:14] <pitti> ogra: if pulsedaemon is not running, it'll fall back to alsa
[04:15] <ogra> great
[04:15] <ogra> thats what i need :)
[04:15] <Mithrandir> twb: unsure; Henrik would know.  I don't see a reason to make it unsupported.
[04:15] <pitti> ogra: i. e. the autoaudiosink just detects availability and uses what works: first pulse, then alsadmix, then esd, then alsa
[04:15] <ogra> good
[04:15] <pitti> ogra: but it will *not* change the order of the sinks that it tries dynamically
[04:15] <ogra> i'll drop my workaround from ltsp then :)
[04:15] <Mithrandir> BenC: done
[04:15] <pitti> (that's what we did in dapper)
[04:15] <twb> Mithrandir: the only reason is that bzr can get quite confused if you try to back out changes from one branch, but not both.
[04:16] <BenC> Mithrandir: thanks!
[04:16] <pitti> ogra: great
[04:16] <ogra> even its sad to lose that file ;)
[04:16] <twb> Mithrandir: oh wait
[04:16] <twb> Nope, nm
[04:16] <ogra> its handy to have something to influence the session
[04:16] <pitti> ogra: oh, is it?
[04:16] <Mithrandir> twb: you can merge a change, then revert the actual change to the files and it won't try to merge it later.
[04:16] <Mithrandir> but, I need to pick up some dinner, so I'm afk for a while now.
[04:16] <twb> Well, clearly I'm doing it wrong.
[04:17] <ogra> pitti, well, to abuse it for other stuff than sound ;)
[04:18] <pitti> ogra: hehe; well, then just keep an empty skeleton file around
[04:18] <ogra> yeah, that was my idea :)
[04:20] <simira> cjwatson: I reproduced the bug (the one with screen going black after choosing keyboard layout)
[04:38] <pitti> is any Ubuntu Weekly News editor here? It seems that https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Ideas is obsolete; where to send suggestions to?
[04:40] <seaLne> BenC: http://behindubuntu.org/interviews/BenCollins/
[04:41] <BenC> seeLne: sweet, I'll be famous :)
[04:41] <seaLne> heh
[04:43] <twb> Mithrandir: ok, I made a dodgy-ass merge that at least builds correctly.
[04:43] <twb> I'm gonna try sticking it in a live cd now, but first I need to update transmuter to install new initramfses correctly under Ubuntu.
[04:47] <dholbach> BenC: haha... your hot teacher in 4th grade... hahaha :-)
[04:50] <cjwatson> simira: right, somebody needs to dig into it and figure out exactly what's failing
[04:50] <cjwatson> insanely hard to do remotely ...
[04:52] <simira> cjwatson: well, I kinda know this colleague of yours...
[04:53] <cjwatson> uh-huh :)
[04:53] <cjwatson> just emphasising that it's hard to help from this end beyond providing a starting point
[04:54] <simira> cjwatson: well, I really have no clue what this bug is about. But Tollef might have an idea.
[04:58] <\sh> benc: nice interview :)
[04:58] <BenC> \sh: thanks
[05:11] <lamont> mdz: you around yet?
[05:21] <lamont> mdz: fixed postfix uploaded to debian, will hit the archive in today's dinstall - so whenever that syncs, the update-inetd thing will be happy
[05:35] <psusi> anyone feel like sponsoring a backport upload?  the dmraid package that shipped with edgy was fubar... the one now in feisty is good... a number of users have had their systems broken by this and would like the fixed version uploaded to -backports, or to the main universe repo if possible
[05:35] <psusi> seeing as how the released one was fubar
[05:59] <fabbione> cjwatson, Mithrandir: can i beg you to promote network-console to main so that tomorrow morning when my son will wake me up at 4am i will have something to work/test ?
[05:59] <fabbione> and with this last pray i am off for the evening
[06:02] <pitti> bye fabbione 
[06:02] <kylem> night fabio
[06:07] <cjwatson> fabbione: done
[06:28] <jdong> out of curiousity, how helpful has -fstack-protector been in  protecting Edgy?
[06:28] <jdong> I see a few buffer overflow USN's for edgy already... would those have been exploitable with stack protector (apart from just killing the app in question)
[06:42] <Keybuk> pitti: be interesting to see how many people trip over the fact that you can't create ad-hoc networks if  you have an atheros card :)
[06:43] <pitti> Keybuk: oh, the driver doesn't support ad-doc mode?
[06:43] <Keybuk> pitti: the driver is stupid
[06:43] <Keybuk> you create virtual interfaces, and each virtual interface has a mode set
[06:43] <Keybuk> ath0 is one such virtual interface
[06:43] <Keybuk> and the default one is always in the managed mode
[06:44] <Keybuk> to make an adhoc one, you have to use wlanconfig on wifi0 to remove the ath0 virtual and make a new one in ad-hoc mode
[06:45] <_ion> Wow. :-)
[06:45] <_ion> That's really great engineering.
[06:45] <Keybuk> it has some advantages
[06:45] <Keybuk> e.g.
[06:45] <Keybuk> wlanconfig ath0 create wlandev wifi0 wlanmode ap
[06:45] <Keybuk> wlanconfig ath1 create wlandev wifi0 wlanmode ap
[06:45] <Keybuk> ifconfig ath0 10.x.x.x
[06:45] <Keybuk> ifconfig eth1 192.168.x.x
[06:46] <Keybuk> echo 1 > /proc/sys/net/ipv4/ip_forward
[06:46] <Keybuk> etc.
[06:46] <Keybuk> uh, s/eth1/ath1/ in that example :p
[06:46] <_ion> I don't have a problem with that, but not being able to *change* the wlanmode is quite stupid. :-)
[06:47] <Keybuk> yes
[06:47] <Keybuk> they should support the ioctl to change the mode of an existing virtual interface
[07:33] <mdz> lamont: ok, if it's unmodified in ubuntu then that's just ducky
[07:44] <LaserJock> mdz: you got a minute? I need your opinion about a possible SRU
[08:06] <mdz> LaserJock: cjwatson is the primary point of contact for SRUs, but I can have a quick look
[08:07] <LaserJock> mdz: well, it's bug #75021 and #74906
[08:07] <Ubug2> Malone bug 75021 in python-imaging "critical missing dependencies (edgy)" [Unknown,Fix released]  http://launchpad.net/bugs/75021
[08:07] <Ubug2> Malone bug 74906 in psycopg "python-psycopg: Missing dependencies? (libc6, libpq4)" [Unknown,Fix released]  http://launchpad.net/bugs/74906
[08:08] <LaserJock> mdz: basically ${shlibs:Depends} got dropped on a couple python transitions
[08:08] <LaserJock> mdz: my concern is that the dropped deps are picked up by many Desktop packages
[08:08] <LaserJock> mdz: so it's really only a problem for server people
[08:09] <mdz> LaserJock: looks definitely worth fixing
[08:09] <cypher1> Keybuk, hi
[08:09] <Keybuk> cypher1: hi
[08:09] <LaserJock> mdz: ok, I just wanted to ask because of the somewhat limited scope
[08:09] <mdz> low risk, completely breaks the package for a substantial number of folks
[08:09] <cypher1> Keybuk, sorry for disturbing still with bug 66637
[08:09] <Ubug2> Malone bug 66637 in util-linux "After running mkswap, swap space is discarded, system fails to hibernate (invalid swap signature)" [High,Confirmed]  http://launchpad.net/bugs/66637
[08:10] <LaserJock> mdz: ok great, just didn't want to seems stupid when I showed up with a debdiff
[08:10] <Keybuk> cypher1: yes?
[08:10] <mdz> LaserJock: np
[08:10] <cypher1> cypher1, but to end up with the same problem even i had not run mkswap.. i had just upgraded from dapper -> edgy
[08:10] <Keybuk> cypher1: then you have a different bug
[08:10] <Keybuk> you should file  a new one
[08:10] <Keybuk> to avoid confusion
[08:11] <cypher1> Keybuk, no suddenly in between i saw the "invalid signature" for swap sprang up from somewhere 
[08:12] <Keybuk> cypher1: that bug is purely that mkswap generates a new UUID when run over an existing swap partition
[08:12] <Keybuk> if you have a different problem ("I upgraded and lost my swap space") then you have a different bug
[08:12] <cypher1> Keybuk, ok thanks
[08:12] <Keybuk> and when that bug is marked "Fix Released", you won't have had your problem solved
[08:12] <Keybuk> although the symptoms may sound a little similar, the problem will be totally different
[08:13] <Keybuk> we prefer to have one bug per problem, rather than one bug per symptom
[08:13] <cypher1> Keybuk, is mkswap run during upgradation ?
[08:13] <Keybuk> otherwise we go mad, and start gibbering :p
[08:13] <Keybuk> cypher1: it's not supposed to be
[08:13] <cypher1> Keybuk, :)
[08:13] <cypher1> Keybuk, if a swap exists and we use it, right ?
[08:13] <Seveas> Keybuk, the upstart announcement was sent to the @netsplit.com list, shouldn't that be the @lists.ubuntu.com list?
[08:14] <Keybuk> Seveas: oops
[08:14] <Keybuk> :)
[08:14] <Seveas> Keybuk, btw: upstart makes one of my projects sooooooooooooo much cleaner - for that alone I almost got a raise ;)
[08:15] <Keybuk> "almost" ? :-(
[08:16] <Seveas> hey, I work there only since late october, give them a break ;) I already got a big christmas bonus ;)
[08:26] <fabbione> cjwatson: thanks a lot
[08:57] <jdong> how does ubuntu automagically reconfigure xorg.conf when I boot it up on different hardware?
[08:58] <jdong> where is it detected that the configuration changed and dpkg-reconfigure xserver-xorg run?
[09:01] <jdong> speaking of magic
[09:01] <jdong> the bad kind....
[09:01] <jdong> http://ubuntuforums.org/showpost.php?p=1881753&postcount=107
[09:01] <jdong> please tell me that's PEBKAC
[09:01] <Burgwork> jdong: likely using a 3rd party nvidia driver
[09:02] <jdong> Burgwork: I hope so...
[09:02] <jdong> though the ABI for the recent kernel update wasn't bumped
[09:02] <jdong> it's still 2.6.17-10
[09:03] <jdong> so that means that all current modules should still work for the new kernel update, right?
[09:04] <keescook> jdong: they were pretty careful about making sure the ABI didn't change.
[09:04] <jdong> ok
[09:04] <jdong> then my next theory is an nvidia-glx mismatch
[09:04] <jdong> the 3rd party 9xxx repos must've been too conservative in their version numbering
[09:04] <jdong> and 87xx nvidia-glx userland must've overridden their 9xxx's
[09:05] <keescook> I hope so... *cringe*
[09:05] <Burgwork> yay! 3rd party repos
[09:05] <Burgwork> on the matter of support, I just learnt that my largest customer has been calling support every day
[09:06] <Burgwork> for three months...
[09:06] <jdong> Burgwork: trying to tell people to wait 6 months for beryl AIGLX is a lost cause... ? ;-)
[09:06] <jdong> keescook: I think so. Most people are using 9xxx nvidia's for beryl-mania
[09:07] <jdong> one person reports nvidia breakage with self-compiled nvidia binary drivers, with nvidia-glx uninstalled and lrm nvidia blacklisted
[09:07] <jdong> that worries me
[09:10] <delire> i'm writing an application for Ubuntu in Python that requires the user provide a password for sudo via a widget console. 
[09:10] <Treenaks> delire: why not use gksudo?
[09:11] <delire> i'm successfully using the pexpect module on a Debian unstable system to send a password to sudo, but on Ubuntu this fails due to sudo wanting the password itself to be sent by a root user. are there any strategies that might suit better?
[09:11] <jdong> delire: you should call gksu
[09:11] <delire> Treenaks: how is gksudo different from sudo?
[09:11] <jdong> delire: to pop up a GTK dialog for sudo...
[09:11] <delire> <-- long time Debian user /me greps
[09:11] <jdong> delire: gksudo/gksu interface with pam and sudo directly
[09:11] <delire> jdong: no, this is a fullscreen application. this isn't possible.
[09:11] <jdong> delire: or you can look at their source and do something similar tot hem
[09:12] <delire> hmm.. perhaps.
[09:12] <jdong> delire: but you shouldn't be prompting for a password and pexpecting it
[09:12] <jdong> that's just not safe
[09:12] <delire> i'm really hoping for a Python interface.
[09:12] <delire> jdong: it seems to be safe, having read documentation on it and looking at memory.
[09:12] <Treenaks> there's a libgksu 
[09:12] <Treenaks> maybe it has bindings in pythno
[09:12] <delire> Treenaks: interesting.. cheers
[09:14] <delire> Treenaks: hmm it seems to have no Python bindings. i may write some if i get time later.
[09:15] <LarstiQ> delire \o/
[09:15] <delire> LarstiQ: hey ;)
[09:19] <delire> on a related note, one thing i notice quitting my application while it's in fullscreen mode on Dapper (at least) is that i'm dumped back into X in a 'zoomed' mode. is this likely a fault of Xorg on Dapper or my application?
[09:19] <twb> Mithrandir: I just tried to install my whizz-bang merged casper, and I get 
[09:19] <twb> [: 43: ==: unexpected operator
[09:19] <twb> when running `update-initramfs -u'.  However, I can't find any source file with an inadequately quoted test(1) clause.  Any idea where this might be coming from?
[09:19] <delire> (it's an SDL application btw)
[09:19] <twb> delire: try Ctrl+Alt+KP_Minus
[09:20] <delire> twb: cheers, that's all very well but i'd rather users don't have to do this.
[09:20] <Treenaks> how do you set fullscreen mode?
[09:20] <Treenaks> just map a window right? no cracky vidmode extensions etc.
[09:20] <twb> I think the correct way to avoid it is to not segfault the SDL application.
[09:21] <delire> Treenaks: nope, just a mapped window.
[09:21] <delire> twb: it's not segfaulting, it's quitting gracefully according to the stack trace.
[09:21] <twb> Can't help.
[09:21] <twb> Try #sdl or whatever.
[09:22] <delire> twb: right, so it is a likely problem of my application.
[09:22] <twb> It's almost certainly NOT an ubuntu-specific problem, and therefore not on-topic for #ubuntu-devel.
[09:23] <delire> twb: ok, good to have established that. i only ask as i don't have the problem on my Debian box running Xorg7.
[09:23] <twb> I see.
[09:23] <twb> Still, #ubuntu is more appropriate than #ubuntu-devel.
[09:24] <delire> twb: well, i'm developing an application i hope to maintain for Ubuntu, but sure.
[09:24] <twb> (Note: this are just my opinions.  Others may disagree.)
[09:33] <Mithrandir> twb: == is a bashism, use =
[09:34] <twb> Er, [ is a binary.
[09:34] <twb> It has nothing to do with bash.
[09:34] <Keybuk> the [ binary only accepts =
[09:34] <Keybuk> it's the bash builtin that accepts ==
[09:34] <twb> You're right.
[09:34] <twb> Stupid bash.
[09:34] <Keybuk> scott@syndicate:~$ type [
[09:34] <Keybuk> [ is a shell builtin
[09:35] <twb> Aha, yes.
[09:35] <twb> The next question is, did they mean string= or number= ?
[09:35] <Keybuk> = is string equal
[09:35] <Keybuk> -eq is integer equal
[09:35] <twb> Right.
[09:36] <Mithrandir> twb: they meant =
[09:36] <twb> But I'm discovering Marco's typos, not making them myself.
[09:36] <twb> Mithrandir: righto.
[09:36] <Mithrandir> if [ "${BUILD_SYSTEM}" == "Ubuntu" ] ; then
[09:36] <twb> If it was up to me, we'd all write sh in this style:
[09:36] <twb> if test "$x" = "$x"
[09:36] <twb> then foo
[09:36] <twb> fi
[09:37] <Keybuk> heh, I remember when people used to claim test was more portable than [
[09:37] <twb> All those nasty semicolons everywhere... yecch.
[09:37] <Keybuk> because they'd been used to only using test in autoconf macros
[09:37] <Keybuk> (when, in fact, that was because [ ... ]  is a quote character in m4 :p)
[09:37] <twb> I use test over [ because [ looks ugly, and newbies forget the mandatory spaces.
[09:41] <psusi> what's a shell script way to take a STRING="foo bar" and split it into two strings, one with "foo" and one with "bar"?
[09:41] <twb> psusi: ${STRING% *}
[09:42] <jdong> ok, guys, nvidia problem for you...
[09:42] <twb> psusi: ${STRING##* }
[09:42] <twb> psusi: see also #bash.
[09:42] <psusi> hrm....
[09:42] <jdong> if you have a non-lrm nvidia kernel, after installing today's update you will get the following error:
[09:42] <jdong> FATAL: Could not open 'lib/modules/2.6.17-10-generic/nvidia/volatile/nvidia.ko': No such file or directory
[09:42] <jdong> a subsequent depmod -ae fixes this
[09:42] <_ion> Why have a non-lrm nvidia kernel module?
[09:43] <jdong> _ion: i.e. 9xxx-series beryl crack etc
[09:44] <_ion> jdong: Why not build your own l-r-m package with an updated nvidia driver?
[09:44] <jdong> _ion: that appears to have been broken by today's kernel update too
[09:44] <jdong> though I'm only 90% sure of that
[09:44] <jdong> still trying to get in touch with users
[09:44] <jdong> reproducing this
[09:45] <jdong> so far I fixed a few users' problems just by depmod -ae
[09:45] <jdong> still trying to get to the bottom of this
[09:48] <tkamppeter> pitti, ping
[09:56] <twb> Mithrandir: the debian merge changed the default username and hostname to `casper' and `live' respectively.  Should these be changed back to `ubuntu'?
[10:00] <twb> I notice the isolinux.cfg for Edgy includes a ramdisk_size kernel argument.   What does this do, and what are the consequences of changing the ramdisk without updating or removing this argument?
[10:04] <alex-weej> is beryl for feisty a dead cert?
[10:04] <alex-weej> or is there still time to persuade the naysayers that METACITY IS THE OBVIOUS CHOICE GRR :P
[10:05] <jdong> it's over
[10:05] <alex-weej> damn
[10:05] <jdong> until metacity spins cubes, makes windows pop out, or simulates hurricane Katrina
[10:05] <jdong> it's a lost cost
[10:05] <jdong> cause *
[10:05] <alex-weej> naeh
[10:05] <alex-weej> that's ridiculous
[10:06] <alex-weej> i'm actually pretty upset that we're throwing out gnome software yet again
[10:06] <twb> alex-weej: who cares, nobody uses the default WM
[10:06] <alex-weej> it's like the firefox vs. epiphany thing all over again
[10:06] <twb> People who don't care enough to choose a better WM will buy an Apple Mac instead of running Ubuntu.
[10:06] <jdong> of course firefox
[10:06] <jdong> sheesh
[10:06] <jdong> unless you don't like having your print dialog options
[10:07] <seb128> alex-weej: I would prefer compiz
[10:07] <seb128> and it's not decided on beryl, no
[10:07] <twb> It's not like GNOME actually makes usable software.
[10:07] <alex-weej> ...
[10:08] <seb128> twb: not the right chan to troll
[10:08] <twb> Yeah, sorry.
[10:08] <seb128> twb: could you use an another chan for that?
[10:08] <seb128> np
[10:08] <twb> GNOME makes me angry.
[10:08] <alex-weej> ok ok 
[10:08] <twb> Like a lot of other stuff.
[10:08] <alex-weej> go to #ubuntu and talk about that
[10:08] <seb128> well, not the right place to speak about your frustation though
[10:08] <twb> yeah.
[10:08] <alex-weej> seb128: has metacity been totally disqualified from the race?
[10:09] <seb128> alex-weej: it'll be available and used for "slow" machines
[10:09] <seb128> alex-weej: and switching to it will be like one click
[10:09] <twb> seb128: you mean the installer will automagically pick one of the two?
[10:09] <alex-weej> does it not make sense to put the effort into making metacity optionally do the fancy stuff than maintaining two WMs?
[10:10] <seb128> twb: no, compiz or beryl should rather fallback to run metacity if they decide they can't work correctly
[10:10] <twb> Ah, at runtime.
[10:10] <twb> Good, good.
[10:10] <alex-weej> means too much inconsistency
[10:10] <alex-weej> they are merely two apps pretending that they are each other plus or minus features
[10:10] <seb128> alex-weej: according to redhat and novell guys who looked at it it's easier to write a composite manager from scratch and make it manage windows than to make metacity being a composite manager
[10:11] <alex-weej> interesting
[10:11] <alex-weej> i won't pretend to understand the situation, it just saddens me a bit
[10:11] <seb128> well, it's not perfect
[10:11] <seb128> and nobody is 100% happy about it
[10:11] <seb128> but there is no other way around
[10:11] <alex-weej> let's be honest
[10:12] <Fujitsu> Does anybody really think Beryl is going to be stable enough?
[10:12] <alex-weej> what's the goal here, to make the best software we can? or to get one up on Vista?
[10:12] <mdke> both of those
[10:12] <imbrandon> both
[10:12] <alex-weej> it seems the second goal is just dragging us along with decisions we don't want to have to make yet
[10:13] <alex-weej> there are a zillion other areas that need to be caught up with first
[10:13] <alex-weej> like webcams and video conferencing
[10:13] <seb128> Fujitsu: not me
[10:13] <mc44> alex-weej: this really isnt the place to discuss this. If you have a problem with the decision, bring it up with the Technical Board
[10:13] <alex-weej> or wireless networking
[10:41] <alex-weej> jdong: does Firefox support session management yet?
[10:41] <jdong> alex-weej: 2.0 does
[10:41] <alex-weej> jdong: any reason why session saving is disabled by default in Ubuntu?
[10:41] <jdong> alex-weej: it isn't
[10:41] <slomo_> ogra: sorry that my explanation was not verbose enough... but i saw that you discussed it with pitti already and now like it ;)
[10:41] <jdong> alex-weej: killall -11 firefox-bin
[10:41] <alex-weej> jdong: x session that is
[10:41] <jdong> or killall -9
[10:42] <alex-weej> jdong: i mean desktop sessions
[10:42] <jdong> X session management?
[10:42] <jdong> oh
[10:42] <jdong> I don't think it supports that
[10:48] <Mithrandir> twb: you can merge it and then revert the content of the merge.
[10:49] <twb> That is what I'm doing.
[10:50] <twb> I'm asking about specific changes because I'm not sure if they are wanted by Ubuntu; what Ubuntu wants is not something I can answer.
[10:51] <twb> http://twb.ath.cx/~twb/scratch/casper now builds and installs and boots (under qemu) on a vanilla Ubuntu 6.10 livecd.
[10:52] <twb> I'm now building netboot images to see if they work, too.  (Netbooting wasn't supported in casper 1.78.)