[00:02] <slangasek> calc: so bug #131526 is fixed in OOo 2.3.1-3ubuntu1, right?  (supposedly fixed upstream in 2.3.1)
[00:02] <ubotu> Launchpad bug 131526 in openoffice.org "[gutsy] OpenOffice crashes/hangs with some Gtk themes (e.g. Crux)" [Undecided,Fix released] https://launchpad.net/bugs/131526
[00:03] <calc> slangasek: yes
[00:03] <calc> it was also fixed in gutsy updates
[00:03]  * slangasek nods
[00:04]  * lamont looks to see if alternate ports images were built for alpha3
[00:05] <slangasek> they weren't published, and I recall seeing some d-i failures which suggested to me it wasn't going to be worth chasing
[00:06] <lamont> slangasek: yeah - I'll just fetch a current daily and see how bad it is.
[00:06] <slangasek> that's the same as would've been released with the alpha had we done one, so. :)
[00:06] <Keybuk> lamont: open office didn't compile on hppa? :)
[00:07] <lamont> Keybuk: apparently someone is actually working on the ia64 port though
[00:07] <lamont> sigh.  I need to find a better place to squat for bandwidth.
[00:07] <calc> it claims hppa built ooo
[00:07] <lamont> 150KB/s sucks
[00:08] <StevenK> lamont: That's all I get.
[00:08] <lamont> calc: it just skips the acutal binary.  ENOTRAMPOLINE
[00:08] <calc> heh
[00:08] <slangasek> SIGPOLEVAULT
[00:08] <calc> failed on amd64, lpia, powerpc, sparc, i know how to fix powerpc build properly, amd64/lpia/sparc are compiler issues afaict
[00:09] <calc> well technically fixing the powerpc build is thoroughly disabling java
[00:17] <lamont> calc: skipping all the binaries does make it build better.  OTOH it's not so useful :-)
[00:17] <lamont> hence hppa builds just fine...
[00:17] <lamont> StevenK: but you live in the land of no bandwidth, don't you?
[00:17] <jdong> I'm guessing I'm out of context, but doesn't skipping all the binaries defeat the purpose of building something? :D
[00:17]  * lamont confirms that StevenK does.
[00:18] <lamont> jdong: "oo.o built on hppa" is the context
[00:18] <lamont> it builds because it doesn't build binaries... so you get a package, just not any application.
[00:18] <StevenK> lamont: Hmph
[00:18] <lamont> see.  no problem.
[00:18] <lamont> StevenK: .au.. bandwidth sucks.
[00:18] <jdong> lamont: meh hppa people don't need OOo anyway :D
[00:18] <lamont> jdong: if they do, they can run it remotely on a faster comptuer.
[00:18] <jdong> lamont: can we do the same with eclipse too?
[00:18] <jdong> :)
[00:20] <lamont> jdong: nah - we just don't build that
[00:20] <jdong> even better :)
[00:23]  * cjwatson unbreaks the d-i powerpc build in bzr
[00:25] <cjwatson> the other failures are really dep-waits on kernel bits
[00:29]  * cjwatson trims a couple of hundred megabytes off openssh's build-deps
[00:29] <lamont> cjwatson: thank you
[00:30] <cjwatson> Colin Walters told me back in the dawn of time that it needed libgnomeui2-dev to build the GTK2 askpass, and evidently I never bothered to check
[00:30] <Keybuk> one could argue that GTK2 askpass is deprecated by seahorse
[00:30] <slangasek> tsk, subversive redhatters trying to make everything use gnome
[00:31] <cjwatson> Keybuk: one could argue that openssh should build its own stuff even if some other optional component is trying to replace it ;)
[00:32] <Keybuk> cjwatson: it already has a simple X one though, no?
[00:32] <Keybuk> it doesn't *realllly* need a GTK2 one as well
[00:32] <cjwatson> Keybuk: no
[00:33] <Keybuk> I could get Mirco to knock up ssh-askpass-gl ? :)
[00:33] <cjwatson> you're thinking of ssh-askpass which was a separate source
[00:33] <Keybuk> ah
[00:33] <cjwatson> openssh itself contains GTK1 and GTK2 askpass implementations
[00:34] <cjwatson> ssh-askpass-gl> go ahead, I'll keep on building ssh-askpass-gnome, you just don't have to include it :)
[00:34] <cjwatson> it's a separate binary package
[00:35] <cjwatson> (I do think ssh-askpass-gl would be cool albeit probably total overkill ;-))
[00:35] <Keybuk> it could look like the movie os "ACCEPTED" when done
[00:35] <slangasek> haha
[00:36] <Keybuk> ACCESS DENIED
[00:36] <Keybuk> oh damn, I just typed sab<tab> to check ...
[00:36] <Keybuk> quick, need a way to wipe his logs off this conversation ;)
[00:47] <Burgundavia> Keybuk: if sound juicer does not spin my cd down to 1x when playing a cd, is that an sj or a kernel bug?
[00:47] <Keybuk> are you sure you haven't just taken speed?
[00:48] <Burgundavia> Keybuk: pretty certain, but let me check with the gf
[00:48] <Keybuk> I'd file it as soundjuicer
[00:48] <Burgundavia> nope, she didn't
[00:48] <Keybuk> but you'd probably need to debug and fix that one yourself
[00:48] <Burgundavia> ugh
[00:48] <Keybuk> since I honestly doubt anyone else anywhere in the universe would be able to replicate it
[00:48] <Burgundavia> probably
[00:49] <Burgundavia> oh wait, now she is saying that she didn't think I notice :)
[00:51] <slangasek> that you were given speed?
[00:53] <Burgundavia> yep
[00:53] <Burgundavia> and how would I go about debugging this?
[00:55] <Keybuk> are you hungry?
[00:55] <Burgundavia> yes, it is almost dinner time
[00:55] <Keybuk> then you are unlikely to be on speed
[00:57] <Burgundavia> right, glad to know, having never done speed, I didn't know that
[01:09] <probleme> i have a bug
[01:09] <probleme> http://hiboox.com/lang-fr/resultat.php?img=mj86a8br.png&error=0#
[01:09] <probleme> (livecd gusty)
[01:09] <probleme> that's all :)
[01:09] <Burgundavia> probleme: you need to file it in the bugtracker on launchpad
[01:10] <Burgundavia> although I am not certain what kind of bug you think you have
[01:10] <probleme> Burgundavia: don't know how to do this
[01:10] <Burgundavia> please join #ubuntu-bugs
[01:10] <probleme> #ubuntu-bugs/j
[04:30] <gQuigs> references: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/51869, https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/18355
[04:30] <ubotu> Launchpad bug 18355 in linux-source-2.6.15 "Add the badram patch to the Ubuntu kernel" [Wishlist,Invalid]
[04:30] <gQuigs> any chance we could see a badram patch package, (not installed by default)
[04:31] <gQuigs> the whole linux-patch-* thing
[05:27] <euther> join #ubuntu+1
[05:47] <dholbach> good morning
[05:49]  * slangasek waves
[05:50] <ion_> Hi
[05:53] <dholbach> hiya ion_, hey slangasek
[07:07] <pitti> Good morning
[07:07] <ion_> Hi
[07:13] <StevenK> pitti: Morning pitti
[07:14] <StevenK> pitti: So, do I have any chance of getting midbrowser promoted?
[07:14] <pitti> StevenK: is that thing using the ffox 3 codebase and xulrunner-1.9?
[07:15] <pitti> hm, I can't see a xulrunner dependency
[07:16] <pitti> StevenK: eventually it boils down to (1) we need it and promote it and (2) asac will support it
[07:16] <pitti> StevenK: less a question about 'if', rather 'how'
[07:16] <StevenK> Right.
[07:17] <StevenK> pitti: And now liferea build depends on it, because some silly dork uploaded without checking first.
[07:17] <StevenK> Well, liferea on lpia
[07:17] <StevenK> pitti: Would you like a bug about it?
[07:31] <Fujitsu> in 5
[07:31] <Fujitsu> Gah.
[07:48] <pitti> StevenK: you mean a bug about 'please migrate midbrowser to ffox3 and xulrunner?
[07:52] <siretart> against which package should bugs like this be filed? http://paste.ubuntu-nl.org/51536/report/
[08:10] <StevenK> pitti: No, I mean a bug "Please promote midbrowser"
[08:14] <pitti> StevenK: we need a MIR bug for that, yes
[08:15] <scizzo-> any dbus developer or packager for dbus around?
[08:18] <pitti> scizzo-: what's the problem?
[08:18] <scizzo-> pitti: well mostly that f-spot does not seem to call on "dbus-laung f-spot"
[08:18] <scizzo-> pitti: I am not sure if it is f-spot or if it is a dbus error...
[08:19] <pitti> scizzo-: can you explain further, please? what does dbus-launch have to do with f-spot?
[08:19] <pitti> dbus-launch is for creating a session bus, but gnome-session takes care of this
[08:19] <pitti> f-spot shouldn't need to fiddle with that
[08:20] <scizzo-> pitti: well a normal start of f-spot gives the error: http://pastebin.se/192746
[08:20] <scizzo-> which in this case state that it is not really launching dbus-launch correctly....however when running dbus-launch f-spot in a terminal f-spot opens and without problems
[08:21] <scizzo-> well I got one gdk-pixbuf
[08:21] <scizzo-> (f-spot:1603): GdkPixbuf-WARNING **: GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed. You must explicitly end the data stream to the loader before dropping the last reference.
[08:21] <pitti> scizzo-: hm, are you actually using gnome?
[08:21] <scizzo-> thats about it
[08:21] <scizzo-> pitti: no I am not....I am running xfce....xubuntu
[08:21] <pitti> scizzo-: and xfce does not launch a session bus by default?
[08:22] <scizzo-> pitti: let me check
[08:22] <pitti> scizzo-: if not, you should install dbus-x11
[08:22] <pitti> (and Xubuntnu should then do that by default; that's worth a bug report)
[08:22] <scizzo-> pitti: let me try that
[08:23] <scizzo-> there are dbus-daemon running not sure if it is the same thing
[08:23] <scizzo-> also I have dbus-x11 installed
[08:28] <scizzo-> if I move the old f-spot dir from .gnome2/ I get some other traces
[08:28] <scizzo-> one sec
[08:28] <scizzo-> http://pastebin.se/192747
[08:28] <scizzo-> the outcome is the same though
[08:30] <pitti> scizzo-: there should be a system dbus daemon, right
[08:30] <pitti> but if that doesn't work, you'd have much worse problems
[08:31] <pitti> scizzo-: did you restart your session after installing dbus-x11?
[08:31] <scizzo-> I am fearing a "scizzo- reinstall the machine" answer
[08:31] <scizzo-> pitti: it was already installed
[08:31] <pitti> hm
[08:32] <pitti> no real idea then, I'm afraid; maybe you can ask the XFCE devs about the lack of a dession dbus
[08:32] <scizzo-> pitti: I can try with a completely new user....?
[08:32] <pitti> and file a bug maybe, too
[08:32] <gpocentek> the dbus session is launched in xubuntu
[08:32] <pitti> scizzo-: you can try, but there's a high chance that this won't help
[08:32] <gpocentek> xfdesktop/thunar need it
[08:32] <pitti> hey gpocentek!
[08:32] <pitti> good to know
[08:32] <gpocentek> hello pitti :)
[08:33] <scizzo-> gpocentek: aaa...right
[08:33] <scizzo-> I am not really a years of used XFCE user...just trying to error search the f-spot stuff
[08:36] <scizzo-> seems to be the same result on the test user
[08:38] <scizzo-> I will check with #xubuntu-devel
[08:38] <scizzo-> thanks for all the thelp
[08:38] <scizzo-> s/thelp/help/g
[08:41] <scizzo-> not really sure what is happening
[08:44] <pitti> tjaalton: I'd greatly appreciate advice about bug 179638
[08:44] <ubotu> Launchpad bug 179638 in xfree86-driver-synaptics "Please sync xfree86-driver-synaptics 0.14.7~git20070706-1  (universe) from Debian unstable (main)" [Undecided,Incomplete] https://launchpad.net/bugs/179638
[08:45] <DktrKranz> Can a buildd admin give-back freesci on i386? Thanks.
[08:46] <pitti> DktrKranz: done
[08:46] <DktrKranz> pitti: thanks.
[08:49] <tjaalton> pitti: huh, hardy has 0.14.7~git20070706-1ubuntu1?
[08:50] <pitti> no, 0.14.4-1
[08:50] <pitti> ah, the binary, right
[08:50] <pitti> tjaalton: the confusion is that Debian builds xserver-xorg-input-synaptics from the xfree86-driver-synaptics source, while we build it from the xserver-xorg-input-synaptics source
[08:50] <tjaalton> right
[08:51] <pitti> tjaalton: so I was asking if we could actually use Debian's source and drop our's to reduce the delta
[08:51] <tjaalton> I've asked mattia if he'd like to rename it, but got no reply
[08:51] <tjaalton> that works too
[08:51] <pitti> right, renaming it in Debian would be nicer, of course
[08:51] <tjaalton> but a sync is not doable
[08:51] <tjaalton> there are changes
[08:52] <pitti> tjaalton: right; that's part of the question in the bug: should we merge our remaining delta to the xfree86-driver-synaptics source and forward the rest to Debian/upstream, or go with our own packaging?
[08:53] <pitti> tjaalton: I'm fine with either (prefering to use the Debian source, of course), but I'd like to remove one of the source packages from Ubuntu to avoid confusion and sync-source.py breakage
[08:53] <tjaalton> maybe we should merge, and then if the source is renamed we'd get it again
[08:53] <pitti> yeah
[08:55] <tjaalton> hmm, so if the only diff between those packages is that the tarball is renamed, it's pretty easy to do :)
[08:56] <pitti> tjaalton: I guess bug 180539 is ok
[08:56] <ubotu> Launchpad bug 180539 in xserver-xorg-video-amd "Please sync xserver-xorg-video-amd 2.7.7.4-1  (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/180539
[08:56] <pitti> the changelog looks reasonable
[08:58] <tjaalton> yeah, that's fine
[08:58] <pitti> thanks
[09:00] <mvo> Riddell: kde 4 release today? is that correct?
[09:01] <tjaalton> mvo: judging by the flood of blog posts I'd say yes :)
[09:09] <StevenK> pitti: I daresay the rationale and so on is well known for midbrowser. Do you want to spell it out anyway
[09:09] <StevenK> ?
[09:10] <pitti> StevenK: just file the bug and say it's required by mobile; one sentence is enough
[09:10] <StevenK> pitti: Mmm, you want the paper trail.
[09:12] <StevenK> pitti: Bug 181959
[09:12] <ubotu> Launchpad bug 181959 in midbrowser "Please promote midbrowser to main" [Undecided,New] https://launchpad.net/bugs/181959
[09:12] <StevenK> pitti: And if you could add ppm in source NEW to your things to look at, not urgent.
[09:13] <pitti> StevenK: yes, still doing syncs; I'll get to NEW later
[09:13] <StevenK> Oh yeah, Friday is your archive day. :-)
[09:13] <pitti> *sigh* yeah :)
[09:15] <\sh> moins
[09:15] <pitti> hey \sh! welcome back to MOTU
[09:15] <StevenK> Hey \sh
[09:16] <\sh> pitti: thx...a wonderful birthday present that is :)
[09:16] <pitti> ooh! happy birthday! *hug*
[09:20] <mvo> happy birthday \sh \o/
[09:20] <sladen> happy neu jahr mvo \o/
[09:21] <pitti> mvo: can you please advise me about bug 179876?
[09:21] <ubotu> Launchpad bug 179876 in compizconfig-backend-kconfig "[Remove] Please remove compizconfig-backend-{gconf,kconfig} from hardy" [Wishlist,Confirmed] https://launchpad.net/bugs/179876
[09:21] <mvo> hey sladen, happy new yeah for you too
[09:21] <mvo> pitti: meh
[09:21] <\sh> mvo: thx :)
[09:22] <mvo> pitti: looking into it now
[09:24] <mvo> pitti: I will rename out packages to match the debian name,that should fix the issue
[09:24] <pitti> mvo: right; please let me know when this is done, then I'll remove our obsolete source
[09:24] <pitti> but better match debian's names for easier merging and syncing
[09:24] <pitti> mvo: thanks
[09:24] <mvo> pitti: ok, doing that now, will take a bit to update all depends etc
[09:25] <pitti> mvo: oh? it's not just about renaming the source package? binary packages, too?
[09:26] <linuxboy> is Ben Collins hangs around ?
[09:26] <mvo> pitti: yes, but its not too bad, few dependencies
[09:26] <linuxboy> I got a kernel issue in gutsy
[09:27] <dholbach> linuxboy: try #ubuntu-kernel or filing a bug in Launchpad
[09:27] <linuxboy> dholbach: tried ubuntu-kernel
[09:28] <dholbach> a bug report is the best place - information on IRC tends to get lost easily
[09:29] <linuxboy> oh
[09:34] <Riddell> mvo: certainly is! are you excited?
[09:34] <Keybuk> *blink*
[09:34] <Keybuk> our X maintainer is "surprised" when changing a monitor "just works" ?! :)
[09:34] <Keybuk> worrying
[09:35]  * Keybuk grins at bryce
[09:35] <tjaalton> hehe
[09:35] <mvo> Riddell: yes! I I'm curious to see it
[09:35] <ion_> :-D
[09:37] <StevenK> Keybuk: Would you mind renewing my membership in ubuntu-dev?
[09:39] <Keybuk> StevenK: yes
[09:39] <StevenK> Keybuk: You would mind? :-)
[09:40] <Keybuk> we don't renew ubuntu-dev memberships
[09:40] <StevenK> Oh, right
[09:40] <Keybuk> they should all be expired
[09:40] <Keybuk> you'll remain a member via "motu" where you don't expire until 2009-01-16
[09:41] <StevenK> Okay, fair enough
[09:41] <Keybuk> although someone seems to have renewed some
[09:41] <sladen> however, the world is scheduled to end 3 weeks before that, you'll never actually get to /see/ the expiration.
[09:41] <Keybuk> sladen:  it is?
[09:41] <Keybuk> are Debian releasing again?
[09:42]  * StevenK smirks
[09:45]  * Keybuk cleans up ubuntu-dev
[09:48] <StevenK> Keybuk: But they can't delete teams, I thought?
[09:48] <Keybuk> do we need to?
[09:53] <pitti> seb128: libbeagle binary NEWed FYI
[09:55] <seb128> pitti: thanks, you can also demote beagle to universe
[09:55] <pitti> \o/
[09:56] <seb128> ;-)
[09:57] <pitti> -- hardy/main build deps on beagle-dev:
[09:57] <pitti> f-spot
[09:57] <pitti> that's the last rdep in main
[09:57] <pitti> seb128: I guess that'll be s/beagle-dev/lib&/ ?
[09:57] <seb128> pitti: the API has changed it likely needs code changes
[09:59] <persia> pitti: Re: process-removals.  Does this mean that we don't need to manually chase Debian removals and file bugs anymore?
[09:59] <pitti> persia: not sure, it seems to lag behind a bit; other removals that I did today didn't turn up there
[10:00] <pitti> persia: but it might just lag a bit
[10:00] <seb128> pitti: we can build it without beagle for now though, there is a f-spot sponsor request bug open, maybe that is already changed there
[10:00] <persia> pitti: How often do you run it?  I can certainly refrain from opening bugs for packages that haven't been removed for > 2 weeks (or some similar rule).
[10:01] <pitti> persia: I try to remember every week
[10:01] <pitti> persia: do you have an automated tool to track them in Debian?
[10:02] <persia> pitti: Thanks.  I'll be sure to only request removals for things pending over two weeks then.  I track http://qa.ubuntuwire.com/multidistrotools/ to identify removal candidates.
[10:03] <persia> There is also http://ftp-master.debian.org/~joerg/removals/removals.rss, which might be a useful input to something.
[10:03] <tjaalton> pitti: xfree86-driver-synaptics merge uploaded
[10:04] <tjaalton> versioned -1ubuntu2 so the binary is newer than what we have
[10:04] <pitti> tjaalton: thanks, you rock
[10:04] <pitti> so once this is in I can remove the old source
[10:04] <pitti> tjaalton: so we did have a remaining delta?
[10:04] <pitti> or is it just to bump the version number?
[10:06] <tjaalton> yes we have a delta
[10:06] <pitti> ok
[10:06] <tjaalton> couple of patches
[10:07] <mvo> pitti: compizconfig-backend-{gconf,kconfig} uploaded now along with a new compiz with updated depeendencies
[10:07]  * pitti hugs mvo
[10:08] <hunger> When will the ooo l10n debs for version 2.3.1 become available? OOo is installable for days now, yet I can not update since the l10n debs still seem to be missing.
[10:09] <mvo> pitti: do you want to a abugreport about the removal of the now outdated libcompizconfig-backend-{gconf,kconfig} from hardy
[10:10] <pitti> mvo: there is one about that topic already, that's fine
[10:10] <mvo> ok, nice. thanks pitti
[10:11] <seb128_> re
[10:11] <seb128> grrr at network restart during upgrade
[10:11] <pitti> yay nm
[10:12] <pitti> it should rather restart on resuming from sleep (always have to do that manually)
[10:12] <mvo> pitti++
[10:12] <mdz_> pitti: that seems to work fine for me
[10:13] <mvo> not for me (static configuration)
[10:13] <pitti> I added it to /etc/pm/sleep.d local for now, but would be nice to fix once and for all
[10:13] <mdz_> oh, I use dhcp
[10:13] <pitti> for me neither; fully dynamic configuration
[10:13] <pitti> but after resuming it just sits there and never tries to detect any wlans
[10:13] <pitti> mdz: for wifi or eth?
[10:14] <mdz> pitti: eth
[10:14] <pitti> ah
[10:14] <pitti> that might be it then; doesn't check for essids after resuming
[10:14] <pitti> mdz: I have some other stuff in my pm/sleep.d regarding reducing power consumption; maybe the sprint is a good opportunity to review such issues and fix them
[10:14] <pitti> TRLS :)
[10:25] <mdz> mvo: is PackagingToolsUsability intended to cover the release upgrader as well?
[10:25] <mvo> mdz: it was not discussed at the bof, what in particular would you like to see ?
[10:26] <mdz> mvo: just the same sort of review of text and UI elements for simple cleanups
[10:26] <soren> Hm.. I'm working on a bind9 SRU in Dapper. Its current version (dapper-{security,updates}) is 1:9.3.2-2ubuntu1.3. How should I version it? Just 1:9.3.2-2ubuntu1.4?
[10:26] <pitti> soren: sounds fine
[10:27] <soren> pitti: Ok. I wasn't sure if the version strings -updates and -security should be distinct somehow. Thanks!
[10:27] <pitti> soren: there hasn't been a strictly enforced policy about this
[10:28] <pitti> we started with adding .1 to security in the past
[10:29] <mvo> mdz: ok, thanks. I will ask mpt about it.
[10:47] <soren> Should SRU's do the DebianMaintainerField thing? If so, when did we start that? Feisty?
[10:49]  * soren glances at pitti
[10:49] <pitti> soren: yes please, since feisty; dpkg-source complaints are correct
[10:49] <pitti> ... in each release
[10:50] <soren> Good point.
[10:50] <soren> pitti: Thanks.
[10:50] <pitti> yw
[11:00] <ChrisGibbs> !info dmraid
[11:00] <ubotu> dmraid: Device-Mapper Software RAID support tool. In component universe, is optional. Version 1.0.0.rc13-2ubuntu5 (gutsy), package size 181 kB, installed size 612 kB
[11:04] <soren> pitti: One last thing (or so I hope :) ): I'm looking at the StableReleaseUpdates to make sure I got everything right, but the whole nominate-approve process has already been done, but I can't see if ubuntu-sru has even been in the loop on thigs bug (bug 160176).
[11:04] <ubotu> Launchpad bug 160176 in bind9 "L.ROOT-SERVERS.NET record needs an update" [Low,Fix released] https://launchpad.net/bugs/160176
[11:04] <StevenK> pitti: Did you get a chance to look at ppm and the midbrowser MIR?
[11:05] <pitti> StevenK: still doing NEW (taking hours again)
[11:05] <pitti> StevenK: midbrowser> as I said, I will veto for the moment if this uses ffox 2 code and no xulrunner
[11:06] <pitti> soren: right, should still be subscribed and ack'ed (feel freel to upload to the queue already for fast inspection; see policy)
[11:06]  * pitti -> lunch, bbl
[11:31] <Riddell> mvo: blamo! http://kubuntu.org/
[11:32] <cj_> is there a way to bring up a stock ubuntu FS without booting a CD?
[11:32] <cj_> debootstrap doesn't make the same filesystem as does the install CD
[11:32] <cjwatson> there's an appendix to the installation guide about cross-installing
[11:32] <cjwatson> installation-guide-i386 package
[11:33] <cj_> danke
[11:33] <cjwatson> it may not be bit-for-bit identical to what the install CD gives you but it should be close enough
[11:33] <Amaranth> Riddell: _nice_
[11:33] <Amaranth> It's about time ;)
[11:39] <cj_> ahh!  here is the clincher: sudo tasksel standard && sudo tasksel ubuntu-desktop
[11:39] <cjwatson> I suspect that's tasksel install ...
[11:39] <cj_> yeah, that
[11:40] <cj_> I was not aware of tasksel before :)
[11:40]  * mvo hugs Riddell
[11:40] <pitti> StevenK: ppm has been accepted in NEW an hour ago, btw
[11:42] <soren> pitti: Subscribed ubuntu-sru to the bug, attached debdiffs for dapper..gutsy, and uploaded to -proposed.
[11:42] <StevenK> pitti: Yay, thanks.
[11:42] <soren> pitti: Thanks for your help.
[11:42] <pitti> soren: great
[11:42] <StevenK> pitti: I was hoping to get midbrowser promoted so Liferea could build, but if you veto it, you veto it.
[11:43] <cj> thanks, cjwatson
[11:44]  * Hobbsee checks which country she's in
[11:45] <Amaranth> Hobbsee: I forget that sometimes too ;)
[11:45] <Hobbsee> this looks wrong.  it has to be wrong.
[11:45] <Amaranth> Hobbsee: ?
[11:46] <Hobbsee> Fetched 108MB in 2min8s (840kB/s)
[11:47] <pitti> mvo: compizconfig* binary NEWed
[11:57] <pitti> yay me; NEW is basically empty now again
[11:58]  * Hobbsee uploads more crap
[11:58] <Amaranth> pitti: for a couple hours anyway :)
[11:58]  * Amaranth tries to think of something to send through NEW
[11:58] <pitti> I won't touch it again today, thanks; 2 hours are enough
[11:59] <StevenK> pitti: So you'll look at midbrowser, and possibly dash my hopes?
[11:59] <pitti> StevenK: SRU now, then component-mismatches, then hardy_outdate.txt, then MIR
[12:02]  * persia is impressed with the volume of work required on archive-admin day, and cheers all archive admins generally, and especially pitti (it's Friday)
[12:03] <pitti> persia: impressed with volume> heh, me too :)
[12:03] <pitti> persia: thanks
[12:06] <Keybuk>       Device Boot      Start         End      Blocks   Id  System
[12:06] <Keybuk> /dev/loop0p1   *           1        9327    74919096   83  Linux
[12:06] <Keybuk> /dev/loop0p2            9328        9729     3229065    5  Extended
[12:06] <Keybuk> /dev/loop0p5            9328        9729     3229033+  82  Linux swap / Solaris
[12:06] <Keybuk> ...
[12:06] <Keybuk> there's something very wrong about that
[12:09] <pitti> soren: please go ahead and upload your bind9 updates
[12:11] <soren> pitti: To -proposed? I already did.
[12:11] <pitti> soren: nothing in the queues
[12:12] <soren> pitti: Ah... I forgot to add my ubuntu-yes-I-am-sure option to dput. :)
[12:12] <pitti> o_O
[12:13] <Hobbsee> soren: the yes-i-am-sure option?
[12:15] <soren> Hobbsee: My default_host_main is a dummy. The "host" that actually uploads to ubuntu is called ubuntu-ja-jeg-er-sikker which means ubuntu-yes-I-amsure.
[12:15] <Hobbsee> ahhh
[12:16] <TheMuso> smart
[12:16] <soren> Hobbsee: I made it so back when I first got upload privileges.. I was a scared little boy back then. I think it's safe to remove it now :)
[12:16] <Hobbsee> hehe :)
[12:16] <soren> Yes, this was only slightly more than a year ago. ;)
[12:16] <Hobbsee> seb128: now i'm finding kde disturbing.  damn you :)
[12:17] <ion_> hobbsee: ? :-)
[12:17] <seb128> Hobbsee: ;-)
[12:18] <Hobbsee> seb128: it's got some really nice stuff in it though
[12:18] <seb128> KDE4?
[12:19] <Hobbsee> seb128: yup
[12:19] <Riddell> seb128: dood, where have you been, it's all over the interweb!
[12:20] <seb128> Riddell: I've just noticed lot of KDE in NEW didn't read anything about it on the web yet
[12:20] <mjg59> Hm.
[12:20] <seb128> I've read some people saying that the coming kubuntu will not be a LTS thoguh
[12:20] <seb128> is that true?
[12:21] <mjg59> Someone's complaining that knotify4 is triggering about 800 wakeups a second.
[12:21] <pitti> yes
[12:21] <mjg59> Can anyone else reproduce that? (Just run powertop on a KDE4 desktop)
[12:21] <seb128> shouldn't that be announced on some ubuntu list?
[12:21] <pitti> seb128: KDE4 is still too fresh to immediately bless it with LTS apparently
[12:21] <soren> pitti: Hmm... Should I have versioned the gutsy one as ...ubuntu0.1 ?
[12:21] <seb128> pitti: my understanding from UDS was that hardy would not ship KDE4 by default
[12:22] <seb128> pitti: that they would have a special KDE4 edition and that the lts would use KDE 3 (like debian will do for lenny)
[12:22] <pitti> soren: that or ubuntu1, as you prefer
[12:22] <Fujitsu> Er, Gutsy should be ubuntu0.1, not ubuntu1... That'll get messy if you use ubuntu1.
[12:22] <soren> pitti: Ok, I named it ubuntu1, so all is well. It won't clash with anything.
[12:23] <seb128> Fujitsu: why?
[12:23] <soren> Fujitsu: Well, in some cases it could, but seeing as the version in hardy is based on a newer version from Debian, I don't see any risk of clashing?
[12:24]  * Fujitsu thought the SRU policy dictated sanity for versions.
[12:24] <Riddell> seb128: yes, that seems to be the case
[12:24] <Riddell> mjg59: sorry I don't have any machine where powertop works
[12:24] <seb128> Fujitsu: why would 0ubuntu1 not be a sane version?
[12:25] <Fujitsu> If I were looking at versions of a package on my system, and saw that bind9 was on *ubuntu1, I would, without checking, likely assume it hadn't been changed since release. SRU versions should be distinguishable.
[12:25] <mjg59> Riddell: Mm? How so?
[12:25] <seb128> Fujitsu: never been like that, GNOME 2.20.1 is versionned 2.20.1-0ubuntu1 for example
[12:25] <mjg59> It'll work on anything running one of our kernels
[12:25] <Fujitsu> seb128: Yes, and that was silly, I have to say. That could never have gone into Hardy sanely.
[12:26] <Riddell> mjg59: needs acpi doesn't it?
[12:26] <seb128> Fujitsu: hardy has 2.21
[12:26] <seb128> Fujitsu: and don't call me silly, thanks
[12:26] <seb128> Fujitsu: I know what I'm doing when I use a version
[12:26] <mjg59> Riddell: No
[12:27] <mjg59> Riddell: But hang on. None of your machines boot with ACPI enabled?
[12:27] <Riddell> mjg59: does wonky things on this R40e
[12:27]  * Hobbsee has a look
[12:27] <pitti> soren: do you still care about bug 119908 ? (dovecot in feisty)
[12:27] <ubotu> Launchpad bug 119908 in dovecot "Dovecot crashes on index files" [Undecided,Fix released] https://launchpad.net/bugs/119908
[12:27] <mjg59> I could have sworn we fixed the R40e years ago
[12:27] <Riddell> mjg59: hal takes an age to start up and the keyboard and mouse repeat presses randomly
[12:27] <mjg59> I mean, sure, no suspend for reasons I never worked out
[12:28] <mjg59> Riddell: Have you tried with the hardy kernel?
[12:28] <Hobbsee> mjg59: 92, apparently
[12:28] <Hobbsee> not 800
[12:28] <mjg59> Hobbsee: 92 wakeups per second?
[12:28] <mjg59> That's still 92 too many. What's it doing?
[12:28] <Hobbsee> mjg59: apparently so.
[12:28] <Fujitsu> seb128: Most updates use ubuntuX.Y notation. Why don't GNOME updates?
[12:28] <mjg59> (Hrngh new software should NOT HAVE THESE PROBLEMS)
[12:28] <Riddell> mjg59: possibly I havn't, I'm that used to adding acpi=off, I'll give it a go in a bit
[12:28] <Fujitsu> We should have some kind of consistency, surely.
[12:28] <mjg59> Riddell: Thanks!
[12:29] <seb128> Fujitsu: what upgrades? what is the of using NMU numbers
[12:29] <Hobbsee> Riddell: how do i tell what it's doing?
[12:29] <Riddell> Hobbsee: strace?
[12:29] <seb128> Fujitsu: if you suggest having a policy to version specially SRU upload that would be fine, but don't rely on NMU number then, you should rather add gutsy or sru to the version
[12:30] <Hobbsee> Riddell: i thought you generally knew what knotify was doing
[12:31] <soren> pitti: Hm.... I'm not sure.. Feisty's relevance has dropped significantly since gutsy got released :)
[12:31] <Riddell> Hobbsee: notifications :)
[12:31] <pitti> soren: that's why I ask
[12:31] <soren> pitti: It's still supported, though. Hm..
[12:31] <Fujitsu> seb128: Looking at *-changes, the vast majority of SRUs use ubuntuX.Y or ubuntuX.Y.MM. I don't see how it's NMU versioning.
[12:31] <seb128> Fujitsu: adding .Y is what debian does on NMU
[12:32] <soren> Fujitsu: The SRU policy dictates that the version should not clash with anything. That's pretty much it.
[12:32] <Fujitsu> seb128: I am aware. But this is after `ubuntu'. Most people follow this rule. It's enforced for security updates.
[12:32] <seb128> Fujitsu: I don't think it's a clear way to say that the version is a sru upload
[12:33] <seb128> you should better include sru or gutsy in the version to do that
[12:33] <Fujitsu> seb128: It means it's an SRU or a security update.
[12:33] <soren> pitti: I believe we briefly discussed it (the dovecot SRU) on IRC, but I forget the outcome. From the released version in feisty to 1.0 there was a huge bunch of things in the changelog that just said "fix index bugs" or thereabouts.
[12:33] <seb128> I've to go for lunch, bbl
[12:33] <seb128> well, adding .Y is the easiest way to make sure it's < new upload
[12:33] <seb128> but not a requirement if you know hardy will get a newer version
[12:34] <soren> pitti: ...I'm not sure what I'd update it to, though.
[12:36] <soren> pitti: And in any case, properly reviewing the necessary patch is a *lot* of work. As I mentioned in the bug report even just the diff from feisty->1.0 is >18K lines.
[12:37] <pitti> soren: yeah, for that I'd rather take the current experience with 1.0 into account
[12:38] <pitti> soren: no problem with it to sit in -proposed for four weeks if there are people who are interested in testing and using it
[12:38] <cjwatson> I concur that it isn't necessary to use ubuntuX.Y versioning if you already know that the next development release didn't clash with the versions you're planning to use
[12:38] <cjwatson> ubuntuX.Y is one of those cases of something that's often used for convenience that people then misinterpret as a requirement
[12:38] <Fujitsu> cjwatson: Isn't consistency a good idea, though?
[12:39] <cjwatson> hobgoblin etc. :-)
[12:39] <Fujitsu> It's used in the vast majority of cases.
[12:39] <cjwatson> I don't think it's necessary, "don't clash" is all we need
[12:39]  * persia thinks not using -XubuntuY (even -Xubuntu0.1) makes it harder to understand that it is ubuntu-specific variation.
[12:39] <cjwatson> I'm not for an excess of policy when it isn't necessary
[12:39] <cjwatson> persia: -XubuntuY *is* policy
[12:39] <cjwatson> (where the package is in Debian)
[12:40]  * persia reads backscroll again, now confused
[12:40] <soren> persia: I add "ubuntu1" to the version.
[12:40] <cjwatson> persia: to rewrite in a way that is compatible with your naming, -XubuntuY.Z for stable updates is the topic
[12:40] <pitti> soren: can you please put your plan into the bug report, or just mark it as wontfix if it isn't interesting any more?
[12:40] <soren> pitti: The thing is that most of the changes from 1.0 to 1.0.10 are also bug fixes.
[12:41] <Amaranth> persia: The argument is whether or not "ubuntu1" or "ubuntu0.1" is 'correct' for an SRU that doesn't currently have ubuntu changes
[12:41] <cjwatson> (which I think is perfectly reasonable and often sensible but not required)
[12:41] <soren> pitti: I'll ask for feedback on the bug report. If noone cares, nor will I :)
[12:41] <pitti> soren: 'most' is the key here, I guess
[12:41] <persia> Ah.  Right.  I like -Xubuntu0.Z in preference to -XubuntuY for SRUs, for consistency.
[12:41] <soren> pitti: Point.
[12:41] <pitti> soren: sounds like a plan; incomplete for a while until some reporter responds
[12:41] <soren> pitti: I'll do that, then.
[12:41]  * soren hugs pitti 
[12:42]  * pitti hugs soren, thanks
[12:42] <cjwatson> I have certainly myself just incremented Y (in persia's naming) in stable releases when I knew that the first upload to the development branch was of a new upstream
[12:43]  * Fujitsu might just be used to security stuff, where we have enforced sane version schemes...
[12:43] <\sh> pitti: do you think it's ok for compiz to default to emerald when it's installed and not honouring x-window-decorator?=
[12:43] <persia> Fujitsu: What is the security rule?  Should it not be matched for SRU to avoid confusion where a candidate is superceded?
[12:44] <cjwatson> security is different because it is much more normal for security updates to be prepared by people who don't ordinarily touch that package
[12:44] <pitti> \sh: that question is above my head, I'm afraid; mvo?
[12:44] <DktrKranz> persia, currently we adopt Xubuntu0.Y (for packages which haven't been modified) or XubuntuY.Z (for packages with Ubuntu deltas), but there isn't a specific policy about a strict versioning. As it has been said, "just don't clash".
[12:44] <cjwatson> but SRUs are often prepared by somebody who's as close to the regular maintainer as Ubuntu has
[12:44] <Fujitsu> cjwatson: Ah, I guess for main it might be a little different.
[12:44] <StevenK> pitti: Usually termed "is over my head"
[12:44]  * persia hopes that the algorithm generating http://people.ubuntu.com/~ubuntu-archive/pending-sru.html#superseded understands that
[12:44] <pitti> StevenK: ah, thanks
[12:45] <Amaranth> \sh: Hi there, again :)
[12:45] <pitti> persia: that just compares version numbers in -security vs. -proposed
[12:45] <cjwatson> Fujitsu: there are packages in universe that I'd consider to have very nearly regular maintainers too
[12:45] <cjwatson> e.g. wine
[12:45] <\sh> Amaranth: thx :) good to be back :)
[12:45] <persia> pitti: That's what I thought, and why I thought consistency would be good.
[12:45] <dholbach> MOTU Q&A Session in 14 minutes in #ubuntu-classroom!
[12:45] <Amaranth> \sh: that too but I meant your compiz question :)
[12:45] <\sh> cjwatson: what's with wine?
[12:46] <Amaranth> \sh: I don't have an x-window-decorator, where did that come from?
[12:46] <\sh> Amaranth: ah :) I don't know I have it in the /etc/alternatives/
[12:46]  * soren goes to lunch
[12:47] <\sh> Amaranth: and it was set to emerald
[12:48] <Amaranth> \sh: maybe mvo just added it, i think he is trying to sync the packages closer to debian
[12:48] <Amaranth> since i have not been available as much to help maintain them (i have no interest in syncing back to debian's broken setup)
[12:48] <\sh> Amaranth: dunno...but for me it's confusing...reading /usr/bin/compiz it will start emerald by default when it's installed
[12:49] <Amaranth> right, the idea being you only have it installed if you wanted to use it
[12:49] <\sh> Amaranth: but I would say, when we have x-window-decorator in place, we should honor it
[12:49] <Amaranth> but you can override this
[12:49] <cjwatson> \sh: did you read the whole conversation?
[12:49] <cjwatson> or did you just highlight on wine and skip the context? :)
[12:49] <\sh> cjwatson: nope sorry..I just got there when I read wine ;)
[12:49] <Amaranth> USE_EMERALD=no or some such thing in ~/.config/compiz/compiz-manager
[12:50] <Amaranth> \sh: Actually I'm not sure how you got the alternatives thing, the latest compiz is not installable yet so even if it's in there you couldn't have it :P
[12:50]  * Amaranth checks bzr
[12:53] <pitti> Riddell: is bug 155144 fixed in hardy?
[12:53] <ubotu> Launchpad bug 155144 in kdelibs "KSelectAction stopped working for custom values" [Undecided,In progress] https://launchpad.net/bugs/155144
[12:53] <Amaranth> \sh: ok, that doesn't exist at all, i think you must have added it manually or from some unofficial package that didn't clean up properly
[12:54] <\sh> Amaranth: well, I didn't install anything else as what's in the archives..of course it was an update from gutsy to hardy...
[12:54] <Riddell> pitti: yes thanks
[12:54] <Amaranth> gutsy didn't have anything like that either
[12:54] <pitti> Riddell: thanks, closed
[12:54] <\sh> Amaranth: hmm...
[12:59] <\sh> Amaranth: ah wait...I installed on gutsy this envy stuff...could be that this package added it there
[13:00] <pitti> mvo, asac: is bug 162609 fixed in hardy? (ubufox and apturl) if so, the status of the hardy and upstream tasks need some love
[13:00] <ubotu> Launchpad bug 162609 in apturl "plugin finder wizard and apturl don't use the same http proxy" [High,In progress] https://launchpad.net/bugs/162609
[13:16] <pitti> mvo: please upload update-manager for dapper (bug #181518)
[13:16] <ubotu> Launchpad bug 181518 in update-manager "check of LTS dist upgrades" [Undecided,Confirmed] https://launchpad.net/bugs/181518
[13:32] <mvo> pitti: thanks, doing that now
[13:39] <tkamppeter> h pitti
[13:39] <tkamppeter> hi pitti
[13:39] <pitti> hi tkamppeter
[13:41] <tkamppeter> pitti, concerning bug 153152 I have no answer from HP, but HP has released a new HPLIP version in the meantime
[13:41] <ubotu> Launchpad bug 153152 in hplip "[Gutsy SRU request] Fax utility not adding files to job." [Medium,Confirmed] https://launchpad.net/bugs/153152
[13:41] <tkamppeter> I think I have to remind the HP guys.
[13:41] <pitti> tkamppeter: so there's no SRU request in it ATM? I'll unsub ubuntu-sru then
[13:42] <\sh> hmmm...does the build state "done" means: published to the archve and build state "accepted" waiting to be published?
[13:42] <jsgotangco> \sh: welcome back!
[13:42] <pitti> \sh: right
[13:42] <\sh> jsgotangco: thx :)
[13:42] <pitti>  \sh: well, 'done' is 'published' or 'currently being published'
[13:43] <\sh> pitti: ok..then I understand why the amd64 version of the package is not on the archive but the i386 is :)
[13:45] <tkamppeter> Yes pitti, I need a fix fromn HP, depending on HP we have top skip fax support in Gutsy and tell this in the release notes. In some weeks I will make an LSB package of the newest HPLIP, if this does fax on Gutsy, we will announce it as a workaround.
[13:45] <tkamppeter> But we will naturally tell that it is non-Ubuntu and so not covered by Ubuntu's commercial support.
[13:47] <ScottK> pitti: Do you have a moment to discuss a MIR conundrum I'm facing?
[13:47] <pitti> ScottK: what's up?
[13:48] <ScottK> I'm working my way through the amavisd-new dependencies and build-deps.
[13:48] <ScottK> I got to build-dep libmilter-dev and stopped.
[13:48] <ScottK> That's part of Sendmail and I know we don't want to bring Sendmail into Main.
[13:48] <ScottK> amavisd-new makes two binaries.  amavisd-new and amavisd-new-milter.
[13:49] <ScottK> It's only amavisd-new we want in Main, not the milter.
[13:49] <ScottK> Of course, since it's a build-dep, I'm kind of stuck.
[13:49] <ScottK> So I can think of some options (none of them great);
[13:49] <ScottK> 1.  MIR Sendmail
[13:50] <pitti> argh no
[13:50] <ScottK> 2.  Split amavisd-new into two source packages.
[13:50] <tkamppeter> pitti, heno, about the London sprint, which days are you there as I want to present to you Tim Waugh, original author of system-config-printer, and Hin-Tak Leung winprinter driver developer.
[13:50] <ScottK> 3.  Split Sendmail into two source packages.
[13:50] <pitti> ScottK: why is amavis so insistant on sendmail? can't it use another MTA?
[13:51] <ScottK> pitti: The milter needs libmilter from Sendmail.
[13:51] <pitti> tkamppeter: I'll be there all week
[13:51] <ScottK> It'll work with Sendmail or Postfix, but needs to build against the milter
[13:51] <ScottK> err libmilter-dev
[13:51] <_StefanS_> hi there..
[13:51] <tkamppeter> pitti, are there days where you are booked out with meetings?
[13:52] <ScottK> Now that Postfix supports milters, I can imagine we may want other milters in Main in the future.
[13:52] <_StefanS_> does the hardy standard kernel support 4gb memory on 32bit?
[13:52] <pitti> ScottK: hm, splitting out libmilter seems like the best option to me, without knowing the details; WDYT?
[13:52] <ScottK> pitti: I think that's the long term best option.
[13:53] <pitti> tkamppeter: none so far; this is supposed to be a work/hack week, not a meeting week; while we'll have ad-hoc group sessions, we aren't supposed to get into discussion all day
[13:53] <ScottK> pitti: It does stick us with a maintenance burden since Debian would have no incentive to follow suite, but for our needs, it's probably best.
[13:53] <pitti> ScottK: or disable milter support in amavis altogether if we don't need it
[13:54] <ScottK> pitti: We don't NEED it.  I checked and the Ubuntu popcon is 47.  Dunno if that qualifies as significant.
[13:54] <_StefanS_> BenC: you there?
[13:54] <ScottK> pitti: But it's in Universe and has been there for a long time.
[13:54] <ScottK> I know people use our Sendmail packages, so it wouldn't suprise me to find it has at least some user base.
[13:54] <tkamppeter> pitti, so my guests can choose the day which fits best for them. I will only coordinate that both come on the same day that they also meet each other (I never got Tim Waugh onto a Printing Summit yet).
[13:55] <StevenK> pitti: ppm is in binary NEW if you want to poke at it.
[13:55] <StevenK> pitti: (And has built everywhere)
[13:55] <pitti> ScottK: hm, I'm afraid I'm not qualified to judge about this; I'm fine with either disabling milter support or splitting out libmilter
[13:55] <pitti> StevenK: poking now
[13:55] <ScottK> pitti: Thanks.  I'll look into how hard splitting out libmilter would be.  Thanks.
[13:55]  * pitti gives up hope to do anything else than archive today and goes on with housecleaning
[13:56] <_StefanS_> so no one can answer my 4gb question ?
[13:56] <ScottK> pitti: While you're housecleaning, StevenK just uploaded a clamav update to feisty-backports that it would be nice to get accepted.
[13:56] <pitti> StevenK: E: ppm: unstripped-binary-or-object ./usr/sbin/ppmd (and a lot of others); why?
[13:56] <realist> Why is there a problem introducing libmilter into main in the first place?
[13:56] <StevenK> Hum. Drat
[13:57] <pitti> lintian is your friend :)
[13:57] <pitti> StevenK: anyway, accepted; feel free to upload a fix
[13:57] <lamont> realist: it's not a problem, it's a process
[13:58] <StevenK> pitti: Doing so now.
[13:58] <BenC> _StefanS_: yeah
[13:58] <_StefanS_> BenC: does the current hardy kernel have 4gb mem support on 32bits?
[13:59] <BenC> _StefanS_: pretty sure we've always had that with the i386 -generic kernel
[13:59] <ScottK> realist: Because Postfix is our primary MTA and we don't want to move all of Sendmail into the supported catagory.
[13:59] <_StefanS_> BenC: isn't possible to check .config in /usr/src/kernel-ver ?
[13:59] <StevenK> _StefanS_: The .config is installed in /boot
[13:59] <ScottK> realist: libmilter is part of the sendmail source package.
[13:59] <_StefanS_> StevenK: thanks
[13:59] <realist> ScottK: so you're talking about splitting libmilter from sendmail
[14:00] <BenC> _StefanS_: CONFIG_HIGHMEM4G=y
[14:00] <realist> Makes sense now, thanks :-)
[14:00] <ScottK> realist: Yes, so we could just bring that in.
[14:00] <ScottK> Then other milters could be promoted to Main if needed.
[14:00] <StevenK> pitti: midbrowser? Although I suspect you'd veto it and give me more work on Monday. :-)
[14:02] <StevenK> pitti: Fixed ppm uploaded.
[14:03] <pitti> still fighting NEW/SRU/etc.; no end today...
[14:04] <pitti> imbrandon: new falcon still has the .mo file
[14:04] <StevenK> Poor pitti, drowning in the archive ...
[14:05] <persia> pitti: Why change "verification-done" to "verification-motu-done"?  I thought the new consolidated SRU procedure shared tags.
[14:05] <pitti> persia: oh? I'm not aware of this
[14:05] <lamont> pitti: I don't suppose you want to send me a diff for the bind9 SRU uploads?
[14:05] <lamont> or I could just go grab it from LP, I suppose
[14:05] <persia> pitti: Right.  I'll go poke ~motu-sru to make a bigger announcement than just updating the wiki.
[14:06] <pitti> persia: different tags make it easier to see who is responsible to verify what, though
[14:06]  * ScottK agrees with pitti
[14:07] <pitti> lamont: they are all attached to bug 160176
[14:07] <ubotu> Launchpad bug 160176 in bind9 "L.ROOT-SERVERS.NET record needs an update" [Undecided,Fix committed] https://launchpad.net/bugs/160176
[14:07] <lamont> yeah
[14:07]  * lamont adds to his "after work" list
[14:07] <persia> pitti: I don't disagree (and don't really have a strong opinion about SRUs, as I'm not confident of thresholds), but if you haven't heard about the new procedure, then ~motu-sru needs to discuss it in a wider forum.
[14:08] <pitti> persia: I did hear about it (in fact it was me who started the process, remember? :) )
[14:08] <pitti> persia: but I wasn't aware of tag sharing
[14:08] <pitti> might just be me not reading the wiki page hard enough
[14:08] <_StefanS_> BenC: sorry but CONFIG_HIGHMEM4G=y is not /boot/config-2.6.24-3-generic :(
[14:09] <persia> pitti: Yes.  It was you who started, but the total documentation from ~motu-sru was the wiki page update.  I suspect a mail to u-d@l.u.c or something might be helpful to make sure people were more generally aware.
[14:09] <asac> pitti: thanks for the prodding. I have ubutfox/apturl upload on my list
[14:09] <pitti> persia: please include the tag issue in the mail, too; thank you!
[14:09] <pitti> asac: great, thanks
[14:09] <BenC> _StefanS_: I just checked it in our config files from the git repo...not sure why it wouldn't be there
[14:09] <_StefanS_> BenC: really odd..
[14:10] <persia> pitti: I'll ask, but as I'm not a member, it will likely come second-hand, so no promises :)
[14:10] <BenC> _StefanS_: are you sure that's 32-bit?
[14:10] <BenC> _StefanS_: I just checked my system, and it's there
[14:10] <_StefanS_> BenC: argh.. I'm an idiot. I'm on amd64 right now...
[14:11] <_StefanS_> BenC: sorry for wasting your time :D
[14:11] <BenC> _StefanS_: no problem :)
[14:15] <pitti> ScottK: is the libfile-temp-perl MIR still relevant? is there a decision wrt. using perl from experimental with updated modules, or keeping separate ones, etc?
[14:16] <DarkSun88> Hi all
[14:16] <ScottK> pitti: There is no decision as far as I know.  I'd appreciate you approving it so the larger Perl question doesn't block my progress on amavisd-new.  I promise I'll let you know if it end up being able to be demoted again.
[14:17] <pitti> ScottK: ok, I see; in that particular case I don't mind much, it's a pretty harmless package
[14:17] <ScottK> pitti: Thanks.
[14:18]  * ScottK is almost done.  I think I've got one more Perl module and then libmilter to deal with.
[14:32] <Keybuk> pitti: interesting bug with SD card reader ... the card gets mounted twice at /media/disk and /media-disk-1
[14:32] <Keybuk> /media/disk is /dev/mmcblk0p1 while /meda/disk-1 is /dev/mmcblk0
[14:32] <Spads> Once for casual, once for formal.
[14:33] <mjg59> mmcblk0?
[14:33] <mjg59> How is that mountable?
[14:33] <pitti> Keybuk: hm, is there a proper partition table on it? sounds like the card has once been formatted without partitions
[14:33] <mjg59> Yeah, there's something screwed with that card. It shouldn't be possible to mount the entire device if it contains a partition table
[14:33] <Keybuk> it may be formatted without partitions, yes
[14:33] <mjg59> If it's formatted without partitions, mmcblk0p1 wouldn't exist
[14:33] <ion_> If that is the case, there probably shouldn’t be a ...p1
[14:34] <Keybuk> it claims to have a partition table
[14:34] <mjg59> The blk0 shouldn't be mountable, and if it is there's something screwed with the layout
[14:35] <ion_> What do e.g. hexdump -C /dev/mmcblk0 | head and hexdump -C /dev/mmcblk0p1 | head output?
[14:35] <Keybuk> let me try dd if=/dev/zero on the card then
[14:37] <LucidFox> pitti> Regarding inkblot...
[14:38] <LucidFox> the files eggtrayicon.c and eggtrayicon.h are "Lesser GPL v2 or later", but v2 is actually Library GPL - it was renamed to Lesser in 2.1. Which version should I include into the orig.tar.gz?
[14:39] <Keybuk> LucidFox: whatever upstream included
[14:39] <LucidFox> Upstream only includes the GPL.
[14:39] <Keybuk> then ask upstream to fix it
[14:39] <LucidFox> I will.
[14:39] <LucidFox> (By the way, so does rhythmbox despite also including these files.)
[14:39] <mjg59> They're not interestingly LGPL if they're in a GPL codebase
[14:40] <mjg59> So just ignore it
[14:42] <persia> You could also explicitly indicate that when you are licensing the code to Ubuntu (as the initial packager), the files previously licensed under LGPL are relicensed under GPL, to be safe, and Ubuntu would then license to users as GPL.
[14:42] <LucidFox> Ah.
[14:44] <mjg59> LGPL is only compatible with GPL because it contains a clause saying it can be used under the GPL
[14:44] <mjg59> It otherwise contains restrictions that aren't present in the GPL
[14:44] <mjg59> So, in the context of a GPLed work, it's GPLed
[14:44] <mjg59> The fact that it also claims to be provided under some other license is unimportant
[14:46] <Keybuk> mjg59: doesn't the LGPL require us to change the notices if we do that?
[14:46] <persia> Keybuk: For the individual files?  Surely we only have to write a note for the work as a whole.
[14:47] <cjwatson>   3. You may opt to apply the terms of the ordinary GNU General Public
[14:47] <cjwatson> License instead of this License to a given copy of the Library.  To do
[14:47] <cjwatson> this, you must alter all the notices that refer to this License, so
[14:47] <cjwatson> that they refer to the ordinary GNU General Public License, version 2,
[14:47] <cjwatson> instead of to this License.
[14:47]  * persia retracts the erroneous statement
[14:47] <cjwatson> gnulib gets this right
[14:47] <mjg59> cjwatson: Hm. I wonder if that's actually the intention.
[14:47] <cjwatson> (well, modulo stupid sed script bugs)
[14:48] <mjg59> cjwatson: Since surely that means that you'd have to provide an LGPLed version and a GPLed version of a library
[14:48] <cjwatson> mjg59: if you use gnulib-tool to import library files into a GPLed project, it seds the licence notices to remove "Lesser"
[14:48] <cjwatson> I believe this is FSF-approved ...
[14:48] <mjg59> cjwatson: What if they're dynamically linked?
[14:48] <cjwatson> gnulib isn't
[14:48] <persia> mjg59: Why?  The LGPL explicitly grants the right to relicense under GPL, no?
[14:48] <cjwatson> mjg59: but yes, in that case I don't know :-)
[14:48] <mjg59> persia: Yes, but according to section 3 only if you remove the LGPL header
[14:48] <Keybuk> persia: it only grants that right if you modify the notices, see above ;)
[14:49] <mjg59> And if you do that, you can no longer use it in anything other than GPL-compatible works
[14:49] <ScottK> persia: Additionally, a special license for Ubuntu wouldn't be in the spirit of DFSG.
[14:49] <persia> Right.  dynamic linking for a "combined work" such as our install CD.
[14:49] <cjwatson> LGPL 3 seems to fix this bug
[14:49] <mjg59> In reality, I think the answer is "Ignore the issue"
[14:49] <cjwatson> it just says:
[14:49] <cjwatson>    b) under the GNU GPL, with none of the additional permissions of
[14:49] <cjwatson>    this License applicable to that copy.
[14:49]  * persia stops contributing to this discussion, glad not to be counsel for this issue.
[14:49] <mjg59> Since the alternative is misery
[14:50] <cjwatson> persia: the install CD is an aggregate under the meaning of the GPL
[14:50] <cjwatson> certain things *on* the install CD might be combined workds
[14:50] <cjwatson> works
[14:50] <cjwatson> (indeed, are)
[14:50] <persia> cjwatson: Even at runtime when it dynamically links?
[14:50] <mjg59> However, the FSF claim that a binary is a derivative work of any of the libraries it dynamically links against
[14:50] <Keybuk> I still want the install CD to be "everything normally distributed with the operating system" ;-)
[14:50] <mjg59> Keybuk: You can argue that, but you don't get any special exceptions for anything shipped on the CD then
[14:50] <cjwatson> persia: again, certain things on the install CD are. The install CD as a unit is mere aggregation
[14:51] <Keybuk> cjwatson: the LGPL-3 is delightfully elegant in that it's a patch to the GPL-3
[14:51] <cjwatson> persia: the whole install CD is not dynamically linked by any reasonable definition
[14:51] <cjwatson> Keybuk: yes, it's a lot neater than 2.x
[14:51]  * persia isn't hiding well
[14:52] <persia> cjwatson: Sure.  The CD is clearly not a violation, and distributing it very likely not.  Using it might be a different issue, but users aren't usually distributing the use, so it might not matter.  Anyway, exactly what would be meant by "distributing the use" is not a question I am currently informed enough to discuss.
[14:52] <mjg59> persia: No, individual parts of the CD may be violations.
[14:53] <mjg59> But the install CD is, itself, irrelevant. The only difference between it and the archive is aggregation.
[14:53] <cjwatson> under the GPL use is explicitly never a violation
[14:53] <cjwatson> other licences may be different (although obviously I rather hope nothing on the install CD has serious use restrictions!)
[14:57] <\sh> ogra: ping
[14:57] <\sh> ogra: you didn't give my mobile number to anybody, let's say a recruiter of your company?
[14:57] <ogra> \sh, nope
[14:57] <ogra> you know i'd never do that, right ?
[14:58] <ogra> well, you obviously dont else you wouldnt have asked :)
[14:58] <\sh> ogra: just asking...wondering from whom he got my mobile number :)
[14:58] <Hobbsee> \sh: plenty of ubuntu people probably have your #
[14:58] <\sh> Hobbsee: nope....
[14:58] <LucidFox> So, in short... what would be preferable to do for the inkblot package, and what should I tell upstream?
[14:58] <\sh> hopefully he had used my imprint
[14:58] <jsgotangco> maybe you added it on facebook heh
[14:58] <Keybuk> cjwatson: sadly the piece of my soul that cared about licences has now died, since I have released, under Canonical's policy, a piece of software under the GPL-3
[14:58] <\sh> jsgotangco: nope :) he only could have it from my imprint...
[14:59] <markvandenborre> I should really have asked over here before sending in https://bugs.launchpad.net/ubuntu/+bug/182028
[14:59] <ubotu> Launchpad bug 182028 in ubuntu "evince and eog freeze on all printing related actions" [Undecided,New]
[14:59] <markvandenborre> is there anything that I can do to improve this bug report?
[14:59] <LucidFox> markvandenborre> I think #ubuntu-bugs would be a better place to ask :)
[14:59] <markvandenborre> sorry
[15:00] <LucidFox> nothing to feel sorry for, just saying
[15:00] <markvandenborre> and thanks for the hint!
[15:00] <mjg59> LucidFox: Just upload it as is. Upstream are unlikely to be in a position to change the copyright headers on eggtrayicon.c.
[15:01] <LucidFox> Well, it was rejected as it was - that's why I came asking in the first place
[15:01] <Keybuk> mjg59: I think we mark that down as "one of those clauses we silently ignore"
[15:01] <Keybuk> just the that nice one in the GPL about describing every change :)
[15:03] <mjg59> LucidFox: Who by?
[15:03] <LucidFox> by pitti
[15:03]  * mjg59 shrugs
[15:04] <LucidFox> https://lists.ubuntu.com/archives/ubuntu-archive/2008-January/014051.html
[15:04] <mjg59> Upstream aren't the copyright holders of the file concerned in this case
[15:04] <pitti> well, I didn't ask for changing copyright headers
[15:04] <mjg59> Oh, I see
[15:04] <pitti> just adding the LGPL to the orig.tar.gz, since the headers refer to it
[15:04] <mjg59> pitti: If they're incorporated into a GPLed work, they're not under the LGPL
[15:04] <LucidFox> yes, and I wanted to know which version of the LGPL :)
[15:05] <pitti> mjg59: ah, so that's an instance of 'GPL swallows LGPL'
[15:05] <mjg59> pitti: I'd assume so, yeah.
[15:05] <pitti> LucidFox: ok; let me look at it again
[15:05] <mjg59> You could argue it's really "GPL plus extra permissions" for those files, but I don't think it's inherently a showstopper
[15:06] <pitti> LucidFox: ok, fished out of rejected, and accepted
[15:07] <LucidFox> Thanks!
[15:07] <pitti> thanks all for the heads-up
[15:17]  * minghua is further convinced that he shouldn't be giving license-related counsel, after reading the discussion.
[15:40] <mathiaz> jdstrand: Do you think it's a good idea to enable the mysql test suite by default when building the package ?
[15:46] <cjwatson> bryce: http://people.ubuntu.com/~bryce/Plots/ doesn't seem to work in firefox-3.0 ... help? is it possible it needs to be declared as XHTML?
[15:46] <cjwatson> firefox-3.0's view source highlights it wrongly as well
[15:47] <pitti> mathiaz: oh, that would be nice; maybe add a DEB_BUILD_OPTIONS=nocheck support for the occasional local test build?
[15:47] <mathiaz> pitti: the new debian version has the test suite enable by default.
[15:48] <mathiaz> pitti: I just remember that it takes ages to run. But I guess it doesn't matter for the buildd.
[15:48] <pitti> right
[15:48] <pitti> that's why 'nocheck' is a good idea IMHO
[15:49] <Keybuk> that's very pretty output for gnuplot
[15:49] <mathiaz> pitti: yeah - seems good. I'll add it.
[15:51] <jdstrand> mathiaz: no-- its known to fail
[15:51] <jdstrand> mathiaz: I have which test are supposed to fail in package-tests
[15:51] <jdstrand> mathiaz: s/supposed/expected/
[15:54] <mathiaz> jdstrand: hum - the debian maintainer enabled them in 5.0.51
[15:55] <jdong> pitti: thanks for your review of mpeg4ip, I'll get those things fixed up :)
[15:55] <pitti> jdong: thanks
[15:55] <jdstrand> mathiaz: maybe they don't have any expected failures in 5.0.51
[15:56] <jdstrand> mathiaz: that would be great
[15:56] <jdstrand> (I haven't built 5.0.51 yet)
[15:56] <mathiaz> jdstrand: I think. I'll give it a try.
[15:56] <mathiaz> jdstrand: I'm currently merging it.
[15:56] <jdstrand> mathiaz: if they do not fail, then I am all for enabling the test suite-- though it takes a *long* time
[15:57] <jdstrand> mathiaz: well-- hold on a sec
[15:58] <jdstrand> mathiaz: ah yes-- tests are known to fail if run in parallel
[15:58] <jdstrand> mathiaz: ie if building in chroots on the same machine for different releases
[15:59] <jdstrand> mathiaz: eg feisty and gutsy are both building and run the tests at the same time, one may cause the other to fail
[16:00] <jdstrand> mathiaz: s/run the tests/run the test suite/
[16:00] <mathiaz> jdstrand: ok - is this something that happens often ?
[16:00] <pitti> that's the same for postgresql
[16:00] <mathiaz> jdstrand: I mean on the buildds
[16:00] <pitti> it doesn't happen on the buildds, though
[16:01] <pitti> mathiaz: no, that's fine; it's just an issue with parallel local builds
[16:01] <mathiaz> pitti: ok - and that could be solved with a DEB_BUILD_OPTION
[16:01] <mathiaz> pitti: set to notest
[16:48] <LucidFox> pitti> inkblot has been published in main...
[16:49] <LucidFox> notwithstanding the fact that it never underwent a MIR, it depends on a library in universe
[16:50] <pitti> LucidFox: ah, forgot to override it when rescuing it from rejected; thanks for the ping, fixed
[16:51] <spacey> bug #133635
[16:51] <ubotu> Launchpad bug 133635 in ltsp "LTSPFS security is broken" [Undecided,Fix released] https://launchpad.net/bugs/133635
[17:43] <ScottK> pitti: Would you have a moment to accept clamav in feisty-backports?  It fixes a remote code execution bug in the current package, so I'd like to get it out soonish...
[17:56] <pitti> ScottK: accepted, thanks
[17:56] <ScottK> pitti: Great.  Thank you.
[18:05] <bryce> cjwatson: yea pitti mentioned the ff3 issue with the plots; I just haven't had a spare moment to look into it.  I'll try to get to it today
[18:37]  * Keybuk beats HAL into a bloody pulp
[18:37] <Keybuk> STOP MOUNTING THE DAMNED SD CARD TWICE
[18:39] <selckin> kick it
[18:39] <sladen> just because HAL capitalised, doesn't mean EVERYTHING ABOUT IT has to be
[18:40] <sladen> is capitalised
[18:41] <Keybuk> WHY DO FREEDESKTOP PEOPLE SHOULD ABOUT D-BUS, HAL AND X ALL THE TIME?
[18:41] <Keybuk> (ok, that last one was kinda cheating :p)
[18:42] <mjj29> the correct spelling/capitalization is actually D-Bus
[18:44] <Keybuk> it used to be D-BUS
[18:46] <ion_> Now it’s BusKit
[18:46] <pochu> lol
[18:46] <sladen> "Buskit is a small charity based in Central Scotland"
[18:47] <sladen> "Google: did you mean:  bizkit dbus"?
[18:47] <sladen> I like biscuits
[18:53] <Keybuk> ok
[18:53] <Keybuk> I'm clearly going to just have to write an fdi file to deal with this
[18:53] <Keybuk> the GPS won't accept any SD card formatted by anything other than itself
[18:54] <Keybuk> and the way it formats it confuses HAL
[20:01] <LaserJock> somerville32: congrats on the breakage ;-)
[20:13] <minghua> LaserJock: About the spell checking topic yesterday -- no, it doesn't require learning Asian language, but it requires installing input method packages and a hand compiled (i.e. not packaged yet) IM module.
[20:13] <LaserJock> ewww
[20:14] <LaserJock> I just started xchat instead
[20:14] <minghua> LaserJock: And it's not that useful anyway -- it gets in the way of typing too much.
[20:15] <LaserJock> minghua: perhaps I just need to relearn how to spell ;-)
[20:47] <cdm10> I'm wondering whether the Update/Upgrade Manager is from upstream or from Ubuntu?
[20:48] <LaserJock> cdm10: Ubuntu I believe
[20:48] <cdm10> LaserJock: I noticed some UI issues with it.
[20:48] <LaserJock> file bugs
[20:48] <cdm10> ok
[20:49] <cdm10> should I ask #ubuntu-desktop first to see if it's intentional?
[20:50] <LaserJock> you could ask here real quick
[20:51] <LaserJock> I'm not sure how many people are paying attention in #ubuntu-desktop at this hour
[20:51] <cdm10> alright.
[20:51] <cdm10> I'm just wondering whether it's intentional that the Distribution Upgrade progress interface is different from the Updates interface.
[20:51] <cdm10> When you do a Partial/Full Upgrade, you see a box with the steps of the process, and that same window stays there for the entire process.
[20:52] <cdm10> Normal updates show a window for downloading the packages, and when that's done, it's replaced by a window that shows the installation progress.
[20:54] <LaserJock> hmm, I *think* that is intentional, but you might ask mvo about it
[20:54] <somerville32> If it isn't intentional, they were coding with a blind fold on :P
[20:55] <cdm10> The thing is, it's inconsistent, and doesn't seem to make sense...
[20:55] <cdm10> mvo?
[20:55] <LaserJock> http://launchpad.net/~mvo
[20:56] <LaserJock> the guy that wrote it
[20:56] <cdm10> LaserJock: Alright, should I directly contact him?
[20:56] <LaserJock> sure, if you have a question :-)
[20:56] <cdm10> alright
[20:56] <LaserJock> it seems like proper behavior to me, but ....
[20:57] <cdm10> LaserJock: is email or IRC preferred?
[20:57] <LaserJock> well, he's not on IRC at the moment I don't think
[20:57] <cdm10> yeah, just checked. I'll email.
[20:57] <somerville32> I think it is sane to me too
[20:58] <somerville32> Distribution upgrades is NOT the same thing
[20:58] <LaserJock> there really different "things" and so to me it makes sense that the windows don't do the same thing
[20:58] <somerville32> The different UI is a big fat clue that you're doing something different
[20:59]  * LaserJock notes that wallpaper not being there is a big fat clue too ;-p
[20:59]  * somerville32 coughs.
[21:03] <somerville32> Thinking about it, not having the the wallpaper on Alphas might be a good idea
[21:03] <LaserJock> heh ... suuure
[21:03] <LaserJock> "I planned it all along"
[21:03] <somerville32> Helps distinguish it as an Alpha :)
[21:04] <cdm10> somerville32: about the distribution upgrades not being the same thing... it's fine if it distinguishes it with text, but imo, using an inferior UI to display normal update progress just to differentiate them isn't a great idea...
[21:04] <LaserJock> inferior?
[21:04] <cdm10> Well, it uses multiple windows
[21:04] <LaserJock> why is that bad?
[21:04] <somerville32> So you think that the normal UI is inferior?
[21:04] <cdm10> Well, it's a matter of opinion, but yes.
[21:05] <somerville32> cdm10, You might talk to TheSheep. He is a UI expert :)
[21:05] <cdm10> The checkbox window used by the dist-upgrade progress box makes it clear that package-downloading isn't the only step in the process... the normal one doesn't indicate that there's going to be another window popping up with a NEW progress bar after the current one is full.
[21:05] <mjg59> cdm10: The stages listed in the distribution update don't apply to a normal update
[21:06] <cdm10> mjg59: yeah, but at least two do...
[21:06] <cdm10> downloading and installing.
[21:06] <mjg59> Only two
[21:06] <cdm10> Well, I'm not saying that the exact same UI has to be there... but they should at least be similar.
[21:06] <somerville32> I don't see why they should be
[21:06] <LaserJock> heh, they're both gtk ... I thought they were similar ;-)
[21:07]  * LaserJock obviously doesn't understand the finer points of UI design
[21:07] <cdm10> LaserJock: I'm not saying that :)
[21:07] <somerville32> Neither do I, lol
[21:08] <cdm10> I'm just stating my opinion. The bigger issue, imo, isn't the inconsistency, but the problem of ambiguity in the normal one.
[21:08] <LaserJock> ambiguity of what?
[21:08] <LaserJock> rather, what is ambiguous?
[21:09] <cdm10> LaserJock: when you begin the update process, the main window disappears and a progress window appears. The progress window has one progress bar. When that progress bar is full (indicating that the process is finished), another window comes up, with a new progress bar. That's unexpected, and could be annoying for a user who's expecting their updates to be finished when the progress bar reaches the end.
[21:09] <cdm10> Also, when the second window pops up, it steals focus.
[21:10] <LaserJock> the stealing focus part makes sense, I've had problems with that in the past
[21:10] <LaserJock> the progress bar thing though, I guess I"m just used to synaptic
[21:11] <cdm10> LaserJock: So am I, so i've come to accept it... but it just seems that the design used in the upgrade progress window makes more sense, and shows a more complete picture of the process to the user. Also, it's closer to the Golden Ratio :) and it solves the problem of focus-stealing by only using one window.
[21:13] <LaserJock> well, I think there are probably practical reasons why it is the way it is
[21:14] <cdm10> LaserJock: It probably has something to do with using Synaptic's built-in progress thingies.
[21:14] <LaserJock> the normal updater is just basically a synaptic-like frontend whereas I think the distribution upgrader is more "from scratch", but I could be wrong
[21:14] <cdm10> whereas it seems that the Upgrade thingy is original Ubuntu stuff.
[21:14] <LaserJock> exactly
[21:14] <cdm10> Anyway, it's just a small nit-picky thing I just noticed :)
[21:14] <LaserJock> so perhaps synaptic could use some UI changes ;-)
[21:14] <cdm10> That's probably true
[21:15] <cdm10> I actually noticed something else. If Ubuntu is going to be using mixed gksudo-PolicyKit for a while, they should be modified to look similar.
[21:15] <LaserJock> in any case, mvo will be able to give you a much better discussion about it
[21:15] <cdm10> yep.
[21:16] <cdm10> I have a question about PolicyKit.
[21:16] <cdm10> I can see why it can be useful to have an unlock button that unlocks some additional functionality in an application that does both user-specific and system-wide tasks.
[21:16] <cdm10> However, things like the Network management applet can't function at all without privileges, so I don't see why they don't just try to get themselves unlocked right away, rather than having the user push Unlock.
[21:24] <cdm10> Did I miss anything about PolicyKit while I was gone?
[21:28] <Riddell> cdm10: no, pitti the policykit guy isn't here
[21:30] <LaserJock> Riddell: is adept still used for update notification in Hardy?
[21:34] <Riddell> LaserJock: yes
[21:38] <cdm10> Riddell: ah, ok, I'll see if I can talk to him about it