[12:34] <pwnguin> (or is it capital?_
[12:35] <thully> the battery brightness is subtracted from 100 and then used as the brightness - thus, setting battery brightness to 100 causes brightness to be set to 0
[12:35] <thully> Offending line in gpm-backlight.c: scale = (100 - value) / 100.0f;
[12:36] <thully> should be scale = value / 100.0f;
[12:36] <pwnguin> you sure?
[12:36] <Keybuk> thully: I've just worked out why nobody's replied to your bug
[12:36] <Keybuk> you Confirmed it yourself
[12:36] <pwnguin> heh
[12:36] <Keybuk> we used Confirmed to mean that a developer's looked at it
[12:37] <Keybuk> so everyone would've just skipped past it assuming someone else was looking at it
[12:37] <thully> I didn't see that - Launchpad is so very confusing to me (I'm used to bugzilla)
[12:37] <pwnguin> thully: g-p-m's frontend says "dim display brightness by"
[12:37] <pwnguin> I'd agree that it's confusing
[12:38] <thully> OK - so then battery brightness should be set to 0 to not dim
[12:38] <pwnguin> yes
[12:38] <thully> Kybuk:  I was under the impression that "confirmed" was simply to indicate that there is enough info to pinpoint the issue to something...
[12:38] <pwnguin> not exactly intuitive if you're expecting symmetrical interface
[12:39] <pwnguin> thully: even if you feel there was enough evidence, you shouldn't confirm it yourself. confirmation bias and all that
[12:39] <Keybuk> thully: generally speaking, the reporter should always leave their own bugs at New
[12:40] <thully> the gconf key has a bad description in that case: "The brightness of the display when on battery power. Possible values are between 0 and 100"
[12:41] <pwnguin> i think the basic problem is that the dim on battery will cut by a percentage
[12:41] <pwnguin> and dim on idle will simply set a new value irrespective
[12:43] <thully> Keybuk: sorry about that, I tried to figure out what "confirmed" meant, but I obviously got the wrong definition.  I figured that it was just to say "there is enough evidence to confirm a problem here" and that devs would basically ignore it until it reached this state.
[12:44] <thully> Obviously I was off by a mile.
[12:44] <pwnguin> Keybuk: there's some gconf keys in apps/gpm/ambient that might be interesting for you if you're looking at for software regressions.
[12:45] <Keybuk> at this point in the release cycle, we're looking for "my laptop explodes" regressions
[12:46] <pwnguin> its your laptop with the sensor, i figured you might be interested anyways
[12:47] <thully> Yes - I just hope that this g-p-m is not shipped with these kind of bugs.  Brightness seems to do all kinds of funky things in this release of g-p-m...
[12:48] <Keybuk> these bugs aren't release critical though
[12:49] <Keybuk> pwnguin: tbh, I suspect that it's the -intel driver that's causing the sensor to not work
[12:49] <thully> Gutsy seems good in my experience, except for 1) NetworkManager keeps crashing (but it's really a madwifi issue) 2) intel X driver randomly crashes on restart 3) gnome-power-manager is FUBAR
[12:49] <Keybuk> thully: I reject the last statement, g-p-m appears to be working quite normally most of the time
[12:50] <thully> Keybuk: on a laptop, with dimming enabled?
[12:50] <Fujitsu> thully: Where `crashes' means on a VT-switch you get massive screen corruption with flashing gray blocks?
[12:50] <Keybuk> there's a lot more to g-p-m than just dimming
[12:50] <thully> Fujitsu: yes, but it also happens on suspend-to-RAM
[12:51] <thully> which changes the VT as part of its process
[12:51] <thully> Also happens when X is restarted
[12:51] <Fujitsu> thully: Yep, there was a bug on that, which I think was fixed. But I still get it after latest updates.
[01:10] <sladen> thully: something is broken is the gpm ac/battery brightness at the moment
[01:10] <sladen> thully: do have the bug numbers etc?  (I know there's at least one dup ... the one I filed!)
[01:10] <thully> the Ubuntu ones or the upstream ones (I just filed them upstream)...
[01:12] <thully> Also, what problem do you mean in particular?  I've identified about 5 with the idle dim logic in 2.20...
[01:12] <sladen> thully: if you have links to either, we can start plugging them together...
[01:13] <sladen> thully: the one I noticed is that the AC brightness is /always/ used since about 2 days ago
[01:13] <sladen> thully: rather than even switching to the battery at all
[01:14] <thully> I'm not seeing that here - though it may be awaiting me in the next dist-upgrade...
[01:14] <mjg59> sladen: No, the change now is that the firmware won't change the brightness
[01:14] <mjg59> g-p-m will
[01:14] <sladen> mjg59: some logic is broken then.  the AC slider adjusts the brightness, even on battery
[01:15] <mjg59> sladen: That sounds like gpm is missing the transition, then
[01:15] <sladen> mjg59: however, the gpm applet shows the correct state
[01:16] <mjg59> immediately, or after some period of time?
[01:17] <thully> well, the issues I noticed with g-p-m are bugs 137598 and 63543 (reopened as a regression from feisty)
[01:17] <ubotu> Launchpad bug 137598 in gnome-power-manager "Screen brightness resets to default (maximum) on idle with AC plugged in" [Medium,New]  https://launchpad.net/bugs/137598
[01:17] <ubotu> Launchpad bug 63543 in gnome-power-manager "Error in automatic diminuition of brightness when idle" [Undecided,Confirmed]  https://launchpad.net/bugs/63543
[01:17] <sladen> mjg59: seems to be a lag;  so it's waiting until the next proactive battery-status event comes in
[01:17] <sladen> that 64xxx bug is too old to be this recent change
[01:18] <mjg59> sladen: If the AC slider is changing brightness on battery, that's a failure of function rather than of logic
[01:18] <mjg59> Could well also be a hal issue
[01:19] <thully> I figure that it sounds like a hardware-specific issue - I don't see that here (though the dimming is messed up in many other ways...)
[01:20] <sladen> acpi is seeing 'ac_adapter' events;  hal isn't reporting them
[01:21] <mjg59> Is hal-addon-acpi running?
[01:23] <sladen> nope, if there an FDI file somewhere that dictates whether that should be run?
[01:23] <sladen> is there
[01:24] <mjg59> No, it should be started at startup
[01:24] <mjg59> hal startup, that is
[01:25] <sladen> ah ha.  ist does get started, but the first acpi event kills hal-addon-acpi
[01:26] <Keybuk> SIGCHLD as IPC :)
[01:26] <mjg59> sladen: Sweet.
[01:26] <mjg59> sladen: You win the prize!
[01:26] <mjg59> The prize is debugging hal
[01:28] <Keybuk> yikes, what's the prize for the loser?!
[01:28] <sladen> asynchronous over abstracted soup
[01:29] <mjg59> Keybuk: Fixing hal and g-p-m
[01:29] <sladen> wonder how trackerd is monitoring the AC status;  surprisingly it's actually the only thing that /is/ responding to the power status
[01:29] <mjg59> sladen: Polling /proc/acpi/ac_adapter/*/status
[01:30] <Keybuk> *blink* it doesn't use D-BUS?
[01:30] <Keybuk> isn't that the eleventh commandment now?
[01:30] <mjg59> It does in svn
[01:31] <Keybuk> :)
[01:31] <thully> speaking of g-p-m and HAL, I have another issue unrelated to the brightness saga - on resume in 2.20, I keep getting "suspend failed" and "Action forbidden" messages.
[01:31] <thully> I tried the debug options, but I still don't see what is causing these messages to appear
[01:31] <thully> The system suspends fine, so obviously something is being oversensitive
[01:33] <sladen> thully: welcome to asynconous event soup;  if even one thing times out (eg. pulling back swap containing the end point in question) then the suspend will appear to "have failed", even if it worked just fine
[01:34] <thully> The bug report would 137738
[01:34] <thully> bug 137738
[01:34] <ubotu> Launchpad bug 137738 in ubuntu "[gutsy]  suspend / hibernate works fine, but after resume, I get a "Failed to suspend" popup" [Undecided,New]  https://launchpad.net/bugs/137738
[01:34] <sladen> and a million others
[01:35] <thully> is there a way to figure out what the event is that is causing this?  g-p-m debug output wasn't that helpful to me...
[01:36] <mjg59> Yes. Read the source and determine every way you can reach that point.
[01:36] <Amaranth> race condition?
[01:38] <thully> mjg59 - :)
[01:41] <thully> Well, this didn't happen in feisty, once again...  Kind of frustrating that every time I attempt to use Linux as my main OS, I am frustrated to heck with random power management issues and feel like bashing my head into the wall...
[01:43] <sladen> thully: regressions;  spawn of the evil doers
[01:44] <Keybuk> thully: power management is hard
[01:44] <Keybuk> and made harder by the hardware manufacturers
[01:46] <sladen> however, we WILL win.  one day
[01:46] <thully> Feisty had its own issues, though... In any case, I'm about to stick to keeping Ubuntu in a VM, get a *desktop* for Linux in the future, and avoid g-p-m hell forever
[01:46] <thully> I guess I feel like that would be cheating, though :)
[01:48] <thully> I actually went to OS X from Ubuntu 3 years ago because suspend issues were driving me nuts...  Now, I'm somewhat bored with OSX (I want to actually look at the code :)) and loading Ubuntu on my MacBook
[01:49] <thully> The issue that was most annoying 3 years ago was ATI radeons commonly used in Thinkpads eating battery like crazy in suspend...
[01:49] <thully> I think mjg59 was working on that way back in the day...
[01:51] <Keybuk> you know you've been in this business too long when you start getting sentimental about bugs
[01:52] <lamont> Keybuk: heh
[01:53] <Keybuk> "I remember the day when Lamont wrote his name in the Release Critical bug list"
[01:53] <thully> I will say that it has remarkably improved since then, though binary drivers are still a PITA (darned Atheros driver seems to be crashing NetworkManager all the time!) and g-p-m is a royal pain
[01:54] <thully> I tried ath5k for fun (though it seems to be know more for license wars than anything), but it doesn't like my card...
[02:00] <thully> I guess I'll log off for now - thanks for all the feedback about these bugs!  I may just end up cheating in my situation (by putting Ubuntu in VMware), but I'm happy some work is being done here.
[02:07] <zul> heh kernel breakages in breezy was fun
[02:09] <donspaulding> I'm having trouble googling for docs on how to use python-apt, anyone in here have any decent resources on the topic?
[02:10] <lamont> Keybuk: dude.  it was just my initial.
[02:11] <Keybuk> donspaulding: it's a python module, of course there aren't docs
[02:13] <donspaulding> Keybuk: heh, so if I'm looking to develop a server-only, in-house, "automatix-ish" package manager python-apt isn't the way to go?
[02:15] <Keybuk> it probably is
[02:15] <Keybuk> it's just like any python module that binds something else
[02:15] <Keybuk> non-existant docs
[02:15] <Keybuk> look up the docs for the ordinary apt lib, compare with dir()/help()
[02:15] <donspaulding> oh, good, then I'm just up a creek (albeit, the right creek)
[02:16] <donspaulding> will do
[02:16] <Keybuk> also look at things like synaptic, update-manager, etc.
[02:16] <Keybuk> any bits that are similar to what you want
[02:16] <Fujitsu> Or look at Automatix
[02:17] <zul>  /kick Fujitsu
[02:17] <donspaulding> Automatix is really the functionality I'm looking for, but I want it server-side and I want to extend it to include some new ways of installing things
[02:18] <donspaulding> s/server-side/no X
[02:23] <sladen> 0Automatix is *never* what you're looking for
[02:25] <kylem> sladen, what if you're looking for the wrong answer?
[02:27] <zul> donspaulding: when I was doing that at work I crated a metapackage much more easier
[02:27] <StevenK> Yup. Because killing dpkg won't create any problems.
[02:27] <Fujitsu> RAOF: But, but, but it sometimes doesn't quit itself, remember!
[02:29] <RAOF> What could possibly go wrong :/
[02:32] <donspaulding> you guys are ruthless
[02:34] <donspaulding> zul: hmm, I'll have to look at the metapackage thing, I assume deb's can run arbitrary commands in them?  Like I could create my own repo with metapackages that are dependent on ubuntu packages, then run commands to configure them after install?
[02:35] <Keybuk> yes
[02:35] <donspaulding> Or would I have to create my own full debs?
[02:35] <donspaulding> interesting... off to google again
[02:35] <Keybuk> heh, just keybuk-meta
[02:35] <Keybuk> http://www.netsplit.com/bzr/keybuk-meta/
[02:36] <Keybuk> cf. the postinst for one of them
[02:36] <StevenK> Way cool, now I can make fun of what you install by default. :-P
[02:36] <Keybuk> :)
[02:37] <StevenK> Keybuk: *Why* is figlet in keybuk-base? :-)
[02:37] <Keybuk> because it's mandatory
[02:38] <donspaulding> holy crap, what a great idea!
[02:40] <Keybuk> donspaulding: it makes installing computers easy
[02:40] <Keybuk> dpkg --unpack *.deb
[02:40] <Keybuk> apt-get install -f
[02:41] <lifeless> whateverhappened to debtakeover?
[02:41] <StevenK> There's something I not heard of for a while.
[02:41] <StevenK> I've, even
[02:42] <Keybuk> StevenK: just figlet? nothing else to make fun of? :p
[02:42] <StevenK> Keybuk: Sadly, yes.
[02:42] <Keybuk> yes there is, no there isn't?
[02:43] <StevenK> Heh, sorry. There's nothing else in there that looks crazy enough to make fun of.
[02:43] <Keybuk> lol
[02:43] <StevenK> Actually, yes there is.
[02:44] <StevenK> Hah, autobork by default on desktop development systems!
[02:44] <Keybuk> ?
[02:44] <ajmitch> sure, why not?
[02:45] <StevenK> Actually, it seems to be almost every version of auto* we ship.
[02:45] <ajmitch> some upstreams are a bit behind the times
[02:45] <Keybuk> always reautoconf with the version upstream used
[02:46] <StevenK> Except if you're CDBS. Twitch.
[02:48] <CarlFK> as long as ya'll talking bout auto and install, is "d-i     partman-auto/disk       string /dev/discs/disc0/disc"  doesn't seem to work for gutsy preseed.  anyone know what it changed to?
[02:49] <Keybuk> CarlFK: well, the disc spec isn't valid
[02:49] <Keybuk> but that might be ok, d-i is verrrry strange
[02:49] <CarlFK> the installer stops and asks me to pick a disk
[02:50] <CarlFK> I think I saw that  partman-auto/disk changed, but can't remember where I saw it.  something like partman-auto/disk-select
[02:50] <Keybuk> the person you need is in bed
[02:51] <CarlFK> yup.
[02:54] <ion_> keybuk: Ooh, what a great idea.
[02:56] <Keybuk> ion_: I can't claim credit for it
[02:56] <Keybuk> though I also can't remember who I copied it off
[02:56] <Keybuk> mdz I think
[02:57] <lamont> slangasek: if you could be so kind as to put bug 148804 to bed tonight, that'd be wonderful
[02:57] <ubotu> Launchpad bug 148804 in mlton "Please sync mlton (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/148804
[03:00] <lamont> slangasek: (or whoever) is icedtea-java7 going to be accepted?
[03:00] <lamont> if it is, please be so kind as to toss it in universe for the moment, for my bootstrapping happiness
[03:01] <lamont> if it's supposed to go in main, I'd vote to move it there after it's bootstrapped.
[03:01] <lamont> likewise, if it's not going in gutsy, that's fine with me too.
[03:01] <StevenK> lamont: I'm quite curious how you actually bootstrap something like that depends on itself
[03:01] <lamont> StevenK: with a sledge hammer
[03:02] <lamont> you'll notice that there's another repository besides ftpmaster.internal mentioned in the mlton build logs
[03:02] <StevenK> For the code, or upstream? :-P
[03:02] <lamont> sadly, for the code.
[03:02] <RAOF> What was the actual fix for "LVM-on-crypt doesn't boot" again?
[03:02] <Fujitsu> RAOF: Hit cryptsetup's initramfs hook hard with the sledgehammer lamont currently has, until it works with UUIDs.
[03:03] <lamont> it's understandable why they build-dep themselves with compilers... if you're crazy enough to write a new language, you probably are lost enough in love with it to want to _write_ the compiler in that language
[03:03] <RAOF> Fujitsu: The bug suggests that it *should* work with uuids, now.
[03:03] <Fujitsu> RAOF: It does, yes.
[03:03] <StevenK> lamont: Heh
[03:03] <Fujitsu> Mine boots as of yesterday's crypsetup upload.
[03:03] <Fujitsu> *cryptsetup
[03:04] <lamont> StevenK: the archive on sanae has a version of the binaries built by "lamont the human autobuilder" according to a set of pedantic lets-make-this-work-right rules
[03:04] <RAOF> Fujitsu: Mine still doesn't, and I'm recalling a conversation along the lines of "we won't fix it for people who've already done it, they should know how anyway"
[03:04] <StevenK> lamont: My question was more along the lines of how do you make the package build at all if the Build-Depends can't be satisified.
[03:05] <lamont> StevenK: that's like right now, hppa is building gutsy using gutsy-stage0 to satisfy build-depends, etc.
[03:05] <lamont> oh. the actual real original bootstrapping...
[03:05] <StevenK> Yes.
[03:05] <lamont> generally, you cross-compile
[03:05] <StevenK> Ew.
[03:05] <Amaranth> vala has this problem too
[03:06] <Amaranth> it's annoying
[03:06] <lamont> so you abuse the source to build you an i386 binary that produces powerpc output.  Then you use that to build the original debs
[03:06] <StevenK> But you only use the cross-compiled code to truly ruly build the version for the archive.
[03:06] <Amaranth> if you use the released version it comes pretranslated to C but if you follow svn you have to hop  along to certain key commits so you have a compiler that can compile itself
[03:06] <lamont> then you install those and build the source natively on ppc
[03:06] <StevenK> lamont: Yup
[03:06] <Fujitsu> RAOF: If you've been booting manually, make sure the name of the currently opened crypto device and that in crypttab  match, then rerun update-initramfs -u.
[03:07] <lamont> likewise, if you're lucky, then there's something sane to build from
[03:07] <lamont> for example, flex includes 'lex.l' in its source... and yes, that's a flex file.
[03:07] <StevenK> Yay!
[03:07] <lamont> it also includes lex.c though, so you don't need to build-depend flex
[03:08] <StevenK> I always found it amusing for packaging systems - like rpm.rpm or dpkg.deb
[03:08] <lamont> heh
[03:08] <RAOF> Fujitsu: So, the currently opened crypto device will be... /dev/mapper/sda5-crypt, yes?  And the crypttab line should be "sda5-crypt /dev/sda5 none luks"?
[03:09] <StevenK> Hrm. Must ask Keybuk what his quit message is.
[03:09] <Amaranth> I had the answer once...
[03:10] <Amaranth> babelfish says something about absurdity
[03:10] <Fujitsu> RAOF: Something like that, yeah (sorry about the lag time, a new lyx upstream tarball ate my upstream)
[03:11] <StevenK> Why do I have this feeling it's "This is laughter for chickens" or something like that, from Serenity
[03:11] <Amaranth> firefly?
[03:11] <StevenK> Serenity is the movie following on from Firefly
[03:11] <Amaranth> I know :P
[03:11] <StevenK> I couldn't stand the series, my wife loved it.
[03:12] <RAOF> Yay firefly.
[03:12] <lamont> StevenK: how unfortunate.
[03:12] <RAOF> StevenK: Really?  Strange person! :P
[03:12] <lamont> "this food is problematic"
[03:12] <StevenK> RAOF: It just didn't ... click. I was dragged along to see Serenity twice, though.
[03:13] <lamont> saw Serenity, tracked down the DVD set
[03:13] <lamont> "Take me sir.  Take me hard."
[03:13] <StevenK> I don't remember that bit
[03:14] <ajmitch> ah, "River Tam kills everyone"
[03:14] <lamont> end of the episode where Mal and Wash are "guests" of the episodes villan
[03:14] <StevenK> RAOF: Admitedly, the second time was because Joss Whedon was fielding questions after the movie.
[03:14] <lamont> StevenK: it's in the series, not the move
[03:14] <lamont> movie, even
[03:14] <StevenK> lamont: Ahhh
[03:15] <StevenK> RAOF: So, if you have the .au DVD release, my wife and I are in the Q&A session on the bonus disc
[03:15] <lamont> "go back to the part where Jayne gets his butt kicked by a 90 pound girl.  Because I don't see that getting old"
[03:15] <lamont> StevenK: there - that's from the move
[03:15] <lamont> movie. sigh
[03:15] <RAOF> StevenK: Wicked.
[03:15] <lamont> StevenK: rock
[03:15] <StevenK> lamont: Now that bit I remember.
[03:16] <lamont> hrm... s/don't/just don't/
[03:16] <StevenK> RAOF: Oh, and the Firefly box set we have is now autografed by Joss
[03:16] <StevenK> And I can't spell, sigh
[03:17] <zul> lamont: wha?
[03:18] <StevenK> lamont: Remind me what Extreme Makeover is? It's ringing a vague bell.
[03:19] <zul> StevenK: its where people with like 15 foster kids get their home torn down and get rebuilt everybody happy blah blah
[03:21] <lamont> http://abc.go.com/primetime/xtremehome/index
[03:22] <lamont> zul: sounds about right
[03:22] <lamont> mitzi gets to be on-air talent with Rib and Paige - I'd expect it's < 5 minutes of actual airtime.
[03:22] <lamont> after all, we only spent 3 hours filming it
[03:23] <StevenK> Hah
[03:25] <CarlFK> in the next batman movie, look for me playing a hospital patient with oriele's CSS  book. that took 16 hours, and I'll be happy if I get 3 min
[03:25] <CarlFK> extra happy if CSS shows up at all
[03:25] <lamont> yeah - my teenager found it very disillusioning when we went up for the reveal
[03:26] <StevenK> CarlFK: Heh
[03:29] <slangasek> lamont: I'm not really in the loop on icedtea
[03:30] <lamont> yeah - I poked doko about it
[03:30] <lamont> he sent me email with the info I need for bootstrapping it... can't really bootstrap it until the source is actually _IN_ the archive though
[03:32] <StevenK> lamont: It isn't in NEW?
[03:32] <lamont> yeah
[03:32] <StevenK> lamont: You can grab it manually from the NEW queue using LP
[03:33] <lamont> right... now have launchpad build it
[03:33] <lamont> that part requires that it be in the archive, not NEW
[03:33] <StevenK> Ah
[03:34] <lamont> it also requires a canonical sysadmin, which means that it'll be tomorrow morning -0600 before I even think about playing with it, by which time someone will have done something with it in NEW, I expect
[03:35] <ScottK> StevenK: Just upload whatever it and when someone complains say, "Oh, sorry,  Thought that was in Universe."
[03:35] <lamont> it would just save me considerable pain if it happened to take a trip through universe on its way to its final destination
[03:35] <slangasek> StevenK: I'm not going to be sweet-talked into accepting something on the basis that someone else somewhere may have made a decision to accept it. :)
[03:35] <StevenK> slangasek: Awwww. :-)
[03:35] <lamont> StevenK: you have to get him _really_ drunk first
[03:36] <StevenK> That's one way to make Debian release on time.
[03:36] <slangasek> which is hard, because I'm a cautious drinker
[03:36] <lamont> drunken archive admins make it release slower...
[03:36] <lamont> slangasek: that does make it more challenging, true.
[03:36] <kylem> will accept things for single malt.
[03:37] <slangasek> lamont: 20-byte .diff.gz files make me cross
[03:37] <lamont> then again, there is always Mao
[03:37] <lamont> slangasek: you're kidding...
[03:37] <slangasek> -rw-r--r-- 1 lp_archive lp_archive      20 Oct  4 02:32 mlton_20070826-1.diff.gz
[03:37] <StevenK> Way cool
[03:37] <slangasek> it's like that in the current version too, so
[03:37] <StevenK> Isn't that just a gzip header?
[03:37] <slangasek> yes
[03:38] <lamont> so it's packaged to allow the debian mainainer to modify things down the road without uploading an entire tar.gz
[03:38] <lamont> most likely, the debian/ directory is in upstream
[03:38] <StevenK> It's ... native without being native ... Ouch
[03:38] <lamont> depending on the size of orig.tar.gz, that can be a wonderful thing
[03:39] <slangasek> yes, the non-wonderful is having debian/ in the orig.tar.gz :)
[03:39] <StevenK> Heh
[03:39] <StevenK> How big is this orig tarball?
[03:39] <lamont> well, if that's how upstream releases .tar.gz......
[03:39] <StevenK> I'm curious if the maintainer is a big wuss
[03:39] <slangasek> 5.3MB <shrug>
[03:39] <lamont> small
[03:39] <lamont> 5MB
[03:40] <lamont> it's not X
[03:40] <StevenK> Argh, take it like a man! I've uploaded three rc's of gimp, with orig and the tarball is bloody 26Mb
[03:40] <wasabi> i dont suppose at some point in the future somebody is going to store uid numbers in /etc/group.
[03:41] <wasabi> sillyness
[03:41] <slangasek> lamont: mlton synced, now what's the convention for documenting this in the bug seeing how that's not in the howto? :P
[03:42] <lamont> close the bug with a comment saying that you synced it, I guess
[03:42] <StevenK> slangasek: You can either reply with 'Synced' and close it.
[03:42] <StevenK> slangasek: Or, paste part of the output of sync-source.py and close it
[03:42] <StevenK> slangasek: I can dig up an example fairly easily
[03:42] <lamont> woot.  rmadison shows bind9_1:9.4.1-P1-2
[03:43] <lamont> wink. wink.  nudge. nudge.
[03:44] <StevenK> I wonder if that's code for "Sync it or I won't love you any more."
[03:44] <slangasek> StevenK: well, I've just pasted some output from sync-source.py, good enough :)
[03:44] <lamont> StevenK: you should watch more monty python
[03:44] <slangasek> photographs, eh, he asks him knowingly
[03:45] <lamont> slangasek: there are no photographs.
[03:45] <StevenK> lamont: Probably. I've only seen Holy Grail
[03:45] <StevenK> "He's not the Lord, he's a very naughty boy!"
[03:45] <lamont> OTOH, if slangasek's wife recognized the skit, she'd be likely to beat me to a pulp.
[03:45] <slangasek> erm
[03:46] <lamont> so lets go with that being code for "please sync.  kthxbye.  love you anyway."
[03:55] <lamont> slangasek:
[03:55] <lamont> thansk
[03:56] <StevenK> libtinymail. You. Are. Going. To. Build. Correctly.
[03:56] <lamont> StevenK: tiny problem?? :-)
[03:58] <StevenK> lamont: Yes. It's called -fPIC and automake
[04:01] <lamont> oh. that thing
[04:03] <lamont> what are you doing that requires ports?
[04:03] <StevenK> Sync'ing lpia
[04:03] <lamont> ah
[04:03] <ajmitch> solved by moving out of .au?
[04:04] <StevenK> I can only find one .au mirror that carries lpia, and it's *hopelessly* out of date. :-/
[04:04] <lamont> many things can be solved that way
[04:04] <StevenK> ajmitch: Like .nz is any better
[04:04] <ajmitch> we have advanced stuff like local loop unbundling that'll finally happen :)
[04:08] <StevenK> ajmitch: I'm not certain if we have that yet.
[04:08] <StevenK> I'm looking at ADSL2+, I just can't afford the initial outlay
[04:08] <ajmitch> ADSL2+ is still a planned feature for us
[04:09] <RAOF> StevenK: What initial outlay?  Doesn't someone want to sign you up for a 18 month contract for free?
[04:09] <StevenK> RAOF: I'm with Exetel, and I want to stay with them.
[04:10] <StevenK> RAOF: Moving from ADSL1 to ADSL2+ requires having to move the ADSL terminating on Telstra's equipment, and moving it to Powertel's
[04:10] <ajmitch> you're currently limited to 1.5Mbps?
[04:10] <RAOF> StevenK: Right.  Gah, stupid Telstra.
[04:10] <StevenK> I could switch to 6Mb down, I just haven't
[04:11] <ajmitch> which is useful when I sync from a fast NZ mirror
[04:11] <RAOF> StevenK: What!  Telstra will allow you to use more than 1.5 Mbps down?
[04:11] <ajmitch> nz2.a.u.c updates every 4 hours, which is quite good
[04:11] <Fujitsu> RAOF: We have 8Mbps on ADLS1 at work.
[04:11] <Fujitsu> pacific's mirror seems to update very regularly now.
[04:12] <StevenK> Funny. I left there last week, you'd think they'd fix it
[04:12] <RAOF> Fujitsu: That must have changed since I was on a Telstra rimm.  They used to only allow 1.5 down.
[04:12] <Fujitsu> RAOF: That changed recently, IIRC.
[04:12] <StevenK> RAOF: Right, it changed very quietly recently
[04:13] <RAOF> Yay Telstra being not quite so totally stupid!
[04:13] <StevenK> Maximum speeds: Up to 8192kbps Down/384 kbps Up **
[04:13] <Fujitsu> RAOF: Not possible!
[04:13] <StevenK> To be honest, 384 kbps up isn't enough
[04:14] <Fujitsu> I have 256kbps, and dputting anything significant kills the rest of my connections... I must work out how to throttle it.
[04:14] <StevenK> Fujitsu: Your firewall is Linux?
[04:15] <Fujitsu> StevenK: It is.
[04:15] <StevenK> Fujitsu: /sbin/tc qdisc replace dev ppp0 root tbf rate 22kbps latency 50ms burst
[04:15] <StevenK> 1540
[04:15] <StevenK> Sorry, that should be one line
[04:16] <StevenK> Fujitsu: tc *sucks* *HARD* to use, but once it works, it's great
[04:16] <StevenK> -rw-r--r-- 1 steven users 2.1M 2007-10-04 12:18 libtinymail_0.0.2-0ubuntu1_amd64.deb
[04:16] <StevenK> HAH!
[04:16] <StevenK> Take *that* automake
[04:17] <Fujitsu> StevenK: I'll try that, thanks!
[04:17] <StevenK> RAOF: If you can figure how to remove a pfifo_fast, I'll love you long time
[04:17] <ajmitch> RAOF: I'm surprised that you're bothering with its manpage
[04:17] <StevenK> Indeed.
[04:18] <StevenK> tc's documentation is poor at best, the source code at worst
[04:18] <donspaulding> so to make my metapackage depend on apache2, what would I put on the Depends line of debian/control ?  Is there an apache virtual package?
[04:18] <RAOF> ajmitch: Well, it tells me roughtly what it does, at least :)
[04:20] <StevenK> donspaulding: Depends: apache2
[04:21] <lamont> donspaulding: there is an apache2 metapackage that should fit the bill
[04:22] <lamont> it, in turn, Depends: apache2-mpm-worker (>= 2.2.3-3.2build1) | apache2-mpm-prefork (>= 2.2.3-3.2build1) | apache2-mpm-event (>= 2.2.3-3.2build1)
[04:22] <lamont> or so
[04:22] <StevenK> ajmitch: Indeed, Exetel charge for moving from ADSL1 to ADSL2+. $88 AUD, which is about half of what I saw last time I checked
[04:22] <donspaulding> StevenK: I'm also looking for a more general answer, so I'm not constantly asking "what should my Depends line look like?"   I see that the Source package depends on debhelper (>=5).  So does that translate to apache (>=2)?
[04:22] <donspaulding> or anyone really
[04:23] <StevenK> donspaulding: Nope, the package for Apache 2 is apache2. In the general case, find the packages you want to install and list them all on the Depends line.
[04:24] <donspaulding> excellent, thanks
[04:25] <StevenK> Hrm. I shall keep that in mind. It looks to be $143 to switch, as opposed to the $300-odd I saw when I looked last time
[04:25] <donspaulding> what does ${shlibs:Depends}  do??
[04:26] <lamont> donspaulding: the >=5 is specifying that versions of debhelper before version 5 are insufficient to the package's needs
[04:26] <lamont> man dh_shlibdeps
[04:26] <lamont> for ${shlibs:Depends}
[04:26] <StevenK> donspaulding: For a metapackage, you don't need it.
[04:26] <lamont> actually, reading through the debhelper docs should be a good starting point
[04:27] <donspaulding> lamont: ok
[04:27] <LaserJock> I wonder if it'd be worth it to pull the debhelper man pages, etc. into an HTML page for people to read
[04:27] <StevenK> LaserJock: man2html does exist, and has for a while
[04:28] <LaserJock> StevenK: yes, I'm wondering if it'd be worth using it and sticking it somewhere
[04:29] <StevenK> http://xgen.iit.edu/cgi-bin/man/man2html?7+debhelper
[04:29] <StevenK> Third hit on Google
[04:29] <LaserJock> oh, that is good
[04:30] <LaserJock> I didn't think it'd have links to all the dh_*
[04:55] <fedaraoti> what does ubuntu use to redhats src.rpm
[04:55] <fedaraoti> src.deb?
[04:55] <donspaulding> dh_make created a few extra files for me, I removed the .ex and READMEs, can I do the same with compat, copyright, dirs, docs, and files?
[04:56] <RAOF> fedaraoti: .dsc, .orig.tar.gz, and .diff.gz
[04:56] <donspaulding> sorry, I also meant to mention this was for a metapackage
[04:57] <fedaraoti> RAOF: will any of them register as a installed package with the other installed debs?
[04:57] <RAOF> fedaraoti: No, because they're not packages.
[04:58] <fedaraoti> ok
[04:58] <fen_> can anyone tell my why when i change ~/.gconf/desktop/background/%gconf.xml and logout/back in it does utterly nothing?
[04:58] <fedaraoti> is there any way like with apt
[04:58] <RAOF> We don't have "package containing the source of the package you can build from this source" package :)
[04:58] <RAOF> fedaraoti: apt-get source packagename :)
[04:59] <fedaraoti> like rpm -i bla.src.rpm then rpmbuild --rebuild bla.src.rpm
[05:00] <fedaraoti> will list it with the other installed rpm
[05:00] <fedaraoti> rpm's
[05:00] <fedaraoti> RAOF: cool
[05:00] <RAOF> fedaraoti: "apt-get source -b packagename" will get the source & build it.
[05:00] <ajmitch> note that apt-get source will download & unpack into your current working directory
[05:01] <fedaraoti> RAOF:  and could that be a .dsc, .orig.tar.gz, or .diff.gz
[05:01] <fedaraoti> ?
[05:01] <fedaraoti> see
[05:02] <fedaraoti> my main queston was do the nvidia module come in a source package
[05:02] <fedaraoti> and would they compile against the kernel?
[05:02] <fedaraoti> say
[05:03] <fedaraoti> apt-get source -b nvidia
[05:06] <dobey> fen_: because the file gets overwritten by what's in memory from the daemon?
[05:06] <dobey> because you aren't supposed to edit those files by hand
[05:11] <holycow> oh i was wondering what its quiet in here
[05:11] <holycow> i'm in -devel
[05:11] <holycow> hehe :)
[05:29] <mekius> Ok, custom gutsy live cd, custom sources.list in /etc/apt/, for the past two months it has been copied verbatim during install, no issues, but just updated today and now it is not copied, but seems to be replaced by a default sources.list
[05:29] <mekius> is this expected behavior?
[05:29] <mekius> and if so, what's the best way to override this?
[05:32] <donspaulding> the debian new maintainers guide mentions the debian/conffiles file that can specify files not to overwrite if the user chooses not to, is that what files is for now?  dh_make didn't create conffiles
[05:35] <dobey> donspaulding: i don't think dh_make is supposed to generate it. i think it's a list of files that you specify by creating the file
[06:12] <RAOF> Fujitsu: Thanks, that crypttab mangling did the trick.
[06:16] <donspaulding> dobey: thanks, I've realized I don't need it.
[07:05] <sladen> mjg59: what the heck did you do to override the hardware brightness control on thinkpads.  It is actually /really/ annoying;  backlight doesn't work on the console etc
[07:06] <sladen> mjg59: it's perhaps a good idea, but I think g-p-m needs to selectively take control (such as when it's actually thj
[07:06] <sladen> mjg59: the holder of the console)
[07:07] <sladen> mjg59: (...and/or when it's actually *running* :)
[07:30] <fabbione> morning
[07:31] <Fujitsu> Hi fabbione.
[07:37] <Whoopie> zul: morning, regarding bug 146987, tpb is started with /etc/X11/Xsession.d/90tpb. Don't know if it's now started twice.
[07:37] <ubotu> Launchpad bug 146987 in tpb "tpb init script doesn't launch tpb" [Undecided,Fix released]  https://launchpad.net/bugs/146987
[07:53] <dholbach> good morning
[07:59] <sladen> Whoopie: tpb isn't really compatible with the provided ubuntu hotkey infrastructure
[08:01] <desrt> you mean ubuntu will give me my hot serial keys directly instead of getting them from ThePirateBay?
[08:01] <desrt> score.
[08:09] <StevenK> Morning pitti
[08:09] <pitti> Good morning
[08:09] <pitti> hey StevenK
[08:24] <slangasek> dholbach: hrrm, sorry about the maintainer field, I didn't even look as it was an ubuntu2 build
[08:25] <dholbach> slangasek: don't worry - that's a mistake that's too easy to make
[09:04] <mdke> dholbach, pitti: ping
[09:05] <pitti> hi mdke
[09:07] <mdke> hiya, morning
[09:07] <stgraber> morning
[09:07] <mdke> pitti: you remember that last cycle you added some stuff to ubuntu-docs to filter out translations less than a certain percentage of completion?
[09:08] <mdke> pitti: i uploaded some translations to the repository yesterday, and tried a build, but I guess a massive barrage of error messages which I don't understand, I wondered if you or Daniel would be able to take a look
[09:08] <mdke> I think they may be due to the stuff that was added for filtering
[09:08] <mdke> s/guess/get
[09:10] <dholbach> mdke: I can take a look after the dogwalk, if pitti hasn't tended to it yet
[09:13] <mdke> dholbach: thanks a lot. the errors look like this - http://paste.ubuntu-nl.org/39514/ - over and over again
[09:13] <dholbach> ugh
[09:14] <dholbach> no idea what that might be :-/
[09:14] <mdke> heh
[09:14] <mdke> it's not stopping the build but it looks bad
[09:15] <dholbach> you might want to bump the version to 7.10.1 and fix the tab problem in the changelog entry
[09:15] <mdke> oh yeah, I have done that in my working copy
[09:16] <mdke> I'm not planning an upload yet, i just wanted to sort this out for now
[09:17] <pitti> dholbach: thanks; please let me know when you start, and if you have questions
[09:17] <dholbach> pitti: it seems some doc-related thing; at least I haven't seen anything like it before
[09:19] <mdke> given the quantity of the errors and the fact we haven't had it before, i think it must be related to the translations (i.e. to the msgfmt and related commands in debian/rules)
[09:19] <\sh> moins
[09:20] <pitti> doko: re your restricted-manager upload> what's the purpose of this? if "import gtk" does not work after a dist-upgrade, pre-depends vs. depends: will not change anything
[09:22] <doko> pitti: define "after dist-upgrade", I have never seen this. the purpose was to have it available as soon as possible
[09:23] <pitti> doko: right, but a lot of my bugs happened after a dist-upgrade, not in between
[09:24] <\sh> I|m having problems with the gnome.settings-daemon as it looks like :*
[09:24] <doko> pitti: after restarting restricted-manager, or with the running process?
[09:25] <pitti> doko: there is usually no running process
[09:25] <dholbach> pitti: I'm afraid, I don't understand what happens there
[09:25] <pitti> I never got really great feedback about those crashes either, so I'm unsure about the exact circumstances
[09:29] <doko> pitti: well, then please revert it then with the next upload. we could try tro reenable this in early hardy
[09:30] <pitti> doko: I don't have a good idea how to handle that either; I know that mangling all the symlinks just in the postinst is tricky
[09:30] <pitti> doko: unless, instead of removing the symlinks, the preinst would just write out a list of them on 'upgrade', and the postinst does the symlink setup in one atomic step?
[09:31] <pitti> doko: it's certainly possible that all of these crashes happened due to incomplete upgrades
[09:31] <pitti> i. e. one package failed to configure, and thus a lot of other packages weren't configured
[09:34] <donspaulding> I listed several packages in my control file Depends: line, debuild'ed my package, then tried to debi it, but it says it depends on <one of my depends packages>, but it isn't going to be installed
[09:34] <donspaulding> What am I missing?  I thought that was what the point of Depends was?
[09:38] <mrgenixus> hi y'all -- trying to install ubuntu onto second disk from within linux distro... is there a way to get a copy of either the text or graphical installer, standalone so that I can install from within linux?
[09:38] <mrgenixus> (e.g. I don't want to burn a cd -- I just want to install ubuntu on an external drive)
[09:39] <doko> pitti: well, that complicates things more, and doesn't seem to be sufficient for newly added files in the update, keeping the .pyc files during an updated could help, but that would require knowledge about the old .pyc file after the new package is installed
[09:40] <donspaulding> mrgenixus: http://www.google.com/search?hl=en&q=install+ubuntu+without+cd&btnG=Search
[09:41] <pitti> doko: but we don't need to keep the .pyc files, right? only the symlinks
[09:41] <pitti> doko: without the .pyc, startup will be slower, but *shrug*
[09:42] <pitti> doko: maybe python packages should be changed to have a common PYTHONPATH for version independent modules, instead of having symlinks to the version specific dirs? could that work?
[09:43] <pitti> doko: i. e. we could add /usr/share/python-support/ to PYTHONPATH and find a solution for the per-package subdirectories
[09:43] <mrgenixus> donspaulding: all of those results and most modifications of the search give me what I want, except I'm not running windows
[09:43] <mrgenixus> I tried the google search first
[09:44] <mrgenixus> your terms were different, so I tried that one -- but I get the same results I already didn't want/need
[09:44] <mdke> pitti: can I leave it with you then? If you want I can file a bug report. The latest source is "svn export https://docteam.ubuntu.com/repos/branches/gutsy". It might be worth checking that nothing important has changed from what you did to the feisty package
[09:44] <doko> pitti: keeping the .pyc files has the advantage that things will work without the .py files. keeping the symlinks requires knowledge of both the old and new files after upgrade, which we currently do not have (and files may move between different packages too)
[09:45] <doko> messing around with PYTHONPATH is not a solution, you'll change the order of imports
[09:45] <donspaulding> well, there goes my claim to most-helpful-irc-acquaitance-of-the-night
[09:45] <donspaulding> :-)
[09:45] <pitti> doko: hm, ok
[09:46] <pitti> mdke: dholbach and I will figure it out
[09:46] <mdke> pitti: thanks very much indeed
[09:46] <mrgenixus> donspaulding: I was hping someone in here had done it
[09:46] <mdke> pitti / dholbach: i'll be on email today if I can help at all
[09:47] <doko> pitti: will apport be turned off in final gutsy?  for other applications which might run during an upgrade, the pre-depends on needed python modules could make things more robust
[09:48] <pitti> doko: yes, we currently plan to turn it off for the final release
[09:48] <pitti> doko: and on again in the live system, just like in feisty
[09:49] <doko> pitti: ok, you don't upgrade that much in the live system =)
[09:50] <pitti> right
[09:50] <pitti> doko: on the live system it's still good to have apport, mainly for ubiquity
[09:51] <donspaulding> mrgenixus: I've done it in the past, but only to switch between other linux distros, never to dual-boot with ubuntu
[09:52] <donspaulding> the problem is that the livecd is just that, a livecd which you are meant to install from.  Essentially it's just a matter of getting grub to boot an installation kernel, which could probably be found on the alternate install CD
[10:08] <dholbach> pitti: thanks a lot
[10:23] <seb128> does anybody has a external usb disk using vfat? bug #133567 would be nice to debug for gutsy
[10:23] <ubotu> Launchpad bug 133567 in nautilus "[gutsy]  long delay in nautilus on first access to vfat drive" [Medium,New]  https://launchpad.net/bugs/133567
[10:25] <mdz> lamont: here now
[10:27] <Hobbsee> hi LaserJock
[10:27] <LaserJock> hola Hobbsee
[10:30] <Hobbsee> LaserJock: good replies on the bug thread, btw.
[10:31] <LaserJock> Hobbsee: maybe :-)
[10:32] <LaserJock> I dislike email because it takes me forever and I always feel like it's not quite complete
[10:32] <Hobbsee> LaserJock: still better than mine would be, in current form - but that's probably as i've actually been trying to use launchpad in places.
[10:32] <Whoopie> sladen: yes, I know. but zul changed the package and I just wanted to let him know that tpb is started with the /etc/X11/... script
[10:33] <Fujitsu> I don't particularly like the one-size-*will*-fit-all approach.
[10:34] <pitti> mdke: where is that source package?
[10:34] <LaserJock> Fujitsu: I don't think it's quite that though
[10:35] <LaserJock> if LP guys are designing in one direction and we're using it in another then obviously problems will happen
[10:35] <LaserJock> have a consistent standard vocabulary would at least help
[10:36] <LaserJock> let alone "this is how we think the best way to use LP is, based on the way we've written it"
[10:36] <Hobbsee> LaserJock: of course, the more we deviate statuses from other bug trackers, the more problems we get
[10:37] <LaserJock> well, I was thinking more internally, but yeah ;-)
[10:37] <Hobbsee> although i've got no idea if the LP guys are taking that into account
[10:37] <Hobbsee> (disclaimer:  was a random thought, rather than based on what you said)
[10:37] <LaserJock> I think they are as they have to figure out how to sync the statuses
[10:38] <LaserJock> so it's more work for them if they go and make a bunch of statuses that they then have to figure out how to map from external bug trackers
[10:39] <Hobbsee> true
[10:40] <LaserJock> I wonder what would happen if they had a different set of statuses for distributions and projects
[10:42] <Hobbsee> mass confusion, probably.
[10:45] <ogra> seb128, cant confirm that here
[10:45] <seb128> ogra: what?
[10:45] <ogra> seb128, bug 133567
[10:45] <ubotu> Launchpad bug 133567 in nautilus "[gutsy]  long delay in nautilus on first access to vfat drive" [Medium,New]  https://launchpad.net/bugs/133567
[10:45] <seb128> ogra: ah, the usb slowness?
[10:45] <seb128> ogra: ok, thanks for trying
[10:45] <ogra> works just fine, tested on two machines
[10:46] <ogra> one fresh and one upgraded ...
[10:47] <seb128> ogra: how big is your disk? and it's using vfat?
[10:48] <ogra> seb128, there are many USB keys out in the wild without proper partitioning, windows allows to format the device directly, we had many probs with that in ltsp, that might be related
[10:48] <ogra> its using vfat (stock 2G disk, bought two weeks ago and untouched until now)
[10:48] <seb128> ogra: ah, 2G is too small
[10:49] <ogra> oh, ok
[10:49] <seb128> ogra: read the recent comment, the guy says it's not noticable on a 2G drive
[10:50] <seb128> but really noticable on a 300 or 500Go disk
[10:50] <ogra> hmm
[10:53] <cjwatson> lamont: icedtea will go via universe, but needs a licence check first, which is on my list.
[10:54] <cjwatson> lamont: please do not attempt to persuade people to accept it before that!
[10:55] <pitti> seb128, ogra: oh, I get that bug, too
[10:55] <pitti> seb128: when I attach my 250 GB USB disk, nautilus hangs for a long time
[10:56] <seb128> pitti: ah? what kind of drive do you use? Do you think you could have a look to the issue?
[10:59] <pitti> seb128: happens to both of my USB HDDs (one has one vfat and one ext3 partition), and the delay scales with the size
[11:00] <seb128> pitti: could you try to figure if gnomevfs-ls does the same or if that's specific to nautilus and what it's doing while it's hanging?
[11:00] <pitti> seb128: and it does not just affect the first drive; when I attach the second one, I get another delay
[11:00] <pitti> and entire nautilus (browsers and desktop) are hanging
[11:00] <pitti> seb128: strace does not do anything while it is hanging
[11:00] <seb128> right, when nautilus hangs all the window are affected, that's a known issue
[11:01] <pitti> seb128: where do I get gnomevfs-ls? (and the bug reporter already noted that this works)
[11:01] <seb128> pitti: libgnomevfs2-bin
[11:01] <seb128> pitti: command-not-found should tell you that ;)
[11:02] <pitti> seb128: gnomevfs-ls works immediately
[11:03] <seb128> ok, that's what the comments on the bug were also saying
[11:03] <seb128> so it's due to nautilus
[11:03] <seb128> but I've no idea of what it's doing
[11:03] <pitti> ok, so I close the kernel task, and I'll do some gdb'ing
[11:05] <pitti> seb128: I'll first help dholbach with ubuntu-docs, then I'll look into this
[11:05] <seb128> pitti: thanks
[11:05] <pitti> this seems pretty important for the release to me
[11:07] <soren> Ok... ubiquity just crashed on my, and when I tell apport I'd like to report the problem, it shows me the info it claims to want to send. I click "Send", and nothing happens. Is the apport issue a known one?
[11:07] <pitti> hm, no
[11:07] <pitti> soren: do you get a progress bar for sending?
[11:07] <seb128> pitti: yes, it is
[11:07] <StevenK> Hobbsee: Heh
[11:07] <pitti> soren: it first uploads the blob to Lauchpad, then it should open a firefox window
[11:08] <soren> pitti: I think it might have uploaded the stuff, but ff never opens.
[11:08] <soren> I can try opening firefox first and see if that helps. Hang on.
[11:08] <pitti> soren: if you do /usr/share/apport/apport-gtk -c /var/crash/....crash, do you see any helpful output?
[11:08] <Hobbsee> StevenK: has anyone yelled at pitti yet, btw?
[11:08] <pitti> soren: shouldn't make a difference; in fact, it usually works *better* if ffox is not yet running; maybe you are experiencing it the other way round, though
[11:09] <pitti> Hobbsee: hm?
[11:09] <Hobbsee> pitti: cups-pdf was asking me for the root p/w when i was doing some upgrade testing in a chroot yesterday.
[11:10] <pitti> Hobbsee: oh, it seems that's due to lpadmin
[11:10] <Hobbsee> yeah
[11:10] <pitti> Hobbsee: hm, did you have cupsys running?
[11:10] <Hobbsee> pitti: dont think so - it was a chroot.
[11:10] <pitti> if you install it as root, it shouldn't ask for a password
[11:10] <soren> pitti: Hm... now it worked.
[11:10] <pitti> Hobbsee: it should say 'connection refused' or something
[11:13] <pitti> seb128: there is only ever one nautilus process which is responsible for both the desktop and all the windows, right?
[11:14] <pitti> seb128: so if I start the one from my built tree, I can gdb this one
[11:14] <Hobbsee> pitti: i dont think this was an install - it was an upgrade.
[11:14] <seb128> pitti: yes
[11:14] <pitti> seb128: so I just kick nautilus from my session, and then start it manually, I figure
[11:15] <seb128> pitti: yes
[11:15] <pitti> dholbach, mdke: ah, got it: /msgfmt: error while opening "ubuntu/windows/po/*.pot" for reading: No such file or directory
[11:16] <pitti> dholbach, mdke: it tries to interpret that as statistics output
[11:16] <soren> Someone was working on dm-crypted root and swap, right?
[11:17] <pitti> soren: that works now?
[11:17] <pitti> soren: i. e. it did after my cryptsetup initramfs script fixes
[11:17] <soren> pitti: That was going to be my next question :)
[11:17] <pitti> soren: today's daily should be good
[11:17] <soren> pitti: It's only in the alternate installer?
[11:17] <pitti> soren: yes
[11:17] <soren> Alright.
[11:17] <pitti> soren: in principle, the bits are there for desktop, too, but the UI bits are missing in ubiquity, I guess
[11:19] <soren> pitti: Sure.
[11:19] <seb128> carlos: is there a rosetta nautilus import waiting?
[11:19] <carlos> seb128: yes
[11:19] <pitti> dholbach, mdke: it just seems that the location of .pot files has been changed (from foo/po/foo.pot to foo/foo.pot); fixing
[11:20] <soren> I know Ian said you could do the conversion on the fly, but that's a really scary thought to me :), so I'm doing a reinstall on my laptop.
[11:20] <carlos> seb128: you can see it from https://translations.launchpad.net/ubuntu/gutsy/+source/nautilus/+imports
[11:21] <dholbach> pitti: oh great
[11:21] <seb128> carlos: do you know how long it's going to take?
[11:21] <pitti> dholbach: ok, it built fine now; I'll send you a diff
[11:21] <dholbach> pitti: if you send a debdiff to mdke, he can put it into svn again and I can roll the package and upload once he's happy with it
[11:21] <dholbach> pitti: afaik he wanted to some other changes anyway
[11:23] <carlos> seb128: well... it will still take a while, we have a huge delay :-( . We are preparing an announcement about that problem
[11:23] <pitti> dholbach, mdke: http://people.ubuntu.com/~pitti/tmp/ubuntu-docs.fix-pot.patch
[11:23] <seb128> carlos: ok :/
[11:25] <pitti> dholbach: mailed him the patch
[11:26] <dholbach> pitti: you ROCK
[11:26] <pitti> np
[11:35] <norsetto> anyone can give me a pointer about .la status? Should we or should we not include them in -dev packages....
[11:36] <slangasek> "it depends"?
[11:36] <norsetto> hehehe, thanks for the enligthment :-)
[11:36] <seb128> norsetto: don't stop shipping one now or it'll require a rebuild of all the packages which have a .la mentioning it
[11:36] <TheMuso> If a new bugfix release of gnome-orca were to be made upstream, what are the chances of getting it into gutsy?
[11:36] <norsetto> seb128: its a new package
[11:37] <seb128> don't ship it the, ;)
[11:37] <seb128> TheMuso: that's a GNOME stable version? updates are ok
[11:37] <norsetto> seb128: ok, any ref. I can use to convince upstream (beside the fact that .la are evil)
[11:37] <Hobbsee> Thew
[11:37] <Hobbsee> TheMuso: well, if you're happy with it...
[11:37] <slangasek> norsetto: if your library has a .pc file, there is no reason to ship .la files except the binary compatibility seb128 mentions
[11:38] <Hobbsee> TheMuso: you're one of the few people who will be using it, so... :)
[11:38] <TheMuso> Hobbsee: It hasn't been made a release yet. Upstream asked me about getting it in.
[11:38] <slangasek> norsetto: what do you need to convince upstream for?  if upstream uses libtool, libtool will still want to install the .la files; removing them from the package is a packaging decision
[11:38] <norsetto> slangasek: just thinking prehemptily ;-)
[11:38] <TheMuso> Ok thanks folks, I'll let them know.
[11:39] <norsetto> Hobbsee: hey, leave me nz!
[11:42] <iwj> mdke: Yes, you can add the new translation straight away.  The complicated transition is to make the locale Translatable (as defined); once it's Translatable you can add (or indeed remove) the translation itself without further ado.
[11:43] <iwj> The script provided by ubuntu-docs will provide the symlink iff the locale is Translatable but not translated.
[11:44] <iwj> slangasek: I've replied to bug 145231 but I'll see if I can dig out some better information.
[11:44] <ubotu> Launchpad bug 145231 in pidgin "cannot restart pidgin" [High,New]  https://launchpad.net/bugs/145231
[11:48] <slangasek> iwj: cheers
[11:51] <seb128> iwj: note that a new bug fix upstream version has been uploaded since and the bug might be fixed now
[11:55] <pitti> seb128: meh, it is helpful that nautilus is in uninterruptible kernel sleep during that time, and thus you can't prace it
[11:55] <pitti> ptrace, even
[11:55] <seb128> :(
[11:56] <iwj> seb128: Ah.
[11:58] <pitti> seb128: hm, the multiload applet is hanging during that time as well; weird
[11:58] <seb128> pitti: maybe gnome-vfs-daemon is hanging?
[12:00] <tkamppeter> pitti, have you seen my mail about cups-pdf and cupsys? I have moved the PDF destination to ~/Desktop now and made the package installing even if CUPS crashes when cups-pdf's maintainer scripts restart it.
[12:00] <pitti> tkamppeter: I saw it,  I'll get to it
[12:01] <pitti> tkamppeter: however, that would require allowing cups-pdf to write into ~/Desktop
[12:01] <pitti> well, it's not too bad, I figure
[12:01] <pitti> I can forbid it to read files in Desktop/
[12:01] <tkamppeter> pitti, for that I have already repackaged cupsys, modifying the apparmor profile
[12:02] <seb128> don't hardcode ~/Desktop guys
[12:02] <seb128> with xdg-user-dirs the directory can be translated now
[12:02] <tkamppeter> pitti, these entries have only a "w", so this should mean that there is write-only access
[12:02] <pitti> tkamppeter: why not just leave it as PDF?
[12:02] <pitti> tkamppeter: as long as PDF printing requires this crackful 'go through root daemon and back', we should confine it as tightly as possible
[12:03] <pitti> tkamppeter: also, I don't have a ~/Desktop at all (and many people don't)
[12:03] <tkamppeter> pitti, this way users will see the files appearing. Many users do not know that they will get dropped in PDF
[12:03] <pitti> tkamppeter: I use ~ as my desktop Dir (which is quite commonm)
[12:03] <seb128> pitti: did you read what I just wrote?
[12:03] <pitti> seb128: yes, that too
[12:03] <pitti> and since Gnome has built-in PDF creation support, it only affects the non-Gnome apps
[12:04] <tkamppeter> pitti, the default installation has a ~/Desktop dir and if the user simpy "rm -rf"s it not knowing fopr what it is good for cups-pdf recreates it.
[12:04] <pitti> seb128: gnome-vfs-daemon is not hanging, it works fine
[12:05] <seb128> pitti: hum, k
[12:05] <pitti> [pid 19503]  <... futex resumed> )       = -1 ETIMEDOUT (Connection timed out)
[12:05] <pitti> hmmm
[12:06] <pitti> seb128: this was after a stavfs() call; that might be it, perhaps
[12:07] <norsetto> pitti: I know it may not be the best time of the year, but, would you be available now to have a pupil?
[12:07] <pitti> norsetto: what do you mean with 'pupil'?
[12:08] <norsetto> pitti: you know, mentoring stuff: Me Mentor, you Pupil
[12:08] <pitti> oh
[12:08] <tkamppeter> There should be very few users modifying the Desktop's config to use another dir to display on the desktop.
[12:09] <Mithrandir> tkamppeter: that's irrelevant, you should respect the user.
[12:09] <pitti> norsetto: right, I'll have some more time at the start of Hardy, but if you have particular questions, or want a package to be reviewed, feel free to mail or IRC me
[12:09] <pitti> tkamppeter: but for those who do we should not break that
[12:09] <Mithrandir> tkamppeter: and by creating a ~/Desktop if that's not the user's desktop, you are not respecting the user.
[12:09] <pitti> tkamppeter: I really think that at this stage of the release, we should just go with ~/PDF
[12:09] <norsetto> pitti: thx for the offer :-) its not for me actually but I'll keep it in mind
[12:09] <Mithrandir> pitti: just ~/, I'd say.
[12:10] <pitti> Mithrandir: I'm nervous about giving cups-pdf any significant privileges in ~, TBH
[12:10] <Mithrandir> pitti: then I don't think we should ship it by default.
[12:11] <pitti> you could accidentally overwrite other PDF files you have, for example
[12:11] <cjwatson> we've kind of already announced it
[12:12] <Mithrandir> we're past beta and the security seems to be questionable, and the design not fully thought through?
[12:12] <pitti> I read the code under the assumption that it would write into ~/PDF/, and designed the AA rules that way; I am fine with the current staus
[12:13] <pitti> for moving it to ~, I'd need to re-review the code and rules
[12:13] <pitti> it's not significantly worse, but it sounds like it could clash with other files from the user, etc.
[12:13] <Mithrandir> heck, it shouldn't overwrite files in ~/PDF either without warning the user
[12:13] <pitti> I just object to changing it to ~/Desktop at this stge
[12:14] <pitti> Mithrandir: right, let me check
[12:14] <Mithrandir> and the program should be safe to use without apparmor; having security depend on the program being constrained to not do anything wrong sounds.. wrong.
[12:15] <Mithrandir> being constrained as opposed to having a safe and secure design
[12:15] <pitti> Mithrandir: as I have always said, I do *NOT* trust cupsys to run as root without AppArmor protection
[12:15] <pitti> and since the daemon calls cups-pdf, that transitively applies to cups-pdf
[12:15] <pitti> cups-pdf itself is reasonable code-wise, and small enough
[12:15] <pitti> but it's still called as root, thus it can get a forged user, etc.
[12:16] <Mithrandir> this really doesn't sound like something we should ship by default to me.
[12:16] <Mithrandir> announced or not.
[12:16] <pitti> Mithrandir: cupsys?
[12:16] <Mithrandir> cups-pdf
[12:17] <pitti> what's the difference? Any other backend could equally well be exploited to ruin your ~
[12:17] <Mithrandir> cups as such usually runs as non-root doesn't it?
[12:17] <pitti> the problem is that cups runs as root, not cups-pdf
[12:17] <pitti> Mithrandir: not any more
[12:17] <Mithrandir> why not?
[12:17] <pitti> our patches still had severe regressions, especially wrt. third-party drivers
[12:18] <pitti> and upstream is absolutely uncooperative about even thinking about a new safe design
[12:18] <pitti> so we eventually replaced the derooting patches with apparmor profiles
[12:18] <pitti> with the effect that cups now actually works as it should
[12:19] <pitti> Mithrandir: i. e. upstream does not say "Your patches suck", which I could understand
[12:19] <pitti> Mithrandir: they say "dude, cupsys must run as root, go away"
[12:19] <pitti> (without being able to tell a single reason why it has to)
[12:19] <Mithrandir> *sigh* :-(
[12:20] <pitti> indeed :/
[12:20] <Mithrandir> what does other distros say?
[12:20] <pitti> Mithrandir: we seem to be the only ones who care
[12:20] <pitti> it just runs as root everywhere else
[12:20] <pitti> and there's not even an official cupsd apparmor profile
[12:21] <pitti> I recently saw the beginnings of it in opensuse's AA repo
[12:22] <cjwatson> pitti: don't know if you noticed, but I committed a patch to apport to fix some of its Launchpad URLs for a milestoned bug; do you think you could review and upload?
[12:22] <pitti> cjwatson: oh, absolutely; you committed to trunk?
[12:22] <cjwatson> yes
[12:23] <pitti> erk, apparently I forgot to push last time; I'll merge
[12:24] <cjwatson> bound branches! :-)
[12:24] <pitti> well, I explicitly don't bind for apport, since I often commit lots of small changes
[12:25] <pitti> cjwatson: ah, looks fine; is it important to explicitly use bugs.lp?
[12:25] <cjwatson> pitti: I'm not sure, carlos filed a bug asking for it and somebody milestoned it
[12:26] <pitti> I see; sure, no problem
[12:26] <pitti> cjwatson: thanks
[12:26] <cjwatson> I figured better safe than sorry in case it was on the LP roadmap to break the old URLs
[12:26] <cjwatson> (which would be evil, but ...)
[12:26] <cjwatson> if you'd rather not, I'd accept an argument that it can wait :-)
[12:26] <carlos> pitti: it helps us to reduce the number of redirects for backward compatibility in Launchpad
[12:26] <cjwatson> carlos: surely the old redirects can never go away
[12:26] <carlos> pitti: though, the redirect needs still to be there
[12:26] <cjwatson> it just reduces the number of hits you get on them
[12:26] <pitti> cjwatson: no, that's fine; the new URLs work, I just always use https://lp.net for brevity
[12:27] <pitti> cool
[12:27] <carlos> cjwatson: we could do that once all distros using the old link are not supported anymore
[12:27] <cjwatson> carlos: http://www.w3.org/Provider/Style/URI
[12:27] <cjwatson> people's bookmarks don't stop being supported
[12:28] <carlos> cjwatson: that's why we add 301 instead of 303 (or is the other way around...?)
[12:28] <carlos> cjwatson: moved permanently redirects are supposed to update bookmarks or that's what I was told
[12:28] <cjwatson> if the bookmark is followed, and if the browser supports it ...
[12:29] <cjwatson> I'm happy to update the links in the browser but it's a terrible bug if Launchpad kills the old URLs at this point
[12:29] <cjwatson> er, "in the distro"
[12:29] <cjwatson> they've been publicised way too much
[12:30] <pitti> seb128: ok, confirmed; the statfs("/media/PittiHD") takes about a minute
[12:30] <cjwatson> +           [ -d $dir ]  || mkdir -p $dir
[12:30] <cjwatson> Keybuk: silly, mkdir -p is enough on its own
[12:31] <Keybuk> cjwatson: mkdir -p would fail if one of the intermediate paths was EPERM
[12:31] <carlos> cjwatson: ok, anyway, kiko wants it there forever too, so don't worry, you will keep your old URLs in place :-P
[12:31] <Keybuk> ie. if you were silly enough to have /var -x or something
[12:31] <seb128> pitti: iz kernel bog? ;)
[12:31] <cjwatson> Keybuk: huh, seriously?
[12:32] <cjwatson> it doesn't just check -d first?
[12:32] <pitti> seb128: maybe, I'll find the place where this happens and gdb over it
[12:32] <Keybuk> wing-commander scott% mkdir -p foo/bar
[12:32] <Keybuk> wing-commander scott% chmod -x foo
[12:32] <Keybuk> wing-commander scott% mkdir -p foo/bar
[12:32] <Keybuk> mkdir: `foo/bar': Permission denied
[12:32] <cjwatson> loony
[12:32] <pitti> seb128: I don't have a drive where I use ext3 exclusively, so it might indeed be specific to vfat
[12:32] <cjwatson> oh, of course it can't check
[12:32] <pitti> seb128: and I don't want to trash my 500 GB USB hard disk to try :/
[12:32] <cjwatson> Keybuk: but then [ -d ]  would fail too!
[12:32] <seb128> pitti: understable
[12:33] <Keybuk> cjwatson: right, but silently and not enough to bail out a -e script
[12:33] <seb128> pitti: comments on the bug suggests it happen also for disk partitions
[12:33] <Keybuk> though I think that one's not -e anyway
[12:33] <cjwatson> Keybuk: er
[12:33] <cjwatson> Keybuk: you do [ -d ]  || mkdir -p
[12:33] <Keybuk> yes
[12:33] <cjwatson> Keybuk: [ -d ]  will fail and the mkdir -p will happen anyway
[12:33] <cjwatson> so the [ -d ]  achieves nothing at all
[12:33] <Keybuk> oh, damn
[12:33] <Keybuk> you're right :)
[12:33] <Keybuk> and here was me thinking I was being smart
[12:33] <Keybuk> lol
[12:33] <cjwatson> I'd just mkdir -p || true
[12:34] <Keybuk> yeah
[12:34] <Keybuk> doesn't make much practical different of course
[12:34] <cjwatson> I have a change to make in sysvinit anyway, so I'll do that
[12:34] <Keybuk> ok
[12:34] <seb128> pitti: if that happened on ext3 I think we would have noticed
[12:35] <cjwatson> Keybuk: you should have seen the wild constructions partman was using to avoid mkdir -p
[12:35] <cjwatson> I found a place where somebody had decided to implement it by hand, including adding non-existent directories to a space-separated list and iterating over them in reverse order
[12:35] <StevenK> cjwatson: As bad as mkdirhier?
[12:35] <cjwatson> StevenK: pretty much
[12:36] <cjwatson> busybox has mkdir -p, so I ripped it all out
[12:36] <StevenK> I wonder how many kittens that code cost. :-P
[12:42] <tkamppeter> pitti, so I will move the PDF destination back to ~/PDF as this is a constant and not a user-specific value like ~/Desktop.
[12:43] <pitti> tkamppeter: are there any other changes in the packages?
[12:43] <tkamppeter> pitti, yes, especially making it configure whenthere are CUPS problems.
[12:44] <mvo> could someone please translate "sistema de ficheros del archivo tar daado - archivo de paquete daado" for me (dpkg error msg)
[12:44] <tkamppeter> The cupsys you do not need to upload, as it is only to make AppArmor allowing cups-pdf to write (not read) into ~/Desktop
[12:45] <Mithrandir> mvo: msgid "corrupted filesystem tarfile - corrupted package archive"
[12:45] <tkamppeter> pitti, another change is to preceed the file names of the PDFs by the job number, so that if the job title is always the same (and not the document name) that the files do not overwrite each other.
[12:46] <mvo> Mithrandir: thanks !
[12:46] <pitti> tkamppeter: we should rather teach cups-pdf to use a -N suffix
[12:46] <pitti> tkamppeter: i. e. foo.pdf, foo-1.pdf, foo-2.pdf, etc.
[12:47] <pitti> tkamppeter: starting at a random number might be too confusing
[12:49] <tkamppeter> pitti, so I will stay only with the install issue and reopen all the other bugs: bug 147551, bug 134671, bug 134682
[12:49] <ubotu> Launchpad bug 147551 in cups-pdf "cups-pdf fails to generate file" [Medium,Fix committed]  https://launchpad.net/bugs/147551
[12:49] <ubotu> Launchpad bug 134671 in cups-pdf "[Tribe5]  cups-pdf do not overwrite existing pdf" [Medium,Fix committed]  https://launchpad.net/bugs/134671
[12:49] <ubotu> Launchpad bug 134682 in cups-pdf "[Tribe5]  user don't know where are his pdf file" [Undecided,Fix committed]  https://launchpad.net/bugs/134682
[12:50] <tkamppeter> pitti, all the rest we should not do on our own but let upstream redesign the appropriate parts of the tool.
[12:50] <pitti> yeah
[12:51] <tkamppeter> pitti, for file visibility they should do a D-Bus notification thingy instead of cluttering the user's desktop with files.
[12:52] <Mithrandir> no, it should just ask the user where he wants to save the file.
[12:52] <tkamppeter> pitti, for files not overwriting each other they should add date and time at the end of the file name as the job number is something strange for non-technical users. Also files with the same document name should stay close to each other.
[12:53] <tkamppeter> Mithrandir, this would be the best. Can the backend pump the PDF through the D-Bus so that a tool running as the user is popping up and asking the user for saving the file?
[12:54] <pitti> tkamppeter: upstream would not accept that, since it's bound to Gnome
[12:54] <tkamppeter> pitti, or should we open a spec to start a new PDF generator project from scratch. Problem is to find the people to implement it.
[12:55] <pitti> tkamppeter: I'd rather convert the remaining desktop apps to use libgnomeprint, or so; it should all be done on the client side, without the need to go through cups
[12:55] <tkamppeter> pitti, what would upstream not accept? The use of D-Bus?
[12:55] <pitti> tkamppeter: cups-pdf is specifically meant to work for non-Gnome apps
[12:56] <asac> stgraber: did you post the driver log yesterday? I had issues and loosed my log of this channel yesterday
[12:56] <tkamppeter> pitti, so then we leave cups-pdf as interim solution until the application developers will catch up and do not develop new features for it. We will simply sync with upstream and fix the bugs.
[12:57] <stgraber> asac: no, I'll try to get one today (no idea why I can't get one with debug=1 and 65536 as debug value ...)
[12:57] <pitti> tkamppeter: might be best; cups-pdf is and remains a nasty hack, regardless of how many bug fixes you apply to it :/
[12:58] <tkamppeter> I will mark all open feature-requesty bug reports on it as "Wontfix"/"Wishlist" telling that it is an interin solution which will be removed as soon as all app developers are following the standards.
[12:59] <pitti> tkamppeter: oh, please leave it open as wishlist; they might be justified
[01:04] <tkamppeter> pitti, so I make them "Confirmed"/"Wishlist" so that upstream can decide on them.
[01:09] <soren> pitti: You did the partman cryptolvm thingie?
[01:10] <pitti> soren: I just fixed the cryptsetup initramfs hook to get along with UUIDs, so that a system installed with that partman-crypto-auto module actually boots
[01:10] <soren> pitti: Do you know what the rationale behind the blockdev-wipe is?
[01:10] <pitti> soren: just paranoia
[01:10] <soren> pitti: No way to disable it?
[01:10] <soren> pitti: It makes installing in vmware *a *pain*.
[01:11] <pkern> soren: There is a file in /lib/partman (I think.)
[01:11] <pitti> soren: if you randomize the entire drive prior to putting an encrypted partition on it, it is much harder to tell where it ends, and where the actual data is, etc.
[01:11] <pkern> soren: You could add it to disable it, I did so too but it was weeks ago.
[01:11] <pitti> (provided that you don't have a partition table that tells you, of course)
[01:11] <pkern> s/add/modify/
[01:11] <pitti> soren: you can disable it
[01:11] <pitti> soren: have it setup the partitioning, say 'no' to the confirmation, and disable erasing
[01:11] <soren> pitti: Ah... point!
[01:11] <pkern> Oh there is a GUI way. Nice.
[01:12] <tkamppeter> pitti, I have updated bug 134682 appropriately. Is it OK this way?
[01:12] <ubotu> Launchpad bug 134682 in cups-pdf "[Tribe5]  user don't know where are his pdf file" [Wishlist,Confirmed]  https://launchpad.net/bugs/134682
[01:13] <pitti> tkamppeter: fine for me, thank you
[01:17] <pitti> seb128: I confirmed that it is really a kernel bug, updated the bug trail accordingly; sorry for the noise
[01:18] <seb128> pitti: that's no noise but useful informations, thanks a lot ;)
[01:18] <pitti> seb128: I just can't find any stat.*fs invocation in nautilus itself, so I don't know where to start gdbing
[01:18] <soren> pitti: Gah.. I would have thought that going back from the "write changes to disk..." dialog would have the manual partitioner all filled in with the automatic values.
[01:18] <seb128> pitti: likely gnome-vfs
[01:19] <pitti> soren: not "go back", say "no"
[01:19] <pitti> soren: "go back" doesn't work
[01:19] <soren> pitti: I did say "no".
[01:19] <pitti> soren: hm, it worked for me
[01:19] <soren> pitti: You had all the values filled in? For me it just showed /boot and the other partition marked as crypto/"dont use" or something.
[01:20] <soren> So I had to fill in the encryption config first, add a pv to it, create an lv and blahblah..
[01:20] <pitti> soren: yes, I tried it in vmware; it required some more going back and forth, but it worked
[01:20] <soren> I'll start over..
[01:21] <seb128> pitti: file-method.c has some statfs calls
[01:21] <seb128> also fstype.c
[01:21] <pitti> seb128: ah, I'll have a look
[01:24] <pitti> seb128: hm, I breakpointed both, no luck
[01:25] <seb128> running nautilus under gdb, doing ctrl-C when it hangs and "thread apply all bt full" doesn't give any clue?
[01:25] <pitti> seb128: that's the point; you can't ^C a program while it is in a syscall (uninterruptible kernel sleep)
[01:25] <pitti> so I need to breakpoint it right before
[01:27] <pitti> seb128: I have some more ideas, I'll report back
[01:29] <soren> pitti: No matter how I go back and forth, I end up with a 255 MB primary partition on /boot and a 8.3 GB logical partition, type encrypted, "not active".
[01:29] <pitti> soren: hm, weird
[01:30] <pitti> soren: let me try it here
[01:33] <pitti> soren: hm, indeed; no idea how I managed to do this back then
[01:33] <soren> pitti: oh!
[01:33] <soren> After it wipes the disks, it shows me everything.
[01:34] <soren> Sorry, that's not entirely true.
[01:34] <pitti> right, but that's too late
[01:34] <viviersf> Which mirror has the most recent uploaded packages ?
[01:34] <pitti> viviersf: archive.u.c.
[01:35] <soren> I hacked the /lib/partman/crypt* script to not do the wipe. Now, when I allowed it to go on, it ended up on that "page"
[01:35] <viviersf> pitti, ok cool thanks
[01:35] <soren> I've always wondered... What's the point of lvm if it uses the entire lv by default anyway?
[01:35] <soren> Er... vg, I mean.
[01:36] <pitti> soren: not sure what you mean? we have one VG "Ubuntu" which holds all the partitions; doesn't that make sense?
[01:36] <pitti> (except /boot, of course)
[01:36] <soren> pitti: Yes, but why does the / lv have to use all the space in the vg?
[01:37] <soren> pitti: What purpose does lvm serve in that case?
[01:37] <pitti> soren: it's exactly like our standard setup; provide a reasonable swap, and the rest for /
[01:37] <tkamppeter> pitti, Riddell has uploaded the new cupsys and cups-pdf (forgot to remove them from my server immediately) I will make new packaes of both.
[01:37] <pitti> soren: the purpose is to combine / and swap into a single encrypted entity
[01:37] <pitti> soren: if we wuold have swap with a random password, then resuming from suspend to disk would break
[01:38] <pitti> soren: if we had two encrypted drives with / and swap, you'd need to passwords, or enter it twice
[01:38] <soren> pitti: Ah, right in the encrypted case, I see a bit of an advantage, but if not, why would anyone want to use the autolvm thing instead of the regular partitions?
[01:38] <pitti> tkamppeter: darn, they have already gone from accepted
[01:39] <pitti> soren: no idea; maybe to have an initial start, or so; I don't see the advantage either
[01:39] <pitti> tkamppeter: if you say that we don't need any changes, let me just reupload my current svn
[01:39] <pitti> tkamppeter: so that I get immediate consistency with svn again
[01:40] <blue|palm> if I have an idea to enhance gnome and I am able to implement it, but would like it to be included in the next ubuntu release, where do i go with my proposal?
[01:40] <pitti> ah, right, no "accepted" for source packages any more
[01:41] <soren> blue|palm: Depending on the nature of your enhancement, you can either register a blueprint on launchpad or talk to the gnome developers about it.
[01:41] <soren> blue|palm: If it ends up in gnome, it lands in Ubuntu automatically.
[01:41] <tkamppeter> pitti, in cupsys all changes can get undone. In cups-pdf the "does not install/upgrade" fix
[01:41] <pitti> tkamppeter: right, please make a new cups-pdf which contain your other fixes
[01:42] <tkamppeter> es have to stay in.
[01:42] <cjwatson> blue|palm: or often just file a bug, if it's small - blueprints are for complex ideas which require design or coordination among multiple components
[01:42] <blue|palm> soren, thanks, do you know what is the normal method of communication the gnome devs use? IRC, mailing list?
[01:42] <tkamppeter> pitti, so a new cupsys is not needed? This you can roll back?
[01:42] <pitti> tkamppeter: I'll upload a new one
[01:42] <pitti> tkamppeter: but I use the svn for that
[01:43] <blue|palm> cjwatson, its a small enhancement to an already working aspect of gnome... but i believe it will increase productivity... ill go with filing a bug report
[01:45] <pitti> tkamppeter: cupsys done
[01:45] <seb128> blue|palm: what is your idea?
[01:47] <blue|palm> seb128, to improve the gnome file copy/move dialogue. I intend to add an 'advanced mode' to allow for pause/resume/speed limitation as well as queueing up file transfers... lastly to add a manager applet of some sort to easily manage your transfers (instead of having 5 copy dialogues open at once, you could hide them and instead monitor them as a list in the manager)
[01:49] <blue|palm> seb128, I'd like to add this almost transparently to the current system, so that normal users can just copy files like usual, but power users/users copying large numbers/sizes of files can use this system
[01:49] <soren> blue|palm: Shouting :)
[01:49] <seb128> blue|palm: I think there is already some bugs upstream about that
[01:50] <blue|palm> seb128, well, i'd like to implement the idea...
[01:50] <seb128> nice ;)
[01:50] <seb128> blue|palm: you might want to mail nautilus-list@gnome.org
[01:50] <blue|palm> seb128, i'm just have no idea how to make it 'official' with gnome
[01:50] <seb128> with your ideas, etc for discussion
[01:50] <blue|palm> seb128, thanks, ill do that
[01:51] <blue|palm> soren, what do you mean by 'shouting'?
[01:51] <seb128> I'm subscribed to the list so I'll read about it there ;)
[01:51] <soren> blue|palm: I was replying to your question about how to contact gnome developers. :)
[01:51] <blue|palm> soren, ah ok :-)
[01:52] <blue|palm> ugh, i personally hate lists... but here goes :-D
[01:53] <cjwatson> blue|palm: you won't get far in free software development if you avoid mailing lists :)
[01:53] <blue|palm> cjwatson, i've realised that
[01:57] <blue|palm> can anybody tell me what tech is behind the network icon (i think its called the network manager applet; the thing that gives you a list of wifi networks/dialup connections etc.) that was introduced into ubuntu recently? is it written in python? or C/C++? and what library is it using? Im looking to create something similar...
[02:01] <stgraber> blue|palm: it's the network-manager, it has two parts, a system daemon and a gnome applet. It's written in C, using dbus for communication between the applet and the daemon.
[02:01] <blue|palm> stgraber, thanks
[02:05] <tkamppeter> pitti, new cups-pdf is in place now, see mail. I have also updated all bug reports. So except urgent bugs printing is ready for Gutsy now.
[02:05] <tkamppeter> Which day is RC freeze
[02:06] <cjwatson> we'll freeze the archive at some point tomorrow
[02:06] <cjwatson> at least that's the current plan
[02:07] <Hobbsee> cjwatson: ARGH!
[02:07] <Hobbsee> cjwatson: is that full freeze?
[02:07] <Hobbsee> as in, fully frozen freeze for main?
[02:07] <pitti> is it just me, or is LD_LIBRARY_PATH broken (i. e. not working at all) for everyone in gutsy?
[02:07] <ogra> cjwatson, huh ?
[02:08] <cjwatson> Hobbsee: yes, with exceptions as usual
[02:08] <ogra> whee, thats quick ...
[02:08] <cjwatson> ogra: I said what I said. The standard release candidate process is to freeze one week before release candidate; this is in fact relaxing that slightly
[02:08] <cjwatson> pitti: you sure it's not a set-id binary?
[02:08] <ogra> yeah, i was just confused since its not listed on the schedule
[02:08] <pitti> cjwatson: yes, I am
[02:08] <Hobbsee> cjwatson: crap.
[02:09] <pitti> cjwatson: LD_DEBUG shows that it uses the path for the first resolution, and forgets about it afterwards
[02:09] <pitti> this makes debugging a lot more painful that it has to be
[02:09] <cjwatson> Hobbsee,ogra: compare https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-April/000274.html with https://wiki.ubuntu.com/FeistyReleaseSchedule, for example
[02:10] <Hobbsee> cjwatson: i know you're probably right, but i still thought it was a little further away
[02:10] <ogra> hmm, i didnt get that mail .. something is broken with my list setup it seems
[02:11] <ogra> oh, wait april
[02:11] <ogra> heh
[02:12] <Hobbsee> cjwatson: us ubuntu people arent good at getting dates right.
[02:12] <Hobbsee> oh cool, watch is only two minutes slow now.
[02:13] <TheMuso> Hobbsee: tsk tsk tsk. You need to get it synced with an ntp server. :)
[02:13] <ogra> Hobbsee, all fault of the clock applet
[02:13] <Hobbsee> TheMuso: the dvd unlocking things actually slow our watches down.
[02:13] <TheMuso> That doesn't surprise me actually.
[02:13] <Hobbsee> TheMuso: we lose 15 mins or so for every 40 hours worked
[02:13] <TheMuso> Since its a magnetic thing.
[02:13] <Hobbsee> the closer we are to it, the more loss.
[02:14] <Hobbsee> not kidding - we did an experiment on this, as the boss was always asking us why we were going early - where it was actually her watch being slow.
[02:14] <Hobbsee> cjwatson: universe isnt freezing for ages, i tkae it?
[02:15] <cjwatson> Hobbsee: technically though not by policy
[02:15] <Hobbsee> cjwatson: great - manual shoves required, i take it.
[02:16] <cjwatson> yes
[02:17] <Hobbsee> cjwatson: cool, OK, i can ignore that queue for longer then.
[02:19] <TheMuso> Hobbsee: heh. Gotta love procrastination.
[02:20] <Hobbsee> TheMuso: procrastination is very useful.  and i've been catching up with uni stuff and friends (yes, i have some), as i cant spend all my time on ubuntu.
[02:20] <TheMuso> Hobbsee: Yeah I know. :)
[02:26] <TheMuso> _MMA_: So what do you say? Just ditch the multiple tasks for now, and make everything installed? If so, I have a very good idea of how this is to be done, and compared to what we've had to do so far, it is piss easy.
[02:26] <cjwatson> TheMuso: blink, what?
[02:26] <cjwatson> what's wrong with tasks now?
[02:26] <Hobbsee> TheMuso: no, i can just assign the entire queue to you - no procrastination required.
[02:26] <TheMuso> cjwatson: Sorry, wrong window.
[02:27] <TheMuso> cjwatson: Basically hard coding ubuntustudio-desktop to the seed deps causes recommends packages not to be installed, so we're just pondering making everything installed at once, saving us the headache of working this out till Hardy.
[02:28] <cjwatson> TheMuso: that's easily fixed
[02:28] <cjwatson> it's just because ubuntustudio-* is in the wrong section
[02:28] <cjwatson> I can fix that in the archive right now
[02:28] <TheMuso> chuck_: Oh ok. Wrong section
[02:28] <TheMuso> cjwatson: Oh ok. What section?
[02:29] <cjwatson> TheMuso: metapackages
[02:29] <TheMuso> oh
[02:29] <cjwatson> well, universe/metapackages
[02:29] <cjwatson> TheMuso: changed in the archive; feel free to change the source at your leisure
[02:30] <_MMA_> *and BenC :)
[02:30] <TheMuso> cjwatson: Oh ok. Since I took over maintanance of meta, I didn't even think to check that. :)
[02:32] <Keybuk> pitti: have you seen the "Gutsy's HAL is broken" thread on devel-discuss
[02:33] <Keybuk> the author replied with some fairly extensive attempt at debugging
[02:33] <Hobbsee> he's on irc now, too
[02:34] <pitti> Keybuk: I saw it, yes; still stuck in nautilus debugging, but I'll look at it
[02:34] <Keybuk> :)
[02:34] <Hobbsee> hm, until he walked away and decided that irc was pointless.
[02:34] <Keybuk> intelligent man
[02:43] <xjkx> "Ubuntu 6.06 LTS - Supported to 2011" that means you will keep updating and keeping it safe and cool until 2011 right?
[02:44] <xjkx> i think i will give it a try
[02:44] <jdong> xjkx: for main, yes, and by updating, we mean security and very very critical bugfixes
[02:45] <jdong> xjkx: don't be like the mepis guy and assume we'd be putting GNOME 2.20 in Dapper by 2011 ;-)
[02:45] <xjkx> hehe it means never getting new versions ;] 
[02:46] <jdong> of course it confuses me why he went back to Debian stable releases....
[02:46] <jdong> and backporting packages from sid.
[02:46] <jdong> when he could've just backported from gutsy like what I do everyday...
[02:52] <Fujitsu> jdong: Remember that the MEPIS guy seems convinced that Ubuntu is... erm... rebuilt almost from scratch each time, from Debian experimental.
[02:52] <StevenK> Whadya mean it's not? :-P
[02:55] <asac> carlos: ok how can i get the translations?
[02:55] <carlos> asac: ?
[02:55] <Keybuk> xjkx: 2011 on the server
[02:55] <carlos> asac: I'm working on the code that would allow you to get them
[02:55] <Keybuk> for, as pointed out, security fixes and critical bug fixes
[02:55] <Keybuk> a little less on the desktop
[02:56] <carlos> so it's not possible yet
[02:56] <asac> carlos: ok ... how can i help then?
[02:56] <carlos> asac: though, I'm leaving to have lunch now, and I have a meeting when I'm back from lunch, do you mind to have a meeting around 15:00 UTC ?
[02:57] <asac> carlos: thats fine
[02:57] <carlos> ok, thanks
[02:57] <Mithrandir> seb128: can I have the applications menu, etc, have their text horisontal on a vertical panel?
[02:58] <seb128> Mithrandir: no
[02:58] <seb128> Mithrandir: that would make a really large panel
[02:58] <Mithrandir> seb128: 100px or so?  Which isn't much when my display is 2560 pixels wide.
[02:58] <asac> seb128: i always liked having the panel on the right/left ... but gnome panel appears to behave strangly; is there something planned for that upstream?
[03:00] <asac> (especially the taskbar)
[03:00] <seb128> Mithrandir: well, there is no option to configure that, and 200 pixels is a lot on a 1024x768 screen
[03:00] <asac> seb128: ok it appears to have improved in this gnome-panel ... so don't bother for my comment
[03:00] <Mithrandir> seb128: it could autorotate if the panel was wide enough that it made sense?
[03:00] <seb128> asac: there is some bugs open for ages but nobody actively working on them
[03:00] <seb128> Mithrandir: yes
[03:01] <Mithrandir> http://err.no/tmp/panel.png looks kinda funny
[03:02] <Keybuk> hurrah, my laptop appears to be tea-proof
[03:05] <minghua> Mithrandir: Maybe you can try the menu with no texts but only the icon.
[03:07] <amitk> Keybuk: upto how many meters?
[03:11] <jdstrand> asac: re bug #138217
[03:11] <ubotu> Launchpad bug 138217 in network-manager "NetworkManager fills log on start up until dhcdbd has started" [Medium,Fix released]  https://launchpad.net/bugs/138217
[03:11] <jdstrand> asac: grep 'Oct  4 09.* dhcdbd not running' /var/log/daemon.log|wc -l
[03:11] <jdstrand> asac: 46
[03:11] <jdstrand> asac: woohoo!
[03:12] <jdstrand> asac: thanks!
[03:18] <norsetto> mvo: ping
[03:21] <mvo> norsetto: pong
[03:22] <norsetto> mvo: hi :-) Just wondering if you looked at bug 131166 recently?
[03:22] <ubotu> Launchpad bug 131166 in apt "[gutsy]  apt-get update deletes local Packages.gz file" [High,Confirmed]  https://launchpad.net/bugs/131166
[03:23] <mvo> norsetto: let me check, I was sure that this got fixed
[03:23] <norsetto> mvo: well, it didn't ....
[03:24] <mvo> norsetto: urghs, ok
[03:24] <norsetto> mvo: but the last patch fixes it
[03:24] <mvo> norsetto: thanks! I milestoned it now
[03:49] <janimo> hello, in the daily xubuntu builds http://cdimage.ubuntu.com/xubuntu/daily-live/20071004/
[03:50] <janimo> it seesm the manifest is still from sep 25
[03:50] <janimo> and the iso I have tested did not have the latest packages
[03:50] <janimo> (older xubuntu-desktop and usplash at least)
[03:50] <Mithrandir> janimo: that was fixed today, iirc
[03:51] <janimo> Mithrandir: was the build not reenabled afetr beta? ok, thanks
[03:51] <Mithrandir> janimo: some problem on the buildds, afaik
[03:51] <janimo> ok, I'll test tomorrwo
[03:53] <Keybuk> cjwatson: did you rebuild d-i after fixing busybox?
[03:53] <cjwatson> Keybuk: no
[03:53] <cjwatson> Keybuk: I'm going to do it when the kernel ABI change lands
[03:53] <Keybuk> ok
[03:53] <Keybuk> Ng: ^ :-)
[03:54] <cjwatson> which should be soon
[03:54] <Ng> ah, ok
[03:54] <Ng> thanks
[03:54] <tepsipakki> just copying [ to /bin works for now :)
[03:54] <cjwatson> yeah, that should be ok
[03:55] <Kopfgeldjaeger> hi
[04:01] <mantiena-baltix> hi all
[04:01] <asac> jdstrand: thanks for confirming the fix
[04:01] <jdstrand> asac: np :)
[04:05] <MacSlow> brb
[04:09] <lamont> doko: what was your bind9 change?
[04:09] <jdstrand> soren: in looking at bug #119075 , I was thinking of simplifying things, and just do test_mysql_access right from /etc/init.d/mysql at the end of 'start'.  This will make it so I don't have to do anything to postinst
[04:09] <ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [Undecided,In progress]  https://launchpad.net/bugs/119075
[04:10] <doko> lamont: not installing the upstream changelog in the library packages to save space on the CD
[04:10] <lamont> ah, because -2 beat you out
[04:10] <jdstrand> soren: it was prompted by the fact that even more changes would have to be made to postinst to get the message shown on upgrade
[04:10] <jdstrand> soren: thoughts?
[04:10] <doko> lamont: I don't think there's apolicy
[04:11] <lamont> doko: got a diff for me?
[04:12] <doko> lamont: http://paste.ubuntu-nl.org/39533/
[04:12] <doko> lamont: or create a -common package and symlink the whole doc directories, will save even more space
[04:12] <lamont> If an upstream changelog is available, it should be accessible as /usr/share/doc/package/changelog.gz in plain text.
[04:13] <lamont> so, sounds like a symlink to share/doc/bind9/changelog.gz is in order
[04:15] <doko> lamont: in this case, you need a common dependeny package, but your source package doesn't have this
[04:15] <doko> and then, I would prefer a symlink to the doc directory
[04:16] <lamont> your patch, as I read it, does the same thing that I did, only in 2 steps...
[04:16] <lamont> first install it everywhere but bind9 and libbind-dev, then install it specifically in those two pacakges
[04:17] <pitti> seb128: since I doubt that we can fix the kernel in time, the only workaround I can imagine is to not display the free space for VFAT drives in nautilus
[04:18] <seb128> pitti: works for me, I think that's better than hanging
[04:18] <lamont> so.. I'll deliver the upstream changelog in bind9-doc, with a note
[04:18] <pitti> seb128: I confirmed that this fixes the hang at least
[04:18] <pitti> seb128: but I'd do the hack in nautilus, not in gnome-vfs
[04:18] <seb128> pitti: what did you change, where?
[04:19] <seb128> pitti: right
[04:19] <pitti> seb128: I don't want to break the actual call (gnome_vfs_get_volume_free_space())
[04:19] <pitti> seb128: ./libnautilus-private/nautilus-file.c, nautilus_file_get_volume_free_space()
[04:19] <pitti> seb128: I might do it one level above, in the filemanager view
[04:20] <seb128> pitti: wherever you think it's the best place to do the change
[04:20] <bddebian> Heya
[04:20] <pitti> seb128: I'll make it so that the properties window hangs and returns the correct result, whereas the browser doesn't show it and hangs
[04:21] <seb128> ok
[04:21] <pitti> erm, s/hangs$/does not hang/, of course
[04:26] <doko> lamont: dh_installchangelogs doesn't install the upstream changelog by default ...
[04:26] <soren> jdstrand: Without seeing the actual code, I think I'd prefer it in the init script.
[04:26] <doko> ohh, pasto, right, I should remove that ...
[04:26] <doko> lamont: will you upload?
[04:26] <lamont> doko: yes
[04:26] <doko> thanks
[04:26] <lamont> +       dh_installchangelogs -a -Nbind9 -Nlibbind-dev CHANGES
[04:26] <lamont> +       dh_installchangelogs -pbind9 -plibbind-dev CHANGES
[04:27] <lamont> that still looks like no change...
[04:27] <doko> lamont: dh_installchangelogs -a -Nbind9 -Nlibbind-dev
[04:27] <lamont> right.
[04:27] <jdstrand> soren: yes.  it is slightly less efficient (ie its checked every time mysql is started), but really that is good-- in case the password is inadvertantly blanked via some other means
[04:27] <lamont> I pasted what you pasted though...
[04:27] <jdstrand> soren: it also makes the changes to the packaging less intrusive
[04:28] <jdstrand> soren: thanks
[04:28] <soren> pitti: If my fresh install with cryptlvm and stuff doesn't boot properly (installed from current daily alternate cd), is that because your fix hasn't hit the dailies yet, or is it just simply still b0rken?
[04:29] <pitti> soren: hm, sounds like the latter; it did work with my locally applied patch
[04:29] <pitti> soren: which cryptsetup version do you have on the CD?
[04:29] <lamont> doko: http://paste.ubuntu-nl.org/39535/ look good to you?
[04:30] <doko> lamont: yes
[04:30] <soren> pitti: ./pool/main/c/cryptsetup/cryptsetup-udeb_1.0.5-2ubuntu1_i386.udeb
[04:31] <pitti> soren: hm, that should have the fix
[04:31] <pitti> soren: I'll do a test install as well to check what's going in
[04:31] <pitti> on
[04:32] <soren> pitti: Where's the config file supposed to be in the initramfs?
[04:33] <soren> Or should the luks signature just be detected and prompt me for my password?
[04:33] <pitti> soren: conf/conf.d/cryptroot should have one target with the correct 'outer' (encrypted file system name
[04:33] <soren> no, that wouldn't be clever..
[04:33] <soren> I only see resume in /conf/conf.d
[04:34] <pitti> hm, that's wrong then
[04:34] <soren> pitti: I'll get it booted and try update-initramfs'ing.
[04:34] <pitti> soren: that was my patch which made it work: http://people.ubuntu.com/~pitti/tmp/cryptroot.diff
[04:35] <pitti> soren: please try update-initramfs -u
[04:35] <soren> Sure.
[04:35] <pitti> soren: in the running system and check whether it makes any difference
[04:36] <soren> Yeah, that's what I was going to do. I'm just waiting for it to boot.
[04:36] <soren> Heh... It asks me for my luks passphrase, when it gets to early crypto disks...
[04:36] <lamont> *** glibc detected *** /usr/bin/uic3: free(): invalid pointer: 0x0012484c ***
[04:37] <lamont> I find that annouing
[04:37] <lamont> annoying, even
[04:37] <Keybuk> I still read that as "glibc detected" being the problem
[04:37] <Keybuk> "OMG! DUDE! GLIBC!"
[04:38] <Hobbsee> no glibc for you@
[04:38] <soren> pitti: I get a couple of warnings about an invalid line in /etc/crypttab
[04:38] <lamont> Keybuk: LOL
[04:40] <pitti> soren: oh, that would be it
[04:40] <pitti> soren: what's your crypttab?
[04:40] <soren> sda5_crypt /dev/disk/by-uuid/<uuid of my sda5> none luks
[04:41] <pitti> hm, that looks fine
[04:41] <pitti> soren: ok, thanks; I'll do a test-install and fix it
[04:41] <pitti> soren: I think we will have pretty much identical vms :)
[04:42] <pitti> soren: siretart merged some other fixes from Debian along with my patch, so maybe they interfered somewhat
[04:44] <soren> pitti: Wow.. There's massive differences between those two initramfs's.
[04:45] <soren> pitti: I did not expect that.
[04:47] <sladen> pitti: it'd be good to test the non-LVM code-paths
[04:48] <sladen> pitti: creating three normal partitions (/boot, /, swap) setting each of those to be cryptoed
[04:48] <pitti> right
[04:56] <Hobbsee> people, is ubuntu-minimal supposed to depend on util-linux, or linux32?  L32 C/R/P's util-linux
[04:57] <sladen> with your -dbgsym, where's it expecting to find the source code?
[04:57] <sladen> pitti: ^^ ;  eg. somewhere under /usr/share  if I unpack the source code in the right place;  or is it looking in the current directory
[04:57] <pitti> sladen: that doesn't work, I'm afraid; I guess it's something like /build/buildd/
[04:57] <pitti> this stuff was designed ATM to get good backtraces
[04:58] <pitti> not sure whether the paths can be mangled
[04:58] <soren> It works if it's in $PWD, too.
[04:58] <sladen> think RH do mangle the paths to be  /somewhere/package-name/foo.c
[04:58] <soren> /usr/src would make sense..
[04:58] <sladen> pitti: then their dbgsym package also includes the source code
[04:59] <cjwatson> Hobbsee: other way round, util-linux C/R/P's linux32
[04:59] <pitti> soren: which part of the search path does it strip off for $PWD?
[04:59] <asac> carlos: will be here in 3 minuts ... maybe chat in #ubuntu-mozillateam?
[04:59] <cjwatson> Hobbsee: I think sticking with util-linux there is fine
[04:59] <carlos> asac: sure
[04:59] <Hobbsee> cjwatson: oh, my bad.
[04:59] <cjwatson> Hobbsee: and certainly util-linux is definitely needed anyway
[05:00] <soren> pitti: No clue. I just remember I've used the debug symbols with the samba source in $HOME/src somehow.
[05:00] <soren> pitti: I suspect it's gdb doing something clever.
[05:00] <pitti> soren: apport-retrace just strips off the path and then tries to find the file name in the unpacked and patched source tree
[05:00] <pitti> soren: (for generating the sourceful stack trace)
[05:00] <Hobbsee> cjwatson: it's a 1am-ism, i think
[05:01] <soren> pitti: I see.
[05:01] <pitti> meh, I should have done a CLI installation; this one will take ages
[05:03] <Hobbsee> doko: ping
[05:03] <doko> Hobbsee: ?
[05:03] <Hobbsee> doko: just letting you know, your upload has caused https://bugs.edge.launchpad.net/ubuntu/+source/gimp/+bug/148985
[05:03] <ubotu> Launchpad bug 148985 in gimp "package gimp 2.4.0~rc3-1ubuntu4 failed to install/upgrade: trying to overwrite `/usr/share/doc/libgimp2.0/README', which is also in package libgimp2.0" [Undecided,New] 
[05:03] <Kopfgeldjaeger> pitti: hum, i can only encrypt the whole hard disk with the daily alternate cd (qemu), if i try to manage my partitions myself, it tells me that i dont have chosen a root file system (i chose this "encrypt" option)
[05:04] <doko> Hobbsee: lookling
[05:04] <doko> Hobbsee: looking
[05:04] <Hobbsee> cool :)
[05:04] <soren> pitti: You say apport strips off the path... How does that work, actually? It uses gdb to generate the backtraces, I assume. Can you pass a special argument to gdb to pull that off?
[05:06] <pitti> soren: no, gdb doesn't support it, otherwise I would have used it; I just do it manually
[05:06] <pitti> soren: i. e. get the gdb stack trace and augment it with the environments of the source file
[05:06] <soren> pitti: Ah, clever, clever.
[05:07] <soren> pitti: I just noticed the -d option to gdb, and thought that might do something like that.
[05:07] <pitti> soren: I don't remember any more what was wrong with it
[05:08] <pitti> speaking about ugly hacks:
[05:08] <soren> pitti: It probably doesn't strip stuff of, just looks in a different place.
[05:08] <pitti> seb128: http://people.ubuntu.com/~pitti/tmp/12_vfat_no_free_space.patch
[05:08] <pitti> seb128: can you have a quick look on it? my gnome vfs fu is quite weak (as well as which strings I have to free, etc.)
[05:08] <pitti> I'm not proud of it, but it avoids the hang
[05:09] <soren> O.O
[05:09] <cjwatson> could somebody have a look at bug 134404 and see what they think of my suggested patch?
[05:09] <ubotu> Launchpad bug 134404 in mbr "mbr ftbfs" [High,Confirmed]  https://launchpad.net/bugs/134404
[05:09] <pitti> oooh!
[05:09] <cjwatson> pitti: gnomevfs> tab-damage, for starters
[05:09] <mjg59> cjwatson: Did you make any changes to partman to fix the HFS+ resize refusal problem?
[05:10] <cjwatson> mjg59: remind me of the bug number?
[05:10] <cjwatson> I don't think so, though
[05:10] <mjg59> Urgh. Bug number.
[05:11] <cjwatson> the (possibly cleaner, but more effort) alternative to my mbr patch is to fix the testsuite to spot vm86 ENOSYS and bail out silently somehow
[05:11] <cjwatson> or implement a do-we-have-vm86 helper program
[05:11] <mjg59> Why's it being built in a 32-bit chroot?
[05:12] <mjg59> There's the potential for other things to break in the same way
[05:12] <cjwatson> mjg59: because our i386 buildds are really amd64, since I assume that's just what sysadmin had handy
[05:12] <cjwatson> I know, but
[05:12] <mjg59> Eh. The buildds are broken :)
[05:12] <cjwatson> the amount of stuff that calls vm86 during builds has got to be tiny
[05:12] <lamont> pitti: since you love syncing from incoming, please sync bind9_1:9.4.1-P1-3 from incoming, so that doko will be happy again.  If you require a bug, please make doko file it. love y'all. kthxbye
[05:12] <cjwatson> I think it's OK to work around the odd few
[05:12] <mjg59> Yeah, but it's also valid for it to
[05:13] <cjwatson> IMO it's perfectly valid to try to build stuff in 32-bit chroots
[05:13] <cjwatson> we certainly don't even begin to document that you can't
[05:13] <mjg59> Well, no, because they don't have the full set of functionality provided by the architecture
[05:14] <mjg59> There are other cases where things can blow up - the kernel still doesn't implement all the compatibility ioctls properly
[05:14] <lamont> mjg59: those would be kernel bugs.
[05:14] <mjg59> lamont: Yes, but nevertheless
[05:14] <doko> mdke: did you see my email about the duplicated .xml files in ubuntu-docs?
[05:14] <lamont> and besides, cjwatson said "try", which we all know means that failure is perfectly acceptable.
[05:14] <mjg59> Ha
[05:15] <doko> seb128: is evolution-data-server somewhat special, that it doesn't build anymore once you did build the package?
[05:15] <carlos> pitti: do you have time to talk with asac and me  at #ubuntu-mozillateam ?
[05:15] <lamont> doko: it better not be
[05:15] <cjwatson> mjg59: since all our builds are done this way, it seems to me that we must already know about all the problem
[05:15] <cjwatson> s
[05:15] <pitti> carlos: I'm quite busy ATM, but I'll lurk
[05:15] <cjwatson> because we're already encountering them all
[05:15] <cjwatson> it's not like they're going to be hidden ...
[05:15] <carlos> pitti: ok, thanks
[05:15] <mjg59> cjwatson: Assuming that there isn't stuff in universe where nobody's noticed the breakage :)
[05:15] <sladen> mjg59: event = "ibm/hotkey HKEY 00000080 00001011\n\0000\004\b=\0002%\000\000\000\000\000\000\000\000\020<H=t0\004\b\030\017l\025\031\205c\t \004\bH<\vL\a\031D=4P\024\000\231\234\030@o\214<\224P<Od<", '\0' <repeats 12 times>, "/\214<p=C\001\005\000"...
[05:16] <mjg59> sladen: Looks broken to me
[05:16] <cjwatson> mjg59: and in any case it's entirely moot because there's no chance of rearranging the buildds now before release, so we have to fix this *anyway*
[05:17] <lamont> mjg59: that's a corollary to there being stuff in universe.
[05:17] <mjg59> Well, "fix" - it disables a chunk of the test harness (which I'm happy to admit isn't likely to cause any problems)
[05:17] <cjwatson> sure, I should have said work around
[05:17] <lamont> mjg59: it could conditionally disable based on the platform...
[05:17] <cjwatson> lamont: err, it does
[05:18] <lamont> linux64 uname -m _should_ work, no?
[05:18] <mjg59> lamont: The only place it can run is on real i386
[05:18] <cjwatson> *blink* hadn't thought of that. is that a good idea in general?
[05:18] <lamont> uh... nfc.
[05:18] <cjwatson> it seems, um, a more exciting solution
[05:19] <cjwatson> what does linux64 do on real i386?
[05:19] <mjg59> cjwatson: the lm flag will be present even in an i386 kernel running on a 64-bit CPU, no?
[05:19] <cjwatson> nothing much, apparently
[05:19] <cjwatson> mjg59: hmm, good point
[05:19] <kylem> mjg59, ye.
[05:19] <cjwatson> so linux64 is actually better
[05:19] <mjg59> Yeah
[05:19] <lamont> oh, and we can drop linux32 from main and/or seeds
[05:19] <cjwatson> kerazy
[05:19] <cjwatson> lamont: feel free to edit the supported seed
[05:20] <cjwatson> lamont: do I need any kind of special build-dep to get linux64?
[05:20] <kylem> wtf, why are we renaming it?
[05:20] <lamont> uname -m; linux64 uname -m
[05:20] <lamont> i686
[05:20] <lamont> i686
[05:20] <kylem> people probably have scripts which depend on this. ;-)
[05:20] <lamont> kylem: util-linux 2.13 Conflicts/Replaces/Provides linux32
[05:20] <cjwatson> kylem: we're not renaming it, it's borged into u-l
[05:21] <lamont> so depends: linux32 is fine
[05:21] <kylem> er, but now seems to be linux64 instead of linux32? :)
[05:21] <lamont> versioned depends? not so much
[05:21] <lamont> nah
[05:21] <cjwatson> kylem: linux64 != linux32
[05:21] <lamont> two different binaries
[05:21] <lamont> linux32 ==> make me 32 bit
[05:21] <lamont> linux64 ==> make me my native arch
[05:21] <cjwatson> well, two different symlinks to the same binary that looks at argv[0] 
[05:21] <kylem> ugh, that's poorly named.
[05:22] <lamont> I just accidentally hijacked it.  I didn't write it
[05:22] <kylem> lamont, it'sok, i'll blame you anyways
[05:22] <lamont> ok
[05:22] <kylem> ;-P
[05:22] <lamont> (and util-linux also Replaces: sparc-utils, just not completely)
[05:23] <lamont> and maybe as early as hardy, we'll Replaces: e2fsprogs
[05:23] <cjwatson> lamont: you're getting the fsck wrapper
[05:23] <cjwatson> ?
[05:23] <lamont> 2.14 will
[05:23] <lamont> and e2fsck
[05:23] <cjwatson> I have a truly ancient bug about that
[05:23] <cjwatson> moving e2fsck out of e2fsprogs doesn't sound like a good idea
[05:23] <lamont> and all fs probing code
[05:23] <lamont> maybe that's not moving
[05:23] <cjwatson> I'd go so far as to say brain-dead
[05:24] <cjwatson> moving fsck out is good though
[05:24] <cjwatson> though the Hurd folks will hate you
[05:24] <lamont> what? both of them?
[05:24] <lamont> there are even fewer hurd users than there are ubuntu/hppa users
[05:24] <cjwatson> lamont: see Debian #111651 for "how to get fsck into a new Essential package safely" fun
[05:24] <ubotu> Debian bug 111651 in e2fsprogs "fsck: split out from e2fsprogs?" [Wishlist,Open]  http://bugs.debian.org/111651
[05:24] <lamont> cjwatson: ah, joy.  I will care about that one, I expect.
[05:25] <lamont> otoh, util-linux is already essential
[05:25] <cjwatson> it is, which may help
[05:25] <cjwatson> I haven't thought about it carefully
[05:25] <lamont> I haven't thought about it more than 2 seconds
[05:25] <lamont> (as in, right now)
[05:25] <cjwatson> the thing you need to ensure is that fsck (and e2fsck) are *always* there
[05:25] <lamont> right
[05:26] <lamont> kylem: linux64 as a name makes sense on 64-bit arch.  on 32bit arch, it's a no-op.  one could argue that not failing is either a feature or a bug.
[05:28] <cjwatson> lamont: if we start using it to test the *real* architecture, it can't be made to fail
[05:28] <lamont> right
[05:28] <lamont> I don't see the success being changed
[05:30] <cjwatson> ok, another attempt in bug 134404
[05:30] <ubotu> Launchpad bug 134404 in mbr "mbr ftbfs" [High,Confirmed]  https://launchpad.net/bugs/134404
[05:36] <seb128> doko: what do you mean? it doesn't build twice in a row? that would be a bug, there was a Debian discussion about that recently and quite some packages are buggy in that regard
[05:36] <seb128> pitti: looking
[05:37] <pitti> wb seb128
[05:44] <seb128> pitti: the patch looks fine to me
[05:44] <pitti> FSVO "fine", but it's better than the current state, I think
[05:45] <pitti> seb128: ok, uploading; let's give this a whirl
[05:48] <doko> seb128: do you think it's worth to symlink the duplicate .png files in evolution?
[05:49] <Riddell> doko: wasn't there a licence problem with icedtea that was stopping it from being uploaded?
[05:50] <doko> Riddell: cjwatson is reviewing the upload, b21 did resolve most of the outstanding problems, the outstanding header problems are mentioned in the copyright
[05:51] <Riddell> ok, good luck :)
[05:51] <seb128> pitti: it's not a patch for upstream so I'll no start discussing declaration in the middle of the code which break on C89 compilers, I expect we will get no ubuntu bug about that (upstream does though) ;)
[05:52] <pitti> seb128: right
[05:52] <seb128> pitti: no, otherwise the patch looks good to do the job it's supposed to do ;)
[05:52] <pitti> seb128: I fully expect to drop it in hardy again, once the kernel bug will get fixed
[05:52] <seb128> doko: how much space does that win? How much do we still need?
[05:52] <seb128> pitti: right
[05:54] <lamont> (rather than the sftp:// that is)
[05:54] <Riddell> evand: what's the right branch for ubiquity? ~ubuntu-core-dev or ~ubuntu-installer ?
[05:54] <doko> seb128: I have to check, but are symlinks to -png unsafe? I think if you ask pitti: it's still not enough =)
[05:55] <evand> Riddell: ubuntu-installer
[05:55] <lamont> doko: as you should have noticed, 9.4.1-P1-3 uploaded to debian, needs a sync to ubuntu
[05:55] <evand> That's temporary while I'm not in core-dev, so I can do releases.
[05:55] <mathiaz> lamont: bzr+ssh:// may be ?
[05:55] <lamont> ah.  ssh+bzr didn't work. :-)
[05:55] <seb128> doko: for documentation? dholbach said it doesn't work
[05:56] <pitti> mathiaz: so the current 2.1 userspace tools do not work with the 2.0.1 kernel?
[05:57] <mathiaz> pitti: well. Not the parser.
[05:57] <Riddell> evand: recond I'd be elite enough to join the ubuntu-installer team?
[05:57] <seb128> doko: <Nafallo> dpkg: error processing /var/cache/apt/archives/gimp_2.4.0~rc3-1ubuntu5_i386.deb (--unpack): trying to overwrite `/usr/share/doc/libgimp2.0/README', which is also in package libgimp2.0
[05:57] <Riddell> s/d//
[05:57] <mathiaz> pitti: you'll get invalid protocol error messages.
[05:58] <evand> Riddell: hrmm, I don't know.  Apply and I'll consider it ;)
[05:58] <mathiaz> pitti: however the utils (like genprof, logprof) work well.
[05:58] <Riddell> evand: "Subscription request pending approval."
[05:58] <doko> seb128: bug 148985
[05:58] <ubotu> Launchpad bug 148985 in gimp "package gimp 2.4.0~rc3-1ubuntu4 failed to install/upgrade: trying to overwrite `/usr/share/doc/libgimp2.0/README', which is also in package libgimp2.0" [Undecided,Fix released]  https://launchpad.net/bugs/148985
[05:58] <mathiaz> pitti: so I just swaped the parser code with the old one and updated the profiles to not use the new capabilities (like network and k permissions).
[05:58] <doko> dholbach: what do you mean by "for documentation?"
[05:59] <pitti> mathiaz: right, makes sense; the kernel messages look totally different
[05:59] <seb128> doko: ok, thanks
[05:59] <mathiaz> pitti: the kernel messages are correctly handled by the log parsing tools.
[05:59] <evand> Riddell: approved
[05:59] <mathiaz> pitti: upstream tries to be backward compatible.
[06:00] <SLaPoet> can someone tell me how to handle forwarding a bug upstream with Launchpad? should it be closed in launchpad? it's more a feature request.https://bugs.edge.launchpad.net/ubuntu/+source/virtualbox-ose/+bug/148784
[06:00] <ubotu> Launchpad bug 148784 in virtualbox-ose "[gutsy]  virtualbox does not configure usb devices" [Undecided,New] 
[06:00] <Riddell> evand: ooh, thanks
[06:00] <lamont> cjwatson: could you check to see if hppa ISO building works yet?  (server stands a small chance, alternate less so, live no way in hell)
[06:00] <kylem> er.
[06:01] <kylem> why?
[06:01] <dholbach> doko: I tried replacing duplicates in gnome-user-docs, the pictures did not show up in localized help
[06:01] <Riddell> evand: what's the ubuntu-core-dev branch for?
[06:01] <lamont> kylem: livecd to a CLI, not to running gnome
[06:01] <dholbach> doko: http://daniel.holba.ch/temp/gnome-user-docs.diff
[06:01] <lamont> lazy-man's recovery CD
[06:02] <evand> Riddell: I think we're eventually going to switch back to that.  cjwatson seems to be keeping it in sync.
[06:03] <sladen> SLaPoet: file the bug upstream, add the upstream bug URL as an upstream tracker;  and launchpad will then (after 24hours) poll the status upstream
[06:04] <cjwatson> Riddell: evand is correct
[06:05] <sladen> SLaPoet: the situation you'll have is  (1) bug exists in foo (Ubuntu);  (2) bug exists in foo (Ubuntu) and foo (upstream), URL = ...  (3) bug exists in foo (Ubuntu), bug fixed in foo (upstream)  (4) bug committed/fix in both  foo (Ubuntu) and foo (upstream)
[06:05] <evand> Is there a trick to installing tasks inside pbuilder, specifically getting past xorg?
[06:05] <mjg59> sladen: Of course, having built it with debugging, I can't get the damn thing to crash
[06:05] <Riddell> evand: rm the postinst?
[06:06] <doko> dholbach, seb128: just a thinko in the patch, should work after the fix
[06:06] <Riddell> oh, pbuilder, not chroot
[06:06] <dholbach> doko: great, thanks for looking into it
[06:06] <evand> well, it is a chroot when you use --login, right?
[06:06] <evand> Riddell: I'll try that though, thanks
[06:07] <pitti> doko, lamont: bind synced
[06:07] <cjwatson> lamont: I've added hppa to cron.ports_daily again and have kicked off a new build. from here on you can check at http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/
[06:07] <lamont> thank you
[06:08] <lamont> both
[06:08] <SLaPoet> sladen: thanks i'll check it out.
[06:08] <sladen> mjg59: something shortly after   else if (strncmp (acpi_path, "battery", sizeof ("battery") - 1)   craps on the stack
[06:09] <mjg59> sladen: Yeah. With debugging symbols, I seem to be able to handle battery events fine
[06:09] <doko> pitti: http://people.ubuntu.com/~doko/tmp/cupsys.debdiff
[06:10] <sladen> mjg59:  dbus_error_free (&error);
[06:11] <pitti> doko: thanks, I'll check it in
[06:12] <iwj> doko: autopkgtest's oo.o build failed because it timed out after 100ks.  Is it really supposed to take that long ?
[06:12] <pitti> doko: if you actually upload that, it'll be rejected (1ubuntu3 should be current), just FYI
[06:12] <mjg59> sladen: Hm. Ok, there's a potential double free there, I guess
[06:12] <mjg59> Though I thought dbus_error_free was smart about that
[06:12] <iwj> (100ks =~ 27.8h)
[06:12] <doko> iwj: which arch?
[06:12] <iwj> doko: amd64
[06:12] <doko> iwj: strange, the build did succeed on the buildd
[06:13] <iwj> doko: Maybe the buildd has a longer timeout.
[06:13] <elmo> the buildds timeout on inactivity
[06:13] <elmo> if you're spewing stuff to the log, they'll keep going indefinitely
[06:13] <sladen> mjg59: it's not going to be free itself, but the attempted recursive free (?) of whatever crap was left inside that structure
[06:14] <iwj> doko: Also:
[06:14] <iwj> -rw-r--r-- 1 iwj warthogs 3.7G 2007-10-04 08:28 log
[06:14] <iwj> That's the build log.
[06:14] <iwj> Surely that can't be normal ?
[06:14] <doko> iwj: Finished:  	 2007-09-28  (took 5 hours 20 minutes)
[06:14] <mjg59> sladen: Hmm, no, that would only happen on shutdown
[06:14] <iwj> doko: Millions of lines like
[06:14] <iwj> ERROR: No Fallback found for language en-US:
[06:14] <doko> iwj: interesting log file, what's in there?
[06:15] <mjg59> sladen: Only other thing I can think of is that there's no explicit init at the beginning of the loop
[06:15] <mjg59> But I can't see the codepath that would result in it being inappropriately freed
[06:15] <tkamppeter> pitti, I have put up a new hplip (2.7.7.dfsg.1-0ubuntu4), as the previous one only fixed the problem for privileged users (bug 147369).
[06:15] <ubotu> Launchpad bug 147369 in hplip "MASTER: Printing via HPLIP does not work any more" [High,Fix released]  https://launchpad.net/bugs/147369
[06:15] <iwj> doko: Seems to be output from eg
[06:15] <doko> iwj: that's the export of the language data, which we only do on i386. so maybe this is a bug
[06:15] <iwj> localize -e -l en-US,as-IN -f /root/adt-downtmp/dsc0-build/openoffice.org-2.3.0/debian/l10n/export/GSI_as-IN.sdf
[06:16] <iwj> localize -e -l en-US,as-IN -f /root/adt-downtmp/dsc0-build/openoffice.org-2.3.0/debian/l10n/export/GSI_as-IN.sdf
[06:16] <iwj> Oops, sorry.
[06:16] <iwj> doko: I'll copy the log to chinstrap.
[06:17] <sladen> mjg59: you need to call the same  dbus_error_init()/libhal_device_rescan()  that all the other cases are using  (which could be moved outside)
[06:17] <pitti> soren: eww; there is no /conf/conf.d/cryptroot any more; siretart, any idea? did that break with the Debian merge?
[06:17] <mjg59> sladen: It is?
[06:17] <doko> calc: ^^^
[06:17] <tkamppeter> pitti, the ususal e-mail
[06:17] <iwj> doko: Looks like the webserver can't cope with large files.
[06:17] <pitti> tkamppeter: ok
[06:18] <doko> iwj: well, maybe just file a bug report, with an excerpt where it starts with these messages
[06:18] <sladen> mjg59: the double free can be discounted as that would only occur on fgets() == 0
[06:18] <iwj> elmo: Is there a sane way to copy a 3.7G file from cadmium to chinstrap ?  My rsync says it will take 3-4h.
[06:18] <mjg59> sladen: Yes, that's what I said earlier
[06:19] <tkamppeter> pitti, I hope with this Gutsy's printing subsystem is completed.
[06:21] <cjwatson> iwj: won't it bzip2 brilliantly?
[06:21] <elmo> iwj: cadmium to chinstrap should be GB, combined with even normal ssh compression, it shouldn't take anything like that long
[06:22] <elmo> (but yes, bzip2 would be another work around)
[06:22] <cjwatson> mvo: do you think we could fix bug 149018 for RC?
[06:22] <ubotu> Launchpad bug 149018 in gnome-app-install "stop depending on app-install-data-commercial" [Undecided,New]  https://launchpad.net/bugs/149018
[06:22] <iwj> elmo: Oh, it seems to have sorted itself out and decided it's only going to take another 2-3 _minutes_.
[06:22] <ion_> CUPS avahi support is so awesome. I plugged a laptop to the network (with a shared printer connected to the desktop machine), clicked print and it Just Worked.
[06:23] <iwj> cjwatson: Yes, but IME on local networks compressing files before copying them is a waste of time.
[06:23] <sladen> mjg59: dbus_free (real->name)
[06:24] <iwj> doko: bug 149021, thanks.
[06:24] <ubotu> Launchpad bug 149021 in openoffice.org "autopkgtest build took >100ks, generated 3.7G logfile" [Undecided,New]  https://launchpad.net/bugs/149021
[06:24] <sladen> mjg59: so it's the attempted access, with the candlestick, in the library
[06:24] <iwj> doko: NB there are a couple of things that seem to make autopkgtest often fail for slightly buggy packages: 1. it doesn't run debian/rules clean before building; 2. the build has no controlling terminal.
[06:25] <mjg59> sladen: I'm still not seeing how dbus_error_free ever gets called without an error_init
[06:26] <avoine> Someone know what the ^ do in apt-get? i.e apt-get install minimal^
[06:26] <iwj> doko: chinstrap:~iwj/log has arrived FYI
[06:26] <sladen> mjg59: error is never initialised;  error shows a false positive of being set at dbus_error_is_set();  error is freed
[06:27] <cjwatson> avoine: install task
[06:27] <sladen> mjg59: should happen in all cases where  event == ibm/hotkey, or event == unknown.  /shouldn't/ (needs verifying) in the case of even == ac_adapter or event == battery
[06:27] <bdmurray> Keybuk: I saw you fixed 129612 - what would be a good test case for it?
[06:27] <cjwatson> avoine: i.e. install all packages with Task: minimal
[06:27] <avoine> ok thx cjwatson
[06:28] <Keybuk> bdmurray: boot with break=top
[06:28] <mvo> cjwatson: sure
[06:28] <mjg59> sladen: I thought you said it happened through the battery path?
[06:28] <Keybuk> does it say "can't access tty; job control turned off"
[06:28] <Keybuk> :)
[06:28] <tkamppeter> Anyone suffering bug 121566?
[06:28] <ubotu> Launchpad bug 121566 in network-manager "no network with dhcp set up" [Critical,Confirmed]  https://launchpad.net/bugs/121566
[06:28] <bdmurray> I figured it was quite easy but wasn't sure which kernel boot option would be best.
[06:29] <cjwatson> mvo: I'll munge the seeds
[06:29] <siretart> pitti: err, ups?
[06:29] <mvo> cjwatson: cool, thanks
[06:30] <cjwatson> mvo: I trust gnome-app-install doesn't really depend on app-install-data-commercial internally?
[06:31] <sladen> mjg59: I think it's hitting  METHOD UCMS  and dying on that first   (acpi_listen and yank cable)
[06:32] <mjg59> Ok, plausible
[06:33] <mvo> cjwatson: no, it was just added so that the data gets imported
[06:33] <mvo> cjwatson: eh, that the package would land on the CD etc
[06:33] <cjwatson> mvo: right
[06:34] <cjwatson> mvo: I've made it a Recommends of ubuntu-desktop; kubuntu-desktop didn't have it anyway (which might or might not be a bug?); I'll add it to Edubuntu and Xubuntu (and the Xubuntu people can take it out if they want)
[06:35] <sladen> mjg59: simplist fix should be   error == NULL;  at the top of the function
[06:36] <mvo> cjwatson: I think initially adept did not support it, so it was not added. I'm not sure about the current state of affairs though
[06:36] <mvo> cjwatson: that sounds appropriate, thanks
[06:38] <mjg59> sladen: Do you mean memset it?
[06:38] <mjg59> It's a struct, not a pointer
[06:40] <mjg59> sladen: Just make sure it's been through dbus_error_init() in every path
[06:40] <sladen> mjg59: including the no-match case
[06:40] <mjg59> Yes
[06:42] <sladen> mjg59: should be able to stick it on line 196 just before the glorified switch statement
[06:43] <mjg59> Yes
[06:43] <mjg59> Want to do that and see if it works?
[06:44] <sladen> mjg59: In progress
[06:45] <mjg59> Cool
[06:48] <pitti> tkamppeter: eww, 666 for /dev printer devices? that sounds wrong
[06:49] <pitti> tkamppeter: the user is not supposed to directly talk to those devices; only the daemon should do that
[06:54] <cjwatson> evand: whoa, nobody had merged the gobuntu seeds in ages. that can't be helping
[06:54] <evand> oh, I had intended to point that out to you
[06:54] <evand> uh, whoops?
[06:55] <cjwatson> not sure if it's the cause of your problem, but ...
[06:55] <evand> worth a shot
[06:56] <evand> want me to take care of it and then point you at the branch, or is it something that would be done significantly quicker by you?
[06:56] <cjwatson> evand: I've just done it :)
[06:57] <evand> heh
[07:00] <tkamppeter> pitti, about HPLIPs permissions for /dev files. They need to be 666 so that normal users can use the hp-toolbox.
[07:00] <pitti> tkamppeter: doesn't that talk though the hplip daemon?
[07:01] <pitti> world-writeable USB device nodes is just plain wrong
[07:01] <tkamppeter> pitti, the HPLIP daemons were removed with the last HPLIP 2.7.7 (generation "2").
[07:01] <mjg59> tkamppeter: 666 device nodes really aren't acceptable
[07:01] <pitti> even root:lpadmin 660 is evil enough
[07:02] <tkamppeter> pitti, hp-toolbox is run by a normal user and seems to start hpssd which in turn accesses the /dev files.
[07:02] <pitti> tkamppeter: the better fix then is (IMHO) to change the .desktop file to call it as root
[07:02] <pitti> eww
[07:02] <tkamppeter> pitti, so you thing the GUIs of HPLIP should run SUID root?
[07:03] <pitti> no, I don't think they should
[07:03] <pitti> they should talk to a sane daemon which manages the devices, locking, etc.
[07:03] <cjwatson> 666 device nodes are just plain negligent, IMO
[07:03] <cjwatson> I'm sorry, but ...
[07:03] <tkamppeter> Perhaps we make hpssd SUID root so that it can access root.root 600 /devs. Should I do it this way?
[07:03] <kylem> 666 device nodes are a security nightmare.
[07:03] <pitti> tkamppeter: no, that would be even worse
[07:04] <cjwatson> 660 + setgid <pick a group>?
[07:04] <pitti> tkamppeter: do we need the hp toolbox for installing and using the printer at all, and do we install it by default?
[07:04] <cjwatson> though that isn't great either
[07:04] <pitti> lpadmin, if we need a group
[07:04] <pitti> oh, no, "lp'
[07:04] <pitti> lp is the group which the device nodes should have
[07:05] <tkamppeter> pitti. hp-toolbox is a convenient feature for users to see ink levels, clean nozzles, see status, ... provided by HP and now users want to use it.
[07:05] <pitti> so it's at least not essential
[07:05] <tkamppeter> pitti, so then I have two solutions:
[07:05] <kylem> keescook, heh.
[07:06] <pitti> we just cannot confine execution to group lpadmin *and* make it setgid lp
[07:06] <tkamppeter> 1. (my preferred): lp.lp 660 permissions for /dev files and hpssd running SGID "lp"
[07:06] <ubotu> Launchpad bug 660 in launchpad "Awful workflow for adding new email addresses." [Medium,Fix released]  https://launchpad.net/bugs/660
[07:07] <tkamppeter> uboto, shut up!
[07:07] <pitti> heh
[07:07] <pitti> (and root:lp)
[07:08] <Kmos> keescook: can you check bug 138819
[07:08] <ubotu> Launchpad bug 138819 in wordpress "wordpress 2.2.3 is out: security release" [High,Confirmed]  https://launchpad.net/bugs/138819
[07:09] <tkamppeter> 2. Say "Sorry, asking ink levels, cleaning nozzles, polling status, scanning with MF device are dangerous actions done by a normal user, they should be reserved to admins" to the reporter of bug 147369 and closing it with "Wontfix"
[07:09] <ubotu> Launchpad bug 147369 in system-config-printer "MASTER: Printing via HPLIP does not work any more" [Undecided,Invalid]  https://launchpad.net/bugs/147369
[07:09] <keescook> Kmos: sure, in a bit, I'm working on OOo and a few others at the moment.  Is there a merge diff in that bug?
[07:09] <pitti> tkamppeter: I think for now it would be better to fix the .desktop file and run it through gksu; keescook, WDYT?
[07:09] <pitti> and keep the device nodes as root:root or root:lp
[07:09] <Kmos> keescook: nop.. but there is a backport request of it.. isn't better?
[07:09] <Kmos> bug 141097
[07:09] <ubotu> Launchpad bug 141097 in feisty-backports "Please backport wordpress from Gutsy" [Undecided,Incomplete]  https://launchpad.net/bugs/141097
[07:10] <Kmos> for feisty
[07:10] <cjwatson> backports are NOT a substitute for security updates
[07:10] <keescook> Kmos: for gutsy, it should be okay.  for feisty, I'll leave that to someone else -- it's a lot of work.
[07:10] <cjwatson> they will generally be rejected if that's their only purpose
[07:10] <tkamppeter> pitti, this would mean that all HP GUI tools should ask for the privileged user password (and should be moved into "System"/"Admin" menu)?
[07:10] <keescook> pitti: just so I understand, it's only a single app that needs root privs?
[07:10] <tkamppeter> So this is 2. of my solutions?
[07:10] <pitti> tkamppeter: I'm not happy with that solution, but fixing it properly is something that upstream should do
[07:10] <pitti> keescook: it's the first time I hear about this either :/
[07:10] <Kmos> cjwatson: in this case, it will bring new features and fix a lot of bugs (including security ones)
[07:11] <Kmos> for feisty =)
[07:11] <keescook> pitti: yeah, was reading the backlog...
[07:11] <cjwatson> Kmos: then perhaps it should not be rejected, but it is still not a substitute for a security update. remember that many users legitimately do not have backports enabled (indeed, that's our default)
[07:11] <tkamppeter> pitti, note that users are also not able to print according to bug 147369.
[07:11] <Kmos> cjwatson: yeah.. i understand your point of view
[07:11] <ubotu> Launchpad bug 147369 in system-config-printer "MASTER: Printing via HPLIP does not work any more" [Undecided,Invalid]  https://launchpad.net/bugs/147369
[07:12] <cjwatson> Kmos: it is a policy statement, not a point of view :-)
[07:12] <Kmos> cjwatson: yeah
[07:12] <Kmos> today updates
[07:12] <keescook> pitti: for that dev node, I'd say it's a toss-up for gksu vs setgid (lp) tool.  I too, lean towards the "ask for password" method.
[07:12] <pitti> tkamppeter: that was the bug your upload was supposed to fix, right?
[07:12] <pitti> tkamppeter: however, I don't understand this
[07:12] <pitti> tkamppeter: isn't this run as a normal cupsys backend?
[07:13] <pitti> tkamppeter: and, as such, as group 'lp' or 'root', depending on the backend permissions?
[07:13] <pitti> neither of those modes requires world permissiosn
[07:13] <Kmos> http://pastebin.com/d55e541a4
[07:13] <Kmos> this is normal ?
[07:14] <tkamppeter> pitti, I think the design problem of HP is that a call of hp-toolbox starts hpssd and then hpssd runs as the calling (unprivileged) user. hpssd stays running until a long timeout expires. So when the user printes afterwards CUPS will use the hpssd which was started by the user. And worse even if user A has triggered hpssd and afterwards user B accesses the device everything goes through user A's hpssd. So a very bad design by HP.
[07:14] <cjwatson> Kmos: bug 146832
[07:14] <ubotu> Launchpad bug 146832 in ubuntu-docs "ubuntu-docs: undefined "&rsquo;" in /usr/share/omf/windows/windows-C.omf" [Undecided,Fix committed]  https://launchpad.net/bugs/146832
[07:14] <Kmos> cjwatson: thanks
[07:14] <keescook> omfg.
[07:14] <pitti> one would thing that the HP guys would know something about software design *sigh*
[07:15] <mjg59> tkamppeter: What prevents someone launching their own hpssd and intercepting people's printing information?
[07:15] <tkamppeter> So to get a little better security having hpssd running always as a non-root neutral user I suggest to set it SUID "lp" and SGID "lp".
[07:15] <pitti> tkamppeter: then, since I guess you don't fancy rewriting this crack in a night, I think the 'run the tool through gksu' is the least evil thing
[07:16] <keescook> besides hp-toolbox, what calls hpssd ?
[07:16] <tkamppeter> pitti, then we take scanning away from normal users.
[07:16] <pitti> first, samsung's printer driver makes openoffice setuid root; now hplip makes printers world-hackable; what next?
[07:16] <keescook> lp: printer on fire.
[07:16] <tkamppeter> keescook everything which accesses HP devices: Printing, Scanning, photo download, ...
[07:16] <pitti> tkamppeter: well, that might be, but that's not something we can fix quickly
[07:17] <pitti> tkamppeter: doesn't the cupsys backend spawn a hpssd, too?
[07:17] <tkamppeter> pitti, thanks for that. I will iunform Samsung immediately about that security hole. Why are users switching from Windows to Linux?
[07:17] <keescook> tkamppeter: I want to understand which tools would spawn hpssd (as the wrong user).  sounds like hp-toolbox and (I'm guessing) cupsd.  Are there others?
[07:18] <pitti> tkamppeter: oh, that was a long time ago, and Samsung fixed it in the meantime
[07:18] <pitti> tkamppeter: it just took a lot of bug ping pong to actually find that out :)
[07:19] <pitti> keescook: since the cups backend runs either as root or lp, that one should be fine
[07:19] <keescook> pitti: right, but are there others?
[07:19] <tkamppeter> keescook, everything HPLIPish is spawning hpssd and the first caller wins, he is the owner of hpssd. Therefore I suggest running hpssd SUID "lp", so that no user can impose his personal rights onto it.
[07:20] <pitti> hm, what about:
[07:20] <pitti> tkamppeter: hm, when cupsys starts up, it won't start the backend, right?
[07:20] <pitti> tkamppeter: what about starting hpssd in an init script then?
[07:20] <pitti> argh, it'll time out, right?
[07:21] <keescook> the reason for not making hpssd setgid lp is that it's an unaudit GUI tool that may give people "lp" group perms accidentally.  We're weighing this chance against the inconvience of prompting for a password.
[07:21] <pitti> damn, this stuff is FUBAR
[07:21] <calc> iwj: what is the main difference between the way you build and the buildds?
[07:21] <tkamppeter> pitti, keescook, making hpssd SUID "lp" is no additional risk, as when a user prints it is run as "lp" anyway. So users are generally allowed triggering selected programs as "lp" and hpssd is already selected.
[07:22] <keescook> tkamppeter: I don't know what tools are "HPLIPish", can you provide a list of the binaries?  so far it is cupsys, hp-toolbox.
[07:22] <pitti> tkamppeter: with the difference that the user can control hpssd's invocation when he starts it directly
[07:22] <iwj> calc: Err, I'm not sure there is a "main difference".  There are a few differences which occasionally cause trouble.
[07:22] <tkamppeter> pitti, you are right, hpssd will time out and so starting it from an init script is no real protection.
[07:22] <pitti> (i. e. set environment variables, pipe stuff into it, etc.)
[07:22] <iwj> calc: The top one I suppose is that I don't do  debian/rules clean  first.
[07:22] <iwj> calc: And the next one after that is that I'm a bit stricter about build-deps being unambiguous.
[07:23] <pitti> tkamppeter: I think if we limit operation to lpadmins (i. e. the first user by default), it's not a too bad restriction for gutsy
[07:23] <pitti> erm, I mean admins
[07:23] <iwj> calc: Is this apropos of the oo.o build failure ?
[07:23] <pitti> tkamppeter: and ask HP to fix their stuff
[07:23] <tkamppeter> pitti, should we perhaps make an AppArmor profile for HPLIP, so that hpssd can only be started by HPLIP tools, CUPS, and SANE and not directly?
[07:23] <calc> iwj: yea i am trying to determine why it would get forever on your build but not on the buildds
[07:23] <iwj> calc: Other things that have caused trouble in the past include lack of a controlling tty and setting TMPDIR (would you believe some packages can't cope if you do).
[07:24] <pitti> tkamppeter: that would be tricky, and not appropriate at this time of the release cycle
[07:24] <mjg59> tkamppeter: The hplip tools run as the user? That wouldn't help.
[07:24] <iwj> calc: Well, I think those millions of error messages might be related.
[07:24] <pitti> apparmor can't rescue an inherently broken design
[07:24] <norsetto> doko: you fixing gimp already?
[07:24] <iwj> calc: You could diff a normal log and the autopkgtest-generated one.  Do you have a chinstrap a/c ?
[07:25] <norsetto> doko: never mind, just saw the it, thx
[07:25] <iwj> calc: doko said it ought not to have been trying to do that locale stuff on amd64 at all.
[07:25] <calc> iwj: yes
[07:25] <tkamppeter> mjg59, the HPLIP tools run really as the calling user. And making them SUID "lp" would be tricky, as files will be created with "lp" ownership. And users could reprint files from the print queues as their own jobs,
[07:25] <mjg59> tkamppeter: Right, so that's not an option
[07:26] <pitti> soren: still here?
[07:26] <mjg59> tkamppeter: In any case, it wouldn't stop someone installing their own hpssd binary
[07:26] <mjg59> If there's nothing to prevent a user-run hpssd binary from obtaining data from other users processess, we've already lost
[07:27] <calc> iwj: i'll check it against a regular amd64 build and see what it shows
[07:27] <pitti> soren: if I manually boot that encryption/lvm system, do update-initramfs -u, I get a valid conf/conf.d/cryptroot and a bootable system
[07:27] <tkamppeter> pitti, I think HPLIP as current is a totally broken design. I will contact HP to fix it, perhaps even that they roll back to hpiod for security reasons.
[07:27] <pitti> tkamppeter: they should have a permanently running small daemon which spawns the heavy programs on demand
[07:27] <mjg59> tkamppeter: When did the design become this broken?
[07:28] <pitti> tkamppeter: thanks
[07:28] <tkamppeter> mjg59, with 2.7.7, HP's second generation of HPLIP.
[07:28] <doko> iwj: not exactly, we don't build binary-indep on amd64
[07:28] <mjg59> tkamppeter: Date-wise?
[07:28] <iwj> doko: OIC.  Maybe that's what's broken.
[07:28] <iwj> doko: That is, I do   debian/rules binary
[07:29] <tkamppeter> mjg59, July 2007. The version numbers are generation.year.month.
[07:30] <tkamppeter> pitti, mjg59 restricting HPLIP tools to privileged users wouls also mean that unpriv ileged users cannot scan on HP's MF devices.
[07:30] <calc> iwj: yea localize isn't called at all on regular amd64 build on buildds
[07:30] <mjg59> tkamppeter: Ok, which was uploaded in August. Hm. Shame we didn't notice the regressions then.
[07:30] <mjg59> tkamppeter: Well, the alternative is security nightmare, so.
[07:30] <pitti> tkamppeter: right, but I don't see any other solution ATM
[07:31] <tkamppeter> And rolling back to 1.x.x would reintroduce tons of bugs.
[07:31] <iwj> calc: And presumably on i386 it doesn't break.
[07:31] <keescook> yay, arbitrary command execution as user running hpssd via network message handling and email delivery.  this is really bad code.
[07:31] <mjg59> keescook: Oh, sweet.
[07:31] <calc> iwj: yea it works everywhere when done via buildd (i guess i386 then) i should verify it was calling localize on the i386 buildd build
[07:32] <mjg59> keescook: So, basically, we can't run hpssd ever?
[07:32] <tkamppeter> So the best solution would even be remove HPLIP from the distro, mark all HPs "Paperweight" on OpenPrinting and tell that they are a big security hole ...
[07:32] <keescook> well, perhaps this particular vuln could be fixed -- use subprocess instead of popen
[07:32] <iwj> calc: I hope you agree that it ought to work when you do binary-indep on amd64.
[07:33] <keescook> tkamppeter: I'd sure not like to do that -- there are a lot of HPs.
[07:33] <mjg59> keescook: You have any faith in there not being others?
[07:33] <keescook> mjg59: not really.  :)
[07:33] <mjg59> tkamppeter: The alternative would be to roll back to 1.7.3
[07:33] <sladen> mjg59: can you review  http://www.paul.sladen.org/ubuntu/upload/26-addon-acpi-fix-free-before-init.diff
[07:34] <pitti> well, not sure if anyone ever reviewed that...
[07:34] <keescook> mjg59: sure that version isn't vuln too?
[07:34] <calc> iwj: yea it works on i386
[07:34] <sladen> mjg59: that fixes hal;  gnome-power-manager is still broken
[07:34] <calc> iwj: well it could be very well that it is completely broken on 64bit platform or something like that, sun doesn't support amd64 at all for OOo aiui, but I will look into why it doesn't work
[07:34] <mjg59> sladen: You've got a potential use-after-free
[07:34] <tkamppeter> keescook, mjg59, pitti, can you report all security holes in HPLIP as bugs on Launchpad, then I will CC these bugs to the HPLIP people so that they can redesign their concept?
[07:35] <sladen> mjg59: where
[07:35] <mjg59>  if (libhal_device_rescan (ctx, udi, &error)) {
[07:35] <mjg59> +					if (dbus_error_is_set (&error)) {
[07:35] <mjg59> +						dbus_error_free (&error);
[07:35] <mjg59> +					}
[07:35] <mjg59> Then you use error again immediately afterwards
[07:35] <sladen> mjg59: read the comment at the end
[07:35] <keescook> (at least it's only listening to localhost)
[07:36] <mjg59> Oh, ok
[07:36] <mjg59> Yeah, looks fine
[07:36] <pitti> keescook: do you write your's about the popen? I'll write one about the daemon invocation
[07:36] <tkamppeter> So pitti, mjg59, keescook, then the solution would be:
[07:36] <mjg59> sladen: Upload that?
[07:36] <keescook> pitti: yup, sounds good.
[07:37] <keescook> pitti: btw, apparmor doesn't block this since the backend is run Ux
[07:37] <pitti> right
[07:37] <tkamppeter> 1. Leave the permissions as they are now: root.lp )or lp.lp) 0660
[07:37] <sladen> gah, how do I get rid of the docbook churn
[07:38] <keescook> do other distros ship hplip?
[07:38] <tkamppeter> keescook: Every distro ships HPLIP
[07:38] <tkamppeter> We should put up some
[07:38] <tkamppeter> global security alert
[07:38] <keescook> tkamppeter: okay, so I'll have to get a CVE for this as soon as I 'prove' to myself that it's real.
[07:38] <mjg59> sladen: g-p-m won't work properly if hal is restarted underneath it, as far as I can tell
[07:39] <tkamppeter> Back to my HPLIP solution:
[07:40] <tkamppeter> Make hpssd root.lp 770, so that only members of the "lp" group can start it
[07:40] <ubotu> Launchpad bug 770 in cryptsetup "Ask password twice on init" [Medium,Invalid]  https://launchpad.net/bugs/770
[07:40] <tkamppeter> ubotu, you have a bug
[07:40] <ubotu> Sorry, I don't know anything about you have a bug - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[07:40] <sladen> mjg59: mostly it crashes
[07:41] <tkamppeter> or better 3. Make all hplip tools root.lp 0770, so that only privileged users can run them.
[07:41] <ubotu> Launchpad bug 770 in cryptsetup "Ask password twice on init" [Medium,Invalid]  https://launchpad.net/bugs/770
[07:42] <tkamppeter> 4. How do we tell unprivileged users clearly that due to a big security hole they are not allowed to do other things than plain printing on HP devices?
[07:44] <pitti> tkamppeter, keescook: WDYT about bug 149045?
[07:44] <ubotu> Launchpad bug 149045 in hplip "needs a proper daemon or cupsys integration" [Undecided,New]  https://launchpad.net/bugs/149045
[07:45] <pitti> tkamppeter: root:lp programs are not for user invocation; no user should *ever* be in "lp"
[07:46] <tkamppeter> pitti, so then the solution is that any access toi HP devices should be made root-only
[07:46] <keescook> reads well; perhaps explicitly mention the 0777 dev nodes?
[07:46] <keescook> pitti: ^^ (re: bug report)
[07:47] <pitti> keescook: I did actually
[07:47] <keescook> ah! sorry, yes, first bullet
[07:47] <tkamppeter> pitti, for scanning one could perhaps run a saned SUID root and let users access the scanners in the HP devices by this saned.
[07:47] <pitti> tkamppeter: right; if the desktop files are correct (X-KDE-SubstituteUID=true) then they will only appear for admins who can run them
[07:48] <pitti> I'm afraid I know too little about the HP tools to give good advice how to fix them for scanning
[07:48] <tkamppeter> pitti, this works also in GNOME?
[07:48] <pitti> tkamppeter: yeah, it does; KDE had it first, so we adapted it
[07:49] <pitti> adopted, even
[07:53] <tkamppeter> pitti, mjg59, keescook: Anyone of you has a standalone scanner (no HP MF device)? How can normal users use suchg a scanner. SANE is completely running as the calling user, so it is completely insane.
[07:53] <tkamppeter> And SANE does not use daemons at all.
[07:54] <pitti> tkamppeter: scanner devices are root:scanner 0660
[07:54] <tkamppeter> pitti, and all users are in the "scanner" group?
[07:54] <pitti> the default user anyway
[07:54] <pitti> and new ones created by users-admin with the 'desktop' profile
[07:56] <tkamppeter> pitti, so we have the same security problem there.
[07:57] <pitti> tkamppeter: not quite; it does not launch any daemons other users would share, and it does not require world-readable/writable device nodes
[07:57] <tkamppeter> pitti, WDYT about making bug 147369 a duplicate of bug 149045?
[07:57] <ubotu> Launchpad bug 147369 in system-config-printer "MASTER: Printing via HPLIP does not work any more" [Undecided,Invalid]  https://launchpad.net/bugs/147369
[07:57] <ubotu> Launchpad bug 149045 in hplip "needs a proper daemon or cupsys integration" [High,Confirmed]  https://launchpad.net/bugs/149045
[07:59] <pitti> tkamppeter: not sure; can admins/lpadmins use HP printers ATM? if no, then it's not a dup
[08:00] <pitti> tkamppeter: we can hack hplip to fix (ish) 147369 while we cannot fix the root cause
[08:00] <tkamppeter> pitti, admins/lpadmins can do everything with HP devices.
[08:02] <keescook> hah, the sendmail arguments are wrong -- email notifications don't even work when NOT abused.
[08:03] <pitti> tkamppeter: oh, if that already works, then fine; how are the dev permissions right now?
[08:03] <tkamppeter> pitti, I can try to quickly find out whether hpssd really times out. If not, we run it by a startup script and give it permissions root.lp (or lp.lp) 0770 and we run it as the user "lp".
[08:03] <tkamppeter> pitti, then all users will be able to scan.
[08:04] <pitti> tkamppeter: lp.lp would be much better
[08:04] <pitti> tkamppeter: 774, btw
[08:04] <tkamppeter> And if it times out, disabling the timeout is probably a tiny unharmful patch (which I could perhaps even get quickly from HP).
[08:04] <tkamppeter> pitti, why 774?
[08:05] <pitti> tkamppeter: no reason to make it unreadable; the binary itself is not a secret
[08:05] <pitti> tkamppeter: 754, of course
[08:05] <pitti> group-writeable would be wrong :)
[08:06] <tkamppeter> pitti, yes, then normal users can security-audit it, then several users will feel much better using HPLIP.
[08:06] <pitti> it's more a question of being able to run md5sums, etc.
[08:06] <tkamppeter> pitti, you are right, 754.
[08:07] <tkamppeter> pitti, so then let the solution be:
[08:07] <tkamppeter> 1. Patch the timeout out of hpssd if it has one
[08:07] <tkamppeter> 2. Make hpssd lp.lp 0754
[08:07] <ubotu> Bug 754 on http://launchpad.net/bugs/754 is private
[08:08] <tkamppeter> 3. Leave the UDEV rules as they are: root.lp 0660
[08:08] <ubotu> Launchpad bug 660 in launchpad "Awful workflow for adding new email addresses." [Medium,Fix released]  https://launchpad.net/bugs/660
[08:09] <tkamppeter> 4. Let hpssd be started by an init script to keep it permanently running as user lp
[08:09] <pitti> tkamppeter: but then no user could run hpssd any more
[08:09] <pitti> ah
[08:09] <pitti> tkamppeter: with 4., 2. is not necessary
[08:09] <pitti> tkamppeter: the binary should be a normal root:root 0755
[08:09] <pitti> tkamppeter: and start-stop-daemon starts it as user lp
[08:10] <tkamppeter> pitti, 2. is still needed as a user could start a second instance of hpssd by hand.
[08:10] <pitti> tkamppeter: and 5. work with keescook to get the popen call fixed
[08:10] <pitti> tkamppeter: no, they can't
[08:10] <pitti> tkamppeter: they cannot access the device
[08:10] <pitti> tkamppeter: 754 is *not* suitable for preventing anyone from running an executable
[08:11] <pitti> tkamppeter: after all, you can copy it to somewhere else and run it from there
[08:11] <pitti> tkamppeter: only 4754 and 2754 makes sense (s[ug] id)
[08:12] <pitti> tkamppeter: (sorry, I misunderstood you earlier)
[08:12] <tkamppeter> pitti, you are right, so 2. is really not needed. The solution is 1, 3, 4 from above.
[08:12] <pitti> tkamppeter: right, and 5 :)
[08:12] <pitti> tkamppeter: I'm fine with that
[08:12] <pitti> tkamppeter: does the daemon continue to run if the device does not exist at all?
[08:12] <tkamppeter> pitti, is 5 really immediately needed if access to the device is restricted?
[08:13] <lamont> https://edge.launchpad.net/ubuntu/gutsy/+source/lsb/3.1-23.1ubuntu2
[08:13] <pitti> tkamppeter: yes, since the problem with popen() is not the device permissions, but that the daemon does not sanitize its input
[08:14] <pitti> tkamppeter: i. e. any user or malware sending stuff to the running hpssd could 0wn your printers, since they can run stuff as user/group 'lp'
[08:14] <tkamppeter> pitti, I do not know whether hpssd will stop on unplugging the device. Also it must be assured that an hpssd gets started on plugging the device.
[08:15] <pitti> tkamppeter: it could make sense to start the daemon from an udev rule?
[08:15] <pitti> tkamppeter: anyway, that's just an efficiency thing
[08:15] <tkamppeter> pitti, Donald Welch from HP has answered to bug 149045.
[08:15] <ubotu> Launchpad bug 149045 in hplip "needs a proper daemon or cupsys integration" [High,Confirmed]  https://launchpad.net/bugs/149045
[08:15] <pitti> tkamppeter: it would be nice if people who do not have HPs wouldn't have the daemon running
[08:16] <tkamppeter> pitti, for USB devices this would be perfect, for parallel and network devices one must find what is the best solution.
[08:17] <pitti> hm, so hpssd does *not* do the device access?
[08:18] <tkamppeter> pitti, Donald says that the libmud library is accessing the devices and this one is directly linked to the user tools which would mean that the access is done with the user's privileges.
[08:19] <pitti> bummer
[08:20] <tkamppeter> pitti, so perhaps we should make the devices belong to the "scanner" group and let the CUPS backend run SGID scanner?
[08:21] <pitti> tkamppeter: no setgidness, please
[08:21] <pitti> tkamppeter: ideally we would make the device nodes accessible to both scanner and lpadmin
[08:21] <dexem> if i would want to announce a new app for ubuntu, where should I sent an introductory email?
[08:21] <pitti> erm, scanner and lp, I mean
[08:21] <tkamppeter> Or then make the user "lp" member of "scanner"?
[08:22] <pitti> tkamppeter: so, lp:scanner should work
[08:22] <pitti> tkamppeter: does the cupsys backend run as root or lp? i. e. is it 700 or 755?
[08:23] <tkamppeter> till@till-laptop:~/ubuntu/hplip$ ls -l /usr/lib/cups/backend/hp*
[08:23] <tkamppeter> -rwxr-xr-x 1 root root 8388 2007-10-04 15:39 /usr/lib/cups/backend/hp
[08:23] <tkamppeter> -rwxr-xr-x 1 root root 7919 2007-10-04 15:36 /usr/lib/cups/backend/hpfax
[08:23] <tkamppeter> till@till-laptop:~/ubuntu/hplip$
[08:23] <tkamppeter> The cupsys backend seems ro run as "lp"
[08:24] <pitti> tkamppeter: so, having the device node be lp:lpadmin should fix it for lpadmins
[08:24] <pitti> tkamppeter: which is usually not every user, but at least the default one
[08:24] <tkamppeter> So at least the user "lp" and also all members of "scanner" would need access.
[08:24] <pitti> right, that's better
[08:24] <pitti> lp:scanner
[08:25] <tkamppeter> pitti, let me try ...
[08:26] <pitti> anyway, I need to leave
[08:26] <pitti> tkamppeter: can we continue this tomorrow if lp:scanner does not work?
[08:26] <pitti> tkamppeter: we should continue discussion on the bug report
[08:26] <tkamppeter> pitti, yes, see you tomorrow.
[08:26] <tkamppeter> pitti, on which of the two?
[08:27] <pitti> tkamppeter: I added that comment to bug 147369
[08:27] <ubotu> Launchpad bug 147369 in system-config-printer "MASTER: Printing via HPLIP does not work any more" [Undecided,Invalid]  https://launchpad.net/bugs/147369
[08:31] <mekius> bryce: ping
[08:36] <iwj> calc: Thanks.  I'm nominally on holiday tomorrow but if you need to ask me questions email me and I may well check my mail mid-afternoon UK time tomorrow.
[08:42] <dexem> I would like to announce a soon v1.0 release of this  --> https://forge.vodafonebetavine.net/frs/?group_id=12  which list should be the best for it?
[08:49] <bryce> hi mekius
[08:49] <rulus> Hi, can anyone tell me what's the difference between in effect between System > Preference > Screen resolution and System > Administration > Screens & Graphics, and why we still need the first one? Setting up your screen resolution in two places seems very confusing to me..
[08:50] <mekius> bryce: hey, we have some via hardware that we are installing a customized ubuntu distribution on.  We have some drivers that we are loading onto the CD for their video, what is the best way to autodetect a VIA video card and setup X to use this instead of just VESA.  We would hard code it, but we plan on distributing the CD via the internet as well.
[08:51] <gnomefreak> rulus: for support see #ubuntu+1
[08:51] <rulus> ok
[08:51] <bryce> mekius: the best thing is to key it off the pci id
[08:51] <bryce> mekius: generally we've done this via the discover-data package
[08:52] <bryce> mekius, it has an xml file listing video card pci id's and indicating the driver to use with them
[08:52] <mekius> bryce: oh ok, that will be pretty easy to setup then
[08:52] <bryce> yup
[08:52] <mantiena-baltix> rulus, problem is, that Screens & Graphics is still very buggy, also it crashes a lot :(
[08:52] <mekius> bryce: so do you think we should roll our own version of this package then?
[08:53] <bryce> mekius: sure, that'd give you the most control.  And then if you give me the changes, I'll roll them into the official package
[08:53] <Kmos> bug 132221
[08:53] <ubotu> Launchpad bug 132221 in ubuntu-dev-tools "requestsync: Add latest debian version to the title of the bug" [Wishlist,Fix committed]  https://launchpad.net/bugs/132221
[08:53] <Kmos> if someone wants to comment it out
[08:54] <mekius> bryce: ok, only issue with that is that this is an inside driver atm so it needs some testing, it is essentially an updated version of VIAs official driver
[08:54] <bryce> mekius: the xml file is pci-device.xml.  I think it's fairly self-explanatory
[08:54] <mekius> bryce: so eventually they will probably release it
[08:54] <bryce> mekius: the one other thing to do is run `make pci-26.lst pci.lst`, which uses the xml to update those lists
[08:54] <mekius> ah ok
[08:55] <bryce> ok no prob; let me know the changes once it is released
[08:55] <mekius> i think for now we can just modify in place for testing :)
[08:55] <bryce> cool
[08:55] <mekius> oh, that's interesting, discover-data was not installed heh
[08:55] <bryce> mekius, there is a second approach I'll give you as an alternate
[08:55] <mekius> that might be a start :)
[08:56] <bryce> dexconf is the tool that generates the xorg.conf for systems
[08:56] <bryce> there is a spot in that code that looks up the driver to use from the debconf database
[08:57] <bryce> you can insert an override at that point
[08:58] <bryce> this alternate approach is rather hacky, but if you're doing something really chipset specific or just doing testing, it might be of use
[08:58] <mekius> yeah
[08:58] <mekius> is the debconf database editable?
[08:58] <bryce> for instance, if you need to customize the xorg.conf beyond just setting the driver (e.g. flipping on various options specific to the device, etc.)
[08:58] <MacSlow> mvo, I've fixed the issue seb128 mentioned... regarding the sensitivity (icon, label) of the effect-level entries in the visual-effects-tab of gnome-appearance-manager... but the problem with #145059 I've not located yet.
[08:59] <evand> mekius: debconf-communicate
[08:59] <mekius> evand: thx
[08:59] <MacSlow> mvo, I would guess better wait with asking you or seb128 for uploading it until that RC-critical bug is fixed, right?
[09:00] <sladen> mjg59: GetBrightness, UINT or INT this week?
[09:00] <mekius> bryce: i might try updating the debconf database if it proves to be simple enough
[09:01] <mekius> bryce: as then in the future if we need to set options we will already be on the right track
[09:01] <bryce> sounds good
[09:01] <MacSlow> mvo, actually I would like to get #145020 done with the next update to gnome-control-center too
[09:01] <mekius> bryce: thx for the help, i figured it was just some conf files of some sort but couldn't find any info online
[09:02] <sladen> mjg59: g_value_set_int: assertion `G_VALUE_HOLDS_INT (value)' failed  etc
[09:02] <bryce> no prob; good luck!
[09:02] <mekius> thx
[09:03] <mekius> evand: any elaboration on using debconf-communicate or something besides the man page for documentation?
[09:03] <mekius> ah ok
[09:03] <mekius> so i need to talk to it with the debconf protocol
[09:04] <evand> echo GET console-setup/charmap | debconf-communicate
[09:04] <evand> yes
[09:06] <mekius> looks like i have some digging to do :)
[09:16] <Whoopie> sladen: I made a patch for the UINT/INT issue:http://en.pastebin.ca/725879
[09:17] <Whoopie> it was in one or two gnome bug reports
[09:18] <sladen> Whoopie: rock;  there's more instances though;   there's the ones already in  debian/patches/73*.patch
[09:18] <sladen> Whoopie: and then also in the brightness applet
[09:18] <sladen> Whoopie: what's the background to it?
[09:20] <Whoopie> sladen: this patch adds more instances then in 73*
[09:20] <sladen> indeed;  and there's yet more on top of those
[09:21] <Whoopie> sladen: ups, ok
[09:21] <Whoopie> sladen: what do you mean by background?
[09:22] <sladen> Whoopie: what's the upstream bug report that details all this churn
[09:22] <sladen> Whoopie: how many other functions does it affect?
[09:24] <sladen> Whoopie: do any of those fix the on-ac/on-battery handling?
[09:25] <Whoopie> sladen: gnome bug 469748
[09:25] <ubotu> Gnome bug 469748 in general "Brightness keys fail to set backlight brightness correctly" [Normal,Unconfirmed]  http://bugzilla.gnome.org/show_bug.cgi?id=469748
[09:26] <Whoopie> sladen: hmm, I don't have problems with on-ac/on-battery. could you explain more?
[09:26] <sladen> Whoopie: the on-battery brightness slider does not work
[09:27] <mjg59> sladen: It works fine here.
[09:27] <Whoopie> sladen: aha, works here
[09:27] <mjg59> Ah. It seems potentially confused by "Dim on idle"
[09:28] <Whoopie> sladen: just annoying DSDT bug with my Samsung P35 which generates an ACPI event event when I change the brightness through sysfs
[09:28] <mjg59> Strongly tempted to just disable that. It's not going to get fixed in tiem.
[09:31] <sladen> mjg59: and how did you disable Fn-Home/Fn-End from twiddling the hardware?
[09:31] <mjg59> I didn't
[09:31] <sladen> mjg59: I want to revert aswell
[09:31] <mjg59> No
[09:31] <sladen> what's stopping that;  xorg?
[09:31] <mjg59> (a) It's in-kernel, so too late
[09:31] <sladen> ffs.
[09:31] <mjg59> (b) It breaks shit
[09:32] <sladen> what this hard coded it can it be disabled with some module parameters
[09:32] <mjg59> (c) You can poke it via /sys/module/video/parameters/no_automatic_changes
[09:32] <mjg59> The default isn't changing. There's no way to make it work.
[09:32] <sladen> I'd rather deal with the corner cases than have completely non-functioning brightness
[09:32] <mjg59> You just need a daemon that listens for you
[09:32] <mjg59> But no, we are not doing this in-kernel
[09:33] <mjg59> It results in everything getting out of sync in horrific ways
[09:33] <sladen> I don't want anything done in-kernel
[09:33] <sladen> it worked great as it was
[09:33] <mjg59> It was done in-kernel
[09:34] <sladen> for the last 5 years it was done in kernel?
[09:34] <mjg59> No, on most machines it was done in hardware
[09:34] <sladen> even without any thinkgpad modules loaded... ?!
[09:34] <mjg59> Yes
[09:34] <mjg59> The Thinkpad driver never did it
[09:34] <mjg59> video.ko did
[09:35] <sladen> so what's the change that went in in the last fortnight that "broke" it
[09:35] <mjg59> I removed the in-kernel policy
[09:35] <mjg59> Because it was impossible to make it work right
[09:35] <slangasek> bug #121566: is this really a reproducible problem with NM on upgrades from feisty to gutsy?  that seems unlikely, with only three follow-ups...
[09:35] <ubotu> Launchpad bug 121566 in network-manager "no network with dhcp set up" [Critical,Confirmed]  https://launchpad.net/bugs/121566
[09:37] <sladen> this is the innocent "alter default behaviour of ACPI video module" ?
[09:37] <mjg59> Yes
[09:41] <pwnguin> neat. cupsys is broked
[09:42] <pwnguin> bug 149117
[09:42] <ubotu> Launchpad bug 149117 in cupsys "cupsys fails to install" [Undecided,New]  https://launchpad.net/bugs/149117
[09:51] <lamont> Setting up passwd (1:4.0.18.1-9) ...
[09:51] <lamont> no matching password file entry in /etc/shadow
[09:51] <lamont> add user 'root' in /etc/shadow? no matching password file entry in /etc/shadow
[09:51] <lamont> add user 'daemon' in /etc/shadow? no matching password file entry in /etc/shadow
[09:51] <lamont> add user 'bin' in /etc/shadow? no matching password file entry in /etc/shadow
[09:51] <lamont> add user 'sys' in /etc/shadow? no matching password file entry in /etc/shadow
[09:52] <slangasek> asac: as the NM scapegoat, do you have any thoughts on #121566? :)  is the syslog provided there sufficient to reproduce/debug this?
[09:53] <asac> bug 121566
[09:54] <ubotu> Launchpad bug 121566 in network-manager "no network with dhcp set up" [Critical,Confirmed]  https://launchpad.net/bugs/121566
[09:54] <slangasek> lamont: what did you do to make it hate you? :)
[09:54] <lamont> the chroot had a shadow file with just the user 'lamont' in it.  and passwd decided it'd be better to fail to install than to let someone have a bogus shadow file on their machine
[09:55] <asac> slangasek: i will triage it ... but i don't think its critical
[09:56] <slangasek> asac: sure, three reports of NM failing in 4 months isn't a lot :)
[09:56] <asac> slangasek: lets keep it for rc, until i received the answers
[09:56] <leh> has anybody of you recently experience problems with firefox on gutsy? i can't do "submits" anymore which is really strange :-)
[09:56] <asac> slangasek: i assign it to me now
[09:56] <leh>  i'd love to report this bug, but can't login to launchpad *g*
[09:58] <lamont> leh: use lynx
[09:58] <lamont> to file the bug, that is.
[09:58] <pwnguin> or a second computer ;)
[09:58] <lamont> :-)
[09:58] <lamont> pwnguin: that'd be cheating
[09:59] <pwnguin> does lp work with lynx?
[10:00] <norsetto> leh: I'd check first in https://answers.launchpad.net/
[10:01] <leh> norsetto: thx alot ;-)
[10:02] <leh> ok, but i'll guess your ff is still working ok
[10:02] <pwnguin> for the moment
[10:04] <pwnguin> leh did you install firefox3 by chance?
[10:13] <mdke> doko: yes, I got it
[10:21] <gnomefreak> crimsun: can you ping me when you get time i need a code-dev to sponser flash backport from gutsy to dapper to fix md5sum, figured might as well upgrade it to latest stable. bug 147688 is the bug on it
[10:21] <ubotu> Launchpad bug 147688 in flashplugin-nonfree "wrong md5sum" [Undecided,In progress]  https://launchpad.net/bugs/147688
[10:58] <mvo> MacSlow: either way should be fine (uploading now to get testing or waiting for the other issue if that gets done reasonsable quick)
[10:58] <nicolai__> gn8
[11:03] <MacSlow> mvo, I think I can get the pending issues done tomorrow