[00:00] <RAOF> tkooda: Does it work if you use dpkg-buildpackage -rfakeroot?
[00:01] <tkooda> nope.  `dpkg-buildpackage -rfakeroot` fails (both as user and root)
[00:02] <tkooda> ..also seems kinda* odd that the package version is 1.6.0, but the sources are 1.7.2..
[00:03] <tkooda> it dosn't appear to use fakeroot by default, either
[00:03] <StevenK> tkooda: Which means 1.7.2-1 was automatically synced from Debian, but it doesn't build.
[00:04] <RAOF> Oh, yeah.  Looks like runit's been failing to build since 1.5.1-1 :)
[00:04] <tkooda> heh
[00:04] <tkooda> solution?
[00:04] <RAOF> At least on x86-64.  i386 may vary :)
[00:04] <tkooda> i386 failing here
[00:04] <jdong> RAOF: where does it fail?
[00:04] <tkooda> in the check
[00:04]  * jdong builds it for fun
[00:04] <tkooda> Checking runsv...
[00:04] <tkooda> Segmentation fault
[00:04] <RAOF> Find out why it FTBFS, fix it, attach a debdiff to a bug?
[00:05] <jdong> /tmp/tranny/runit-1.7.2/admin/runit-1.7.2/src/runsv.check: line 4: 18062 Segmentation fault      (core dumped) runsv
[00:05] <jdong> how lovely.
[00:05] <tkooda> heh
[00:05] <RAOF> That'd be in make check, right?
[00:05] <tkooda> google turned up some very old suggestion about omitting "-fomit-frame-pointer"?
[00:05] <tkooda> raof, yes
[00:05] <StevenK> So disable make check, and it'll build?
[00:05]  * StevenK hides
[00:05] <tkooda> heh
[00:05]  * RAOF hunts
[00:07] <StevenK> RAOF: For the segfault, or me? :-)
[00:08] <RAOF> For *you*.
[00:09] <RAOF> I'd suggest gdb for the segfault, unless their code is fragile enough that leaving the frame pointer in fixes it.
[00:09] <StevenK> Which just points the finger at upstream being unable to code.
[00:10] <RAOF> Actually, if their code's fragile enough that it doesn't work unless the frame pointer doesn't get removed, I'd seriously consider using something else.
[00:10] <StevenK> Like upstart? :-)
[00:10] <RAOF> Oh, wow.
[00:10]  * RAOF actually reads package description.
[00:11] <RAOF> Something called "runit" *should* be a unit testing framework :P
[00:11]  * StevenK cackles
[00:11] <ajmitch> nah
[00:11] <ajmitch> 'run' 'it' :)
[00:12] <RAOF> EPARSE
[00:12] <ajmitch> apart from the fact that there are 20 other testing frameworks all ending in unit
[00:12] <RAOF> And xUnit is a whole family of them.
[00:12] <tkooda> any chance of getting a patch for "https://bugs.launchpad.net/ubuntu/+source/runit/+bug/74135" merged at the same time?  (inittab -> upstart)
[00:12] <ubotu> Launchpad bug 74135 in runit "runsvdir does not use upstart" [Medium,Confirmed]
[00:12] <ajmitch> perhaps runit should be called runstuff?
[00:13] <RAOF> So why would one want to use runit?
[00:13] <tkooda> I don't care if it's called bannanna-ramma, as long as the damned thing builds.  :P
[00:15] <jdong> ajmitch: and run it is trademarked in the USA too ;-)
[00:15] <RAOF> tkooda: You're very welcome to fix the FTBFS, apply whatever (sane) patches you like, and attach a debdiff to a bug :)
[00:15] <StevenK> Why anyone would want to switch to runit from upstart is beyond me
[00:16] <Keybuk> mmm, djb config files
[00:16] <tkooda> RAOF, I'll try my hand at a debdiff
[00:17] <tkooda> StevenK, no.  running runit from* upstart.
[00:17] <tkooda> (vs inittab)
[00:18] <StevenK> tkooda: I still fail to see your reason.
[00:20] <RAOF> Especially since their test program segfaults.  That's not what *I* look for in my init program :)
[00:20] <StevenK> Muahaha
[00:21] <tkooda> not runit-as-process-1, but having upstart launch runit to run my numerous daemontools/runit service dirs.
[00:22] <StevenK> tkooda: But upstart can do that itself
[00:22] <tkooda> can upstart do seperate logging processes per-service like runit+svlogd?
[00:26] <tkooda> upstream runit-1.7.2 builds+checks okay..  wtf is going wrong in the build process to cause the check to segfault?
[00:29] <mathiaz> ScottK: you mentionned at UDS that cyrus sasl should be dropped from main, and dovecot sasl should be used instead. Why ?
[00:29] <tkooda> StevenK, upstart can let me pipe the output of a service to another process (that it runs+supervises)?
[00:31] <StevenK> tkooda: upstart can supervise itself, but logging I'm unsure about
[00:37] <tkooda> I don't think I have the time/skill to fix the 'runit' FTBFS.. so I guess it'll just stay broken until the package maintainer get's around to it (last mod was ~1yr ago?)
[00:39] <jdong> tonyyarusso: does the hardy version build?
[00:39] <tonyyarusso> jdong: err, misfire?
[00:39] <jdong> yes
[00:39] <jdong> tkooda:
[00:39] <jdong> WHOA it's the funniest thing ever
[00:40] <jdong> FTBFS on everything *but* ia64 and lpia
[00:40] <LaserJock> that's a bit different
[00:40] <tonyyarusso> weird
[00:40] <jdong> hardy's ver still segfaults
[00:40] <RAOF> Reverse FTBFS :)
[00:41] <ion_> :-)
[00:42] <jdong> ooh let's just remove the check!
[00:42] <jdong> (joking, joking)
[00:43] <jdong> tkooda: you are saying make check does NOT die upstream?
[00:53] <tkooda> jdong, correct.
[00:53] <jdong> I don't see how that's even possible
[00:53] <jdong> we aren't mangling the source at all
[00:54] <jdong> unless the sources don't match up with upstream's version
[00:54] <tkooda> jdong, runit_1.7.2.orig.tar.gz from packages.u.o builds+checks even.
[00:54] <jdong> what??
[00:54] <tkooda> (manually, not with the dpkg-source && dpkg-buildpackage)
[00:54] <jdong> so start cutting things out of debian/rules one by one
[00:54] <jdong> until something solves it
[01:16] <tkooda> jdong, done:  http://devsec.org/tmp/runit-1.7.2.buildfix-1.diff  <-- "fixes" FTBFS in runit-1.7.2; just cheap trick of using gcc instead of diet
[01:23] <ScottK> mathiaz: Since we already support dovecot for MDA, we might as well switch to use dovecot for SASL and it's that much less to deal with.
[01:24] <ScottK> mathiaz: Dovecot is (I've heard) generally easier to get set up and working.
[01:29] <mathiaz> ScottK: ok. Do you know if dovecot implementation is API-compatible with Cyrus implementation ?
[01:33] <slangasek> does it support all the SASL methods that cyrus does?
[01:35] <mathiaz> slangasek: good question. I don't know. Postfix can be built with Dovecot's Sasl implementation.
[01:35] <mathiaz> slangasek: same for exim. It may prove that the dovecot implementation is robust enough.
[01:36] <mathiaz> slangasek: and I've just found this page: http://wiki.dovecot.org/Authentication/Mechanisms
[01:36] <slangasek> ok
[01:36] <slangasek> seems to cover everything I care about :)
[01:40] <jdong> tkooda: heh I don't know about the correctness of that as a fix though; probably should poke the Debian maintainer
[01:42] <tkooda> heh
[01:43] <tkooda> maintainer is upstream author
[01:44] <jdong> yeah him too
[01:44] <mathiaz> slangasek: about bug 163194 - do you plan to fix it in debian also ?
[01:44] <ubotu> Launchpad bug 163194 in samba "need option to disable creation of lanman hashes" [Undecided,New] https://launchpad.net/bugs/163194
[01:44] <tkooda> don't got much more time right now to nudge..  perhaps later (read: likely never??)
[01:47] <lamont> and theoretically, postfix is built with dovecot support.  maybe.
[01:47]  * lamont hates sasl.
[01:47] <lamont> or rather, I hate not having figured it out
[01:49] <jdong> tkooda: it builds correctly on debian and we are using the same sources, so I'd suspect it's a diet bug
[01:50] <jdong> tkooda: or toolchain differences
[01:50] <tkooda> k
[01:51] <tkooda> odd.  it appears to pass the compile successfully, but just not the check.
[01:52] <tkooda> (I would have expected any diet bug to rear it's head in the compile step)
[01:53] <jdong> tkooda: segfaults in hardy in the same way, and we use same dietlibc in hardy as Debian where it buidls correctly
[01:53] <jdong> I'm out of hunches
[01:55] <tkooda> sounds like a dietlibc issue then? -wonder how that got through?
[01:55] <tkooda> (or perhaps a compile flag that shouldn't be used anymore??)
[01:57] <ScottK> mathiaz: I know Postfix is packaged to work for both SASL implementations.  Dunno about other users.
[02:01] <slangasek> mathiaz: well, I expected that adding an option for it was something to be pushed upstream, but that's already done... as far as making the change to the default in Debian, that's a policy change that needs to be discussed with the rest of the team first
[02:03] <slangasek> ScottK: in what sense is it packaged to work for both? the postfix binaries are linked against cyrus sasl...
[02:04] <ScottK> slangasek: It's been a while since I looked.  I thought it supported both.  Let me look into it.
[02:04] <ScottK> Postifx upstream definitely supports both (at least at compile time).
[02:06] <lamont> ScottK: if we don't support both, I'd love to.  ISTR checking and finding that it would
[02:06] <slangasek> so how does it support both dynamically?
[02:06] <slangasek> (and why would dovecot be supported by dlopen, but cyrus by linking? :)
[02:14] <lamont> postconf -a
[02:14] <lamont> cyrus
[02:14] <lamont> dovecot
[02:15] <lamont> man postconf
[02:15] <lamont>  -a     List  the available SASL server plug-in types.
[02:16] <StevenK> lamont: When did -a hit postconf?
[02:17] <lamont> uh...
[02:17] <StevenK> lamont: It's not on my Dapper machine, which is why I ask
[02:17]  * lamont goes looking
[02:21] <lamont> 2.3 introduced it.
[02:21] <lamont> so look at edgy and beyond.
[02:22] <slangasek> ah, the difference is that dovecot uses an authentication server rather than a plugin, hmm
[02:22]  * slangasek looks at this design skeptically
[02:23] <lamont> slangasek: fwiw, uploading util-linux 2.13-11ubuntu1 to hardy, will upload a sync'ed bsdmainutils once panthera uploads to debian
[02:23] <lamont> and yes, he's expecting it
[02:23] <slangasek> ok
[02:24] <lamont> Conflicts: bsdmainutils (<<6.1.9)
[02:25] <lamont> and yeah, 6.1.9 is actually the current version in sid.
[02:25] <lamont> so I probably screwed up
[02:25] <slangasek> hrm, isn't there supposed to be a Replaces: with that too?
[02:26] <lamont> bsdutils no longer delivers any binaries that it didn't in 2.12r --> nothing that bsdmainutils delivers
[02:26] <lamont> ergo, no Replaces any more
[02:26] <slangasek> oh
[02:26] <slangasek> then why does it need to conflict either?
[02:26] <lamont> to force the upgrade issue, I suppose
[02:26] <lamont> should it not conflict either?
[02:27] <lamont> hrm... time for this one to go home.
[02:27] <slangasek> I can't see any reason it should conflict, and don't understand how a conflict would help force an upgrade
[02:27] <lamont> I'll pick up the conversation when I get home... it could be that I'm being a muppet.
[02:27] <lamont> and then I'll get to upload -12 to debian. :-)
[02:27] <lamont> will ponder while driving
[02:31]  * lamont finishes pondering, uploads -12
[02:47] <Hobbsee> dear update manager, why do you insist on keeping on stealing focus?
[02:47] <Hobbsee> i dont need to know that you've finished downloading packages, and are now installing them
[02:48] <jdong> Hobbsee: compiz?
[02:49] <Hobbsee> yes
[02:49]  * jdong points your-fault finger at Amaranth ;-)
[02:49] <jdong> compiz focus stealing protection is umm...... not there.
[02:50] <StevenK> Compiz focus stealing protection has been stolen
[02:50] <Amaranth> It breaks in metacity too
[02:51] <jdong> one could say Compiz has ADD.
[02:51] <StevenK> jdong: We knew that
[02:53] <jdong> hmm, does /upgrade kill my connection....
[02:54] <jdong> whoa I'm still alive!
[02:54] <jdong> I think
[02:54] <jdong> why is Samba still broken?
[02:55] <lamont> ah, one more reason I won't run compiz.
[02:55] <lamont> neat
[02:55] <lamont> not that there was much risk of that anyway
[02:56]  * Hobbsee wonders what the xorg change was
[03:00] <jdong> *sigh* thanks fglrx for hardlocking on me.
[03:01] <RAOF> Bwa ha!
[03:01]  * RAOF points and laughs.
[03:01] <jdong> :P
[03:02] <slangasek> jdong: which samba where?
[03:03] <jdong> slangasek: the one in the topic
[03:03] <slangasek> er, ok
[03:03] <jdong> we should probably take that out, right?
[03:03] <slangasek> yep
[03:03] <jdong> better :)
[04:53] <LaserJock> ok, for translations to be shipped does a .pot have to be included in the source package?
[04:56] <minghua> LaserJock: To be shipped where?
[04:57] <LaserJock> in the lang packs
[04:59] <minghua> I don't quite know how Rosetta works, but I think the answer is yes.
[04:59] <minghua> #launchpad is the right place to ask, I think.
[04:59] <LaserJock> perhaps
[05:00] <LaserJock> I'm trying to figure out the packaging
[05:00] <LaserJock> my package has .po files and ships .mo files
[05:00] <LaserJock> but no .pot
[05:00]  * Hobbsee wnoders if you have to use the kde pot file patch
[05:01] <LaserJock> Hobbsee: well, it's a Gnomish app so I wouldn't think so
[05:01] <LaserJock> ;-)
[05:01] <Hobbsee> i doubt it's kde specific, it's just called that
[05:02] <LaserJock> hmm, I wonder where I'd find it
[05:03] <Hobbsee> http://kubuntu.org/~jriddell/kubuntu_01_kdepot.diff
[05:03] <Hobbsee> oh, hang on, it loosk specific
[05:03] <LaserJock> yeah
[05:03] <TiMiDo> wow, the launchpad is sure lacking a lot,
[05:04] <LaserJock> I'm thinking I just need to something in debian/rules that generates a .pot
[05:07] <minghua> LaserJock: "cd po; make <package-name>.pot" usually should give you the POT file.
[05:07] <minghua> LaserJock: But it's really something should be done by upstream.
[05:07] <mpt> TiMiDo, can you be more specific? :-)
[05:10] <LaserJock> minghua: I wonder if I need to put that in the .diff.gz or do it at build time
[05:15] <LucidFox> If a bug is in the stable Ubuntu release but fixed in the development release, can I mark it as fixed?
[05:15] <Hobbsee> yes
[05:16] <Hobbsee> mpt: i warn you, incidently, if you *ever* break keescook's autoreply script for launchpad, you (collectively) run the great risk of being imminently killed.
[05:16] <Hobbsee> just in case you were wondering :)
[05:17] <minghua> LaserJock: I don't think it makes much difference, unless you do some tricky things to the timestamps.
[05:21] <mpt> Hobbsee, I have no idea what you're talking about, but I do know that's not a good way to express it
[05:22] <Hobbsee> mpt: sorry.  just thinking of if there are impending UI changes.
[05:22] <mpt> There are always impending UI changes. Launchpad is an active project.
[05:23] <pwnguin> so uh, apparently modprobe wont load nvidia drivers if xorg.conf doesn't have it listed?
[05:24]  * Hobbsee sighs at impending work
[05:25] <mjg59> pwnguin: Correct
[05:25] <mjg59> Otherwise non-free modules get loaded unnecessarily
[05:26] <pwnguin> interesting
[05:26] <pwnguin> dont you have to actually go to the trouble of installing nvidia-glx?
[05:30] <pwnguin> mjg59: how then, do you load the module without modifying xorg.conf?
[05:52] <mjg59> pwnguin: You don't?
[05:52] <mjg59> Well, you can use insmod
[05:53] <mjg59> But there's no reason to load it unless you're using the nvidia driver
[05:53] <pwnguin> apparently someone wants to see if they can even build / load the driver on their g80
[05:54] <mjg59> Why?
[05:55] <pwnguin> because its not fully supported by nvidia-glx-new?
[05:55] <mjg59> I don't understand the problem
[05:55] <mjg59> If they're installing a new driver, they need to change xorg.conf to use it
[05:56] <mjg59> And then the nvidia module will get autoloaded
[05:56] <pwnguin> < crweb32> i just needed it to load so i can watch detection/other stuff
[05:56] <pwnguin> 23:31 < crweb32> my card isn't supported fully yet
[05:56] <mjg59> Then use insmod
[06:47] <Seq> Is there a way to have
[06:48] <Seq> Is there a way to have a linux-backports-modules style package replace certain modules (like alsa is with said package) but be included in the initrd?
[06:49] <corevette> i didn't know hardy was planning ppc https://launchpad.net/ubuntu/hardy/powerpc
[06:52] <Fujitsu> corevette: It has been unsupported by Canonical for a release or do, but was never entirely dropped, and likely won't be for some time.
[06:52] <Fujitsu> s/do/so/
[08:03] <MacSlow> Greetings everybody!
[08:04] <dholbach> good morning
[08:05] <tjaalton> good morning!
[08:05] <tjaalton> general notice; I've changed my nick (formerly "tepsipakki")
[08:05] <dholbach> hey tjaalton! :-)
[08:05] <tjaalton> hey dholbach :P
[08:06] <LaserRock_70s> tjaalton: oh man, just when I started remembering your nick :-)
[08:07] <tjaalton> LaserRock_70s: yeah, it's been nice and quiet for the past few days :)
[08:09] <pitti> Good morning
[08:14] <LaserRock> pitti: heah, you're up
[08:15] <LaserRock> pitti: I have a translation/lang pack question for you
[08:15] <pitti> Hey Laser...'R'ock?
[08:15] <LaserRock> pitti: see Planet
[08:15] <LaserRock> pitti: it's all jorge's fault
[08:16] <LaserRock> does the source package need to have a .pot for translations and inclusion in the lang packs to work?
[08:17] <pitti> LaserRock: after the source package is fully built, there needs to be a .pot file
[08:17] <pitti> ideally this is dynamically created during build, so that patches which change strings are considered
[08:17] <pitti> many packages ship a static .pot which must be updated manually; that's not optimal, but works
[08:18] <LaserRock> ok
[08:18] <pitti> (we don't change strings too often)
[08:18] <LaserRock> gcompris ships .po files but no .pot
[08:18] <LaserRock> and apparently in gutsy the translations got dropped or something
[08:18] <LaserRock> real mess, upstream's not happy
[08:18] <pitti> ah; in the past, gcompris was special
[08:18] <pitti> but I remember having touched it in hoary times to fix translations
[08:19] <LaserRock> pitti: yeah, I think we (I) must have dropped your changes in a merge/sync accidentally
[08:20] <LaserRock> I should be able to built the .pot in at build time in debian/rules though right?
[08:21] <pitti> LaserRock: yes; how in particular, is the question
[08:21] <pitti> LaserRock: does the package use intltool?
[08:23] <dholbach> hey mvo
[08:23] <mvo> hey dholbach!
[08:23] <StevenK> Hey pitti
[08:23] <LaserRock> pitti: I'm not exactly sure but I think so. there are lots of .po files in po/
[08:23]  * dholbach does his daily call for attention to http://people.ubuntu.com/~dholbach/sponsoring
[08:24]  * pitti hugs StevenK, good morning
[08:24] <pitti> LaserRock: lemme look
[08:24] <LaserRock> pitti: there's references to intltool all over the place in the makefiles, etc.
[08:25] <pitti> ah, great
[08:25] <pitti> LaserRock: and does the package use cdbs?
[08:26] <LaserRock> pitti: no, only debhelper
[08:27] <pitti> LaserRock: try calling 'intltool-update -p --verbose'
[08:27] <pitti> LaserRock: usually after 'make' in debian/rules build
[08:28] <LaserRock> pitti: ok, I'll give it a go
[08:28] <LaserRock> pitti: would there be any possibility of doing an SRU to get translations back for gutsy?
[08:30] <pitti> LaserRock: I'd prefer building the package locally with pkgbinarymangler installed and enabled and tossing the translations.tar.gz to carlos for manual import
[08:30] <pitti> carlos: is that possible/reasonable?
[08:34] <dholbach> seb128, StevenK, doko_, server people (keescook, soren), calc, pitti, asac, mvo: http://people.ubuntu.com/~dholbach/sponsoring/ :)
[08:34] <Fujitsu> dholbach: How is the responsible person determined?
[08:34] <pitti> dholbach: I fixed all but one yesterday, and that one requires some action from the bug reporter
[08:35] <dholbach> pitti: ok - great
[08:35] <dholbach> Fujitsu: assignee + subscribers - (people not in ~ubuntu-dev or other developer teams)
[08:36] <dholbach> Fujitsu: maybe responsible is the wrong word for it, I merely want to know easily if it has the attention of an ubuntu developer
[08:36] <LaserRock> I would think just assignee would be more "responsible person"
[08:36] <dholbach> it's not always assignee
[08:36] <seb128> dholbach: do you do stats?
[08:38] <dholbach> seb128: stats as in how?
[08:38] <seb128> dholbach: as how many packages are uploaded and reviewed
[08:39] <pitti> hey seb128, good morning
[08:39] <dholbach> it'd be nice to have that, I agree
[08:39] <pitti> seb128: AFAIK, the only remaining bit of 2.20.1 in -proposed is tomboy, right?
[08:39] <seb128> dholbach: I'll upload the package from bug #118589 soon and I was wondering if that should be listed on your sponsor list
[08:39] <ubotu> Launchpad bug 118589 in ubuntu "[needs-packaging] Avant Window Navigator" [Wishlist,In progress] https://launchpad.net/bugs/118589
[08:39] <seb128> pitti: yes
[08:39] <seb128> good morning pitti ;-)
[08:39] <dholbach> seb128: not sure a query like "all bugs seb128 is subscribed to and ubuntu-main-sponsors or ubuntu-universe-sponsors too" works in LP
[08:44] <LaserRock> pitti: if people translate strings for gcompris in Rosetta but there is no .pot I'm guessing the translations aren't included in the lang packs
[08:44] <LaserRock> pitti: I'm looking at bug #107971
[08:44] <ubotu> Launchpad bug 107971 in gcompris "Incomplete French translation" [Medium,Triaged] https://launchpad.net/bugs/107971
[08:44] <pitti> LaserRock: they won't even be imported
[08:45] <pitti> LaserRock: that'll still use the feisty/edgy pot (whenever it got broken)
[08:45] <LaserRock> right
[08:45] <LaserRock> man, that's not good :/
[08:45] <carlos> pitti: yeah, send me anything you need to be fixed so you don't need a build to get it imported
[08:45] <pitti> carlos: cool, thanks
[08:46] <pitti> LaserRock: ^ so, please install pkgbinarymangler, enable /etc/pkgbinarymangler/striptranslations.conf, and build the package
[08:46] <carlos> pitti: is it for gcompris?
[08:46] <pitti> carlos: oui
[08:46] <carlos> I only need the .pot file then
[08:46] <carlos> no need to generate the tarball
[08:46] <carlos> just get all patchs applied and generate the .pot file
[08:46] <carlos> and that's it
[08:49] <LaserRock> ok, to be clear
[08:49] <mpt> StevenK, are you going to get the HardyAboutUbuntu spec approved by the 22nd?
[08:49] <LaserRock> I'll fix up gcompris in Hardy when I merge
[08:49] <LaserRock> for Gutsy I create a .pot and send it to carlos
[08:50] <LaserRock> pitti: ^^ is correct?
[08:51] <pitti> LaserRock: seems like it
[08:51] <LaserRock> pitti: and would it be a good idea to ask upstream to ship a .pot?
[08:51] <LaserRock> or is that something we like to do at build time anyway
[08:51] <pitti> LaserRock: I don't think so; we need to generate during build anyway
[08:52] <LaserRock> pitti: ok, danke
[08:53] <carlos> LaserRock: gnome doesn't do it by default and is the right thing to do
[08:54] <carlos> LaserRock: because it's a generated file. Is just that it must be created as a make rule
[08:55] <LaserRock> carlos: I see
[09:04] <Nafallo> mjg59: getting VGA-output just by pressing the Fn+key apparently doesn't work
[09:04] <seb128> doko: around?
[09:05] <seb128> doko: you added "Fix build failure with g++-4.3" patches to glibmm2.4 and gtkmm2.4, do you have the build errors somewhere or sent those upstream or to Debian?
[09:08] <doko> seb128: http://people.debian.org/~lucas/logs/2007/09/10/gcc43/
[09:08] <seb128> doko: thanks
[09:08] <seb128> doko: do we need those fixes now? I'm considering sending the patches to Debian and doing a sync
[09:09] <doko> seb128: yes, or else these failures show up in rebuild tests again
[09:10] <seb128> doko: is there an easy way for me to do a such test build locally?
[09:10] <pwnguin> Nafallo: which laptop maker?
[09:10] <mvo> seb128: I installed gcc-snapshot and set CC=/usr/lib/gcc-snapshot/bin/gcc
[09:10] <mvo> seb128: and CXX=/u/l/g/b/g++
[09:10] <doko> seb128: either use gcc-snapshot or install g++ from the ~ubuntu-toolchain ppa
[09:11] <seb128> doko, mvo: thanks
[09:13] <Nafallo> pwnguin: Lenovo and Sony
[09:14] <pwnguin> Nafallo: interesting. my toshiba is apparently outright not supported ever
[09:14] <Nafallo> pwnguin: same chipsets and works fine on the LVDS?
[09:15] <pwnguin> LVDS?
[09:16] <Fujitsu> pwnguin: LCD.
[09:17] <Fujitsu> The internal one, that is.
[09:17] <pwnguin> Nafallo: i think im missing part of the conversation, which chipsets would be the same?
[09:17] <Nafallo> pwnguin: X3100 / GMA965
[09:18] <pwnguin> ah, no
[09:18] <Nafallo> pwnguin: and right, I probably only just told Fujitsu :-P
[09:18] <pwnguin> this is a good old nvidia
[09:18] <Fujitsu> That would be correct.
[09:18] <Fujitsu> Ah, well, nvidia is evil, so I'm not surprised.
[09:18] <pwnguin> it has nothing to do with nvidia
[09:18] <pwnguin> at least not directly
[09:18] <pwnguin> they support fn
[09:18] <Nafallo> Fujitsu: xrandr complains that the screen can't be larger than 1280x1280 and fails :-)
[09:19] <pwnguin> except on toshiba
[09:19] <Fujitsu> Nafallo: Ah, if you turn off Composite, that should work.
[09:19] <Fujitsu> Although I'm sure the 965 allows a larger screen than that...
[09:19] <Nafallo> Fujitsu: aha!
[09:20] <Fujitsu> Nafallo: Or set the screen to be on top or below, rather than beside.
[09:20] <Nafallo> Fujitsu: same thing
[09:20] <pwnguin> do video drivers get put in universe on occasion?
[09:20] <Fujitsu> Nafallo: Must be a fairly big external screen, then.
[09:21] <pwnguin> im thinking it would be neat to have nouveau drivers in hardy, but i can understand the LTS being a scare
[09:21] <Fujitsu> pwnguin: -amd was for quite some time last cycle.
[09:21] <Nafallo> Fujitsu: 1280x1024
[09:21] <Nafallo> Fujitsu: and a bigger one on the way :-P
[09:21] <Nafallo> Fujitsu: anyway... turn off composite with the new xorg.conf? ;-)
[09:21] <tjaalton> pwnguin: tracking upstream would be massively painful
[09:22] <tjaalton> since there are no releases
[09:22] <Nafallo> Fujitsu: - something, right? :-)
[09:22] <Nafallo> hi tjaalton :-)
[09:22] <tjaalton> Nafallo: hey :)
[09:23] <Nafallo> gaah! DUMB google. not the electrical composite...
[09:23] <pwnguin> tjaalton: indeed. i know someone who already does it though ;)
[09:24] <Fujitsu> tjaalton: Are you now employed by Canonical?
[09:24] <tjaalton> Fujitsu: heh no, I just got bored by the long nick
[09:24] <Fujitsu> Because that generally induces the nick change.
[09:24] <Fujitsu> Heh.
[09:24] <Nafallo> lol
[09:25] <pwnguin> then.. keescook is his real name?
[09:26] <Nafallo> pwnguin: yes.
[09:26] <Nafallo> but jono should really be named jbacon now ;-)
[09:26] <Nafallo> to fit in with the crowd :-P
[09:26] <LaserRock> along with mpitt
[09:26] <dholbach> ...say LaserRock and Nafallo... :)
[09:27] <tjaalton> pwnguin: there's no-one maintaining it in debian, for that reason :/
[09:27] <LaserRock> one of the perks of being a lowley volunteer
[09:27] <Nafallo> dholbach: I'm not employed by Canonical :-P
[09:27] <dholbach> LaserRock: pfffft
[09:27] <dholbach> Nafallo: pfffft
[09:27] <pwnguin> tjaalton: i know. plus it carries a lot of extras, from what i recall. some libdrm or something
[09:28] <Nafallo> dholbach: and well, my name is Nafallo, and my surname is not pronouncable by non-swedes ;-)
[09:28] <tjaalton> pwnguin: git HEAD of everything..
[09:28] <pwnguin> tjaalton: at any rate, RAOF keeps a ppa with nouvuau
[09:28] <Nafallo> Fujitsu: I got clone with Composite and AIGLX off.
[09:28] <luisbg_> LaserRock, LaserRock! LOL!!
[09:28] <LaserRock> Nafallo: yeah, I've tried and I just give up
[09:28] <Nafallo> Fujitsu: so can't see the bottom menu bar.
[09:31] <soren> If an upstream tarball does not contain the appropriate license file, but it's otherwise quite clear that it's supposed to be there (every source file says it's GPL and such), the right thing to do is to repack the tarball with the COPYING added?
[09:33] <dholbach> soren: if upstream promised me to add it, I added it to the diff.gz
[09:35] <soren> dholbach: I seem to remember someone (Mithrandir, perhaps) rejecting a new package on those grounds.. I belive the reasoning was that it's entirely possible to only download the orig.tar.gz from our archive, and without the COPYING in there, it's not clear if it's redistributable...
[09:35] <soren> dholbach: It's of course entirely possible that I'm just on crack.
[09:36] <dholbach> soren: you can repack the tarball too, but I'm not an archive admin, so maybe *I*'m on crack
[09:36] <soren> :)
[09:42] <pwnguin> where does the failsafe gdm log errors to?
[09:43] <Mithrandir> soren: it should be in the orig.tar.gz.  I'd like you to get upstream to release a new version with it fixed, but if waiting for that blocks you, please feel free to upload a repacked orig.tar.gz with a note in the changelog as to what's been done.
[09:43] <soren> Mithrandir: Exactly the answer I was looking for. Thanks.
[09:55] <carlos> pitti: hi, what's the status of gutsy's language packs?
[09:55] <pitti> carlos: you tell me?
[09:55] <pitti> are there tarballs now?
[09:56] <carlos> pitti: every Sunday and Wednesday!
[09:56] <carlos> pitti: as usual :-)
[09:56] <carlos> we don't stop producing them
[09:56] <pitti> ah, great
[09:56] <pitti> I'll set up the PPA builds today then
[09:57] <pitti> I didn't find time to update the langpacks yet, too much stuff to do
[09:57] <pitti> ArneGoetje: are you interested in some hands-on training about this? ^
[09:58] <carlos> pitti: ok, thanks
[09:59] <pitti> carlos: I guess one of these days can be dropped, we'll only build them weekly
[09:59] <pitti> so that hardy can get a slot
[10:00] <carlos> pitti: yeah, next month hardy ones will be generated so I will move Gutsy to be done daily
[10:00] <pitti> daily?
[10:03] <seb128> StevenK: do you plan to do that gimp merge? ;-)
[10:24] <pitti> seb128: does gnome-keyring work for you in current hardy? I only get an error dialog "Couldn't search keyring (code 9)"
[10:25] <Fujitsu> pitti: Works for me several times a day.
[10:25] <pitti> hm
[10:25] <seb128> pitti: I think it does, at least network-manager connect to my network without asking the password
[10:25] <pitti> I have this since yesterday's dist-upgrade
[10:25] <seb128> gnome-keyring didn't change recently
[10:25] <Fujitsu> (several times a day because NM reconnects every time I reboot after -intel locks my machine)
[10:44]  * RAOF returns to see nouveau highligted...
[10:45] <pwnguin> heh
[10:45] <pwnguin> sorry ^_^
[10:45] <RAOF> Was someone after something else from libdrm git?
[10:46] <pwnguin> i mentioned nouveau earlier
[10:46] <RAOF> I could easily build intel & ati drm modules from that source.
[10:48] <tkamppeter> pitti, hi
[10:48] <pitti> hey tkamppeter
[10:50] <tkamppeter> pitti, first, the changelog of the actually uploaded cups-pdf (bug 152293) looks a little bit strange (no name u8nder my sync, my name under Debian upload). Did you edit anything on the changelog or did Launchpad mess up the changelog display?
[10:50] <ubotu> Launchpad bug 152293 in cups-pdf "cups-pdf 2.4.6-3ubuntu9 doesn't create PDF-queue" [Medium,Fix released] https://launchpad.net/bugs/152293
[10:50] <pitti> tkamppeter: that's fine, since you correctly used -v
[10:53] <pitti> tkamppeter: what you see is the .changes file, not the actual changelog
[10:53] <tkamppeter> pitti, I see, in the _source.changes file all name stamps are stripped off from the new changelog entries and Launchpad adds only one name stamp at the end, the one of the latest change.
[10:53] <pitti> tkamppeter: s/Launchpad/dpkg/
[10:54] <pitti> tkamppeter: you did the upload and introduced all those versions into Hardy
[10:55] <tkamppeter> pitti, second, HPLIP: I tried "man requestsync" and my system did not find the man page. Which package do I need to install?
[10:55] <pitti> tkamppeter: ah, sorry; that's in ubuntu-dev-tools
[10:55] <pitti> tkamppeter: ah, is that your first sync request?
[10:56] <pitti> tkamppeter: you should read https://wiki.ubuntu.com/SyncRequestProcess then
[10:56] <pitti> tkamppeter: it explains both the process and the usage of requestsync
[10:56] <tkamppeter> Now I have found it, too, by the great command-not-found tool, I typed symply requestsync without man.
[10:56] <tkamppeter> Yes, it is my first sync request.
[10:57] <tkamppeter> Thanks for the link.
[10:57] <Keybuk> >>>> --=-4+WD5xy/k0klzAYckvq7
[10:57] <Keybuk> **** Command '--=-4+wd5xy/k0klzayckvq7' not recognized.
[10:58] <Keybuk> heh
[10:58] <StevenK> seb128: I do, yes.
[10:58] <Keybuk> someone needs to drag Majordomo into the 20th century
[10:58] <tkamppeter> pitti, but I am in doubt whether syncing with Debian is the right thing. This is probably more for the packages where there is active maintainership on the Debian side and Ubuntu simply takes what Debian does.
[10:58] <pitti> tkamppeter: but what was the reason why the DD uploaded it to experimental?
[10:58] <pitti> ideally the two of you would cooperate and work on one package
[10:59] <pitti> which is then uploaded to Debian and synced to Ubuntu
[10:59] <tkamppeter> pitti, we have it the other way around: I am actively maintaining the package at Ubuntu and Debian takes what Ubuntu does.
[11:00] <pitti> well, with 'we both work in the same VCS and keep the packages in sync' there is not much of an 'other way round' IMHO
[11:01] <thom> Keybuk: no, they need to kill it with extreme prejudice
[11:01] <seb128> pitti: well, it's just a question of where the VCS is then
[11:01] <tkamppeter> The DD, Marc Purcell, has uploaded it becuase users complained about HPLIP not getting updated (Debian bug 413225).
[11:01] <ubotu> Debian bug 413225 in hplip "new upstream release" [Wishlist,Fixed] http://bugs.debian.org/413225
[11:02] <pitti> tkamppeter: did you talk to him about shared maintenance? or did he just upload the current version to experimental without any discussion?
[11:03] <tkamppeter> Mark has put it into experimental because our Ubuntu package has one additional binary package, hplip-gui which causes it to need to go through the NEW process again.
[11:03] <Keybuk> thom: I had the fun experience of posting a kernel patch to LKML this week
[11:03] <soren> Where can I find a list of packages in gutsy-proposed?
[11:03] <Keybuk> let me paraphrase the response
[11:03] <Keybuk> "AIIIIEE!! MIME!!! GNARGH!!! MELTTTTTING!"
[11:04] <pitti> soren: http://people.ubuntu.com/~ubuntu-archive/pending-sru.html might be what you want (packages which are newer in -proposed than in -updates/-security)
[11:04] <pitti> soren: for a full list: Packages.gz :)
[11:04] <tkamppeter> pitti, Mark did it by himself, without any discussion with me. For me there was simply no Debian maintainer at all, as Henrique de Maraes Holschu has quit doing Debian packaging work.
[11:04] <pitti> tkamppeter: ah, I see
[11:04] <soren> pitti: Ooh! That was exactly what I was looking for. Shiny.
[11:04] <pitti> soren: :)
[11:05] <tkamppeter> I did not know that Mark does work on printing packages. Perhaps he simply looks around in Ubuntu for what can help on Debian problems.
[11:06] <pitti> tkamppeter: so if you want to keep it that way, that would be fine; but I still think that working in a shared VCS together with the Debian guys would avoid unnecessary duplicate work on both sides
[11:07] <pitti> tkamppeter: what does your upload actually change compared to -ubuntu1 we have in hardy?
[11:07] <tkamppeter> pitti, I think working together with Debian is really the better solution. Only requirement is that Debian provides a maintainer who quickly reacts if I do something on the package.
[11:08] <pitti> tkamppeter: oh, we shouldn't block on Debian for doing an Ubuntu upload
[11:08] <tkamppeter> pitti, it adds only a ChangeLog entry, I have only done it to close the Merge-o-Matic sync request.
[11:08] <pitti> tkamppeter: ah, I see; so we can just ignore the MoM entry for now
[11:15] <tkamppeter> pitti, I got an e-mail (I do not find it any more) that I should fix my MoM entries, so I will simply ignore that one and only sync if Debian really contributes something and does not only sync our package.
[11:16] <pitti> tkamppeter: right; it's fine to ignore those, where Debian doesn't have actual changes
[11:16] <pitti> tkamppeter: do you get my /msgs?
[11:18] <tkamppeter> Yes.
[11:36]  * pitti radiates hot hate towards svn
[11:40]  * Hobbsee waves
[11:42] <pitti> hey Hobbsee
[11:44]  * Hobbsee hugs pitti
[11:51] <\sh> keescook, I added debdiffs for openldap2.3 for feisty and gutsy
[11:52] <fabbione> hi Hobbsee
[11:52] <Hobbsee> hey fabbione!
[11:52] <\sh> keescook, bug #162162
[11:52] <ubotu> Launchpad bug 162162 in openldap2.3 "[CVE-2007-5708] openldap 2.3" [Undecided,In progress] https://launchpad.net/bugs/162162
[11:59] <cprov> elmo: do you know if it's easy to restore rubidium image on ferraz ?
[11:59] <cprov> oops wrong channel, nevermind me.
[12:04] <seb128> bigon:
[12:04] <seb128> "Explanation of the Ubuntu delta and why it can be dropped:
[12:04] <seb128> Ubuntu changes can be dropped"
[12:05] <seb128> bigon: that's not really an explanation of the Ubuntu delta and why it can be dropped
[12:05] <pitti> why? yes!
[12:05] <soren> :)
[12:05] <Hobbsee> seb128: dude...we didn't have a MOTU write that, surely?
[12:06] <Hobbsee> ISTR various of us on motu-uvf going thru this stuff with bigon last time, too.
[12:10] <seb128> Hobbsee: bigon did
[12:10] <Hobbsee> seb128: yeah.  wow.
[12:11] <Hobbsee> seb128: i thought our MOTU's took better care than that :(
[12:11] <seb128> Hobbsee: most of the time they do, don't worry
[12:12] <Hobbsee> seb128: i'm glad to hear it. repeatedly giving people the riot act around ubuntu too would not be so much fun.
[12:13] <Hobbsee> s/giving/reading/
[12:13] <Hobbsee> work is enough :)
[12:19] <Hobbsee> pitti:++
[12:20] <seb128> Hobbsee: ?
[12:20] <Hobbsee> seb128: ? w.r.t what?
[12:21] <Hobbsee> oh, pitti++ to his mailing list post (ubuntu-devel)
[12:21] <pitti> Hobbsee: SRU?
[12:21] <Hobbsee> pitti: yup
[12:21] <seb128> Hobbsee: yes
[12:22] <persia> pitti: Just as an aside, motu-sru has been inactive since feisty (not that I don't agree peer review is good).
[12:22] <Hobbsee> seb128: i'm agreeing with pitti w.r.t his SRU mail to ubuntu-devel.  alternatively, i'm telling pitti to clone himself.
[12:22] <Hobbsee> persia: i think they're using motu-uvf instead.
[12:22] <Hobbsee> makes me wonder what i should do with the bugs and such
[12:22] <persia> Hobbsee: Not really.  Was true from UVF -> release, but not today.
[12:23] <Hobbsee> hmm, i wonder why i'm getting bugmail
[12:23] <Hobbsee> last i checked, azereus is not in main.
[12:23] <pitti> persia: right, it was decided to abolish it
[12:23] <persia> pitti: OK.  Just wanted to make sure :)
[12:33] <bigon> seb128: I've explaned a bit more why ubuntu changes can be dropped for empathy
[12:38] <seb128> bigon: thanks
[12:39] <pitti> hm, consolekit does not have a session for my primary user
[12:40] <seb128> bigon: I'll do the sync because you are looking at the package but "Most of the changes merged in debian, other minor changes can be dropped" is still not a satisfactory explanation of what those changes are why they can be dropped
[12:40] <StevenK> bigon: You need to list all of the changes, the reason for each of them.
[12:40]  * Hobbsee would advise checking the sig on the request
[12:40] <Hobbsee> seeing as we've seen crack before from new motus, which are actually non-motu's uploading people's packages, and resigning them.
[12:41] <Hobbsee> guess that doesnt apply for launchpad, though
[12:42] <\sh> keescook, bug #162385 , removed all .orig remains from the dpatches
[12:42] <ubotu> Launchpad bug 162385 in drupal5 "[Security] Several Security Issues for drupal 5.x before 5.3" [Undecided,In progress] https://launchpad.net/bugs/162385
[12:43] <Keybuk> http://blog.fubar.dk/?p=94
[12:43] <Keybuk> nice
[12:44] <pitti> seb128: btw, I have the feeling that the 'gnome-screensaver does not accept my password' is related to the 'CK does not know about my session' bug
[12:44] <seb128> pitti: gnome-screensaver doesn't accept your password?!
[12:45] <pitti> no, it occasionally does htat
[12:45] <seb128> do you have ck running now?
[12:47] <pitti> seb128: I restarted the session, and it knows about it now, yes
[12:47] <seb128> weird
[12:47]  * pitti greets his very first PK auth dialog
[12:47]  * seb128 hugs pitti
[12:48] <seb128> Riddell: do you confirm bug #163383?
[12:48] <ubotu> Launchpad bug 163383 in k3b-i18n "Please sync k3b-i18n 1.0.4-1  (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/163383
[12:55] <ScottK> pitti: I asked around after we briefly discussed Universe SRU policy yesterday and was told some other MOTUs are working on a proposal to change the policy to (hopefully) deal with your concerns, so discussing it at the meeting on Friday would be premature.  They're planning on posting to the mailing list thread when they have it worked out.
[12:56] <pitti> ScottK: that sounds fine
[12:57] <Riddell> seb128: let me look
[12:58] <Riddell> seb128: yes, that's fine
[12:59] <seb128> Riddell: ok, thanks
[13:06] <cjwatson> seb128: perhaps the contentious bits of desktop-volumes-representation (fully automatic label generation) could be factored out to a separate "Discussion" section? I think the rest of the spec is valuable and can be approved without that
[13:07] <cjwatson> it seems reasonable to have the desktop autogenerate a reasonable label on the fly if there isn't one there, and if the user wants to change it to something meaningful to them then let them do that; the installer isn't going to be able to guess something any more meaningful than what you could generate on the fly anyway
[13:07] <cjwatson> (where meaningful => "my old Windows stuff" or "my music" or whatever)
[13:10] <seb128> cjwatson: works for me, part of the spec is deprecated by partition-​management though
[13:10] <seb128> cjwatson: I'll update it to list only the naming policy we want to use
[13:10] <cjwatson> ok, I haven't read that yet
[13:12] <soren> Should .py files in /usr/share/python/site-packages... usually be executable? They're not meant to executed directly, but lintian makes a fuss about it.
[13:15] <cjwatson> IIRC, lintian makes a fuss only if they don't start with #!
[13:16] <cjwatson> if the files are executable, they should actually *be* executable by means of a #!; if that's not desirable or sensible, remove the x bit
[13:17] <soren> They have #!, and are not executable, so it's the other way around.
[13:18] <soren> I could change the build system to remove the #! lines, but I'm not sure it's worth the effort.
[13:24] <pitti> Keybuk: Awooga! my first gnome-mount -> PK -> auth dialog for *my* password (not root's) -> success :)
[13:25] <cjwatson> soren: for "not worth the effort", the right answer is to leave the lintian warnings there and just not pay attention to them
[13:25]  * pitti declares this a good enough victory to finally have lunch, bbl
[13:25] <cjwatson> then perhaps some future developer may see and care
[13:25] <dholbach> pitti: enjoy it :)
[13:25] <soren> cjwatson: That's what I meant :)
[13:25] <soren> cjwatson: Thanks.
[13:26] <cjwatson> I think Lintian's point in this case is really more that the useless shebang should be removed, rather than that it really wants them to be executable
[13:27] <soren> cjwatson: Right.
[13:40]  * lamont uploads a new bsdmainutils to go with the util-linux upload of last night
[13:57] <Keybuk> pitti: sweet
[14:03] <Nafallo> anyone have a date for when vmware will be available in gutsy/partner?
[15:02] <pitti> seb128: in the interest of peer review, do you think https://wiki.ubuntu.com/MainInclusionReportPolicyKit is sane?
[15:02] <seb128> pitti: looking
[15:02] <seb128> pitti: s/Gnome/GNOME ;-)
[15:02] <pitti> argh, I suck :)
[15:03] <seb128> pitti: looks good
[15:03] <cjwatson> Keybuk: since I just drafted hardy-bootloader-review, would you take over the job of approver from me, please?
[15:03] <seb128> yeah for policykit ;-)
[15:05] <Keybuk> cjwatson: sure
[15:05] <cjwatson> thanks
[15:06] <pitti> so let the madness begin! /me promotes
[15:06]  * ogra sees a lot of traffi on increase-hwdb-participation
[15:06] <ogra> pitti, cjwatson did any of you talk to cr3 ? he's working on a new client afaik
[15:07] <ogra> not smolt based
[15:07] <pitti> he mentioned it briefly
[15:07] <pitti> on FossCamp, someone showed me http://www.dohickey-project.com/
[15:07] <pitti> this also looks quite useful
[15:07] <ogra> the ideas sound just w´awesome
[15:08] <ogra> talk to him :) it sounded like a nice idea of partial apport integration with the hwdb client
[15:13] <Ng> pitti: was it Martin Owens? he was at fosscamp (and is a thoroughly pleasant chap)
[15:13] <pitti> Ng: right, he was
[15:13] <pitti> it was him, I meant
[15:15]  * pitti -> off for some hours, bbl
[15:16] <\sh> keescook, jdstrand bug #164072 ready for review
[15:16] <ubotu> Launchpad bug 164072 in cacti "[CVE-2007-6035] cacti has a sql injection vulnerability" [Undecided,New] https://launchpad.net/bugs/164072
[15:17] <jdstrand> \sh: thanks! :)
[15:24] <cr3> ogra: I will be talking to the fedora folks, introduced to me by George, about extending hwtest (next generation of hwdb) to also post hardware information to smolt
[15:24] <ogra> right
[15:24] <cr3> darn, pitti left, but I would also like to mention I have spoken to the author of dohickey and we'll probably work together
[15:24] <ogra> on the spec there was a question if we'd use smolt
[15:24] <ogra> https://blueprints.edge.launchpad.net/ubuntu/+spec/increase-hwdb-participation
[15:25]  * persia notes that it might be nice to catch HW changes as well, for those who upgrade without reinstalling, but not important enough to spec or anything
[15:26] <cr3> ogra: since smolt is such a recurring topic, I will try to implement it as soon as possible
[15:27] <cr3> persia: I would like to track hardware and software changes. when there is a test corresponding to one of those things which have changed, the user could be prompted to retest
[15:28] <persia> cr3: That'd be the solution to my ill-formed wish :)
[15:29] <cr3> persia: glad to hear it sounds useful, this kind of feedback is very valuable
[15:31] <persia> cr3: I'm mostly thinking in terms of tracking support effectively.  If I attach a new DDC/CI screen, or a new keyboard with a different layout, or put in the latest video card, etc. the system will still work (perhaps with a quick fiddle), but the fact that the system supports that hardware isn't being reported, so the next person doesn't know it's safe to install.
[15:32] <\sh> jdstrand, I'll push some notes to debian stable security, too
[15:33] <\sh> jdstrand, btw...I can't add the CVE link to the bug report, because I think LP only checks mitre...but this CVE is not listed on mitre right now
[15:33] <cjwatson> calc: note that I have assigned ooo-langpacks to you and targetted it for hardy; I believe the specification is fairly clear and we've discussed it before, but please shout if anything is unclear
[15:35] <jdstrand> \sh: that has been my experience as well
[15:36] <\sh> jdstrand, worth a bug?
[15:37] <cr3> persia: right, so you should be prompted once again to run the relevant tests corresponding to your new hardware
[15:37] <jdstrand> \sh: I don't think so.  I think it is intentional right now as a form of integrity checking.
[15:37] <jdstrand> \sh: LP isn't well integrated with security updates yet, so it is not a big deal anyway
[15:38] <\sh> jdstrand, well, the CVE parser on edge is a real improvement :)
[15:38] <jdstrand> \sh: if it's noted in the bug report and flagged as security, we can get it in our cve tracking syste
[15:39] <persia> cr3: I'm undecided regarding a direct prompt, or a more subtle restoration of a menu item, as I suspect the collection would be best done after any required local tweaking, rather than before, but it depends on whether the test is an "out of the box" test or a "works for me" test.
[15:39] <calc> cjwatson: ok
[15:39] <jdstrand> \sh: there has been some work on it, yes, and hopefully we'll be able to move over relatively soon (I have no timeframe)
[17:01] <cr3> ogra: by the way, I added a cool feature to hwtest yesterday which relates tests to hardware or software components. the relation is defined in a text file and is really readable: 'net.80211' in info.capabilities and linux.hotplug_type == 2
[17:03] <ogra> nice !
[17:04] <cr3> ogra: ideally, I would like to be able to list all hardware devices and see the number of related tests
[17:07] <lamont> cjwatson: got time to be a chroot-tarball muppet?
[17:09] <lamont> chinstrap:~lamont/chroot-fresh, *7
[17:33] <wasabi> Curious question: would it make sense in some way for dhclient to store received dhcp options in HAL for a given network device?
[17:33] <wasabi> I'm wondering about how to propagate a few of those options to other applications, such as, for instance, Samba's WINS option.
[17:35] <Keybuk> it makes an amount of sense
[17:35] <wasabi> Yeah, we're storing similar stuff, such as MD and LVM block devices in there. High level stuff.
[17:36] <wasabi> options could be translated to dhcp.$optionname or dhcp.$optionnumberid
[17:36] <wasabi> or some such
[17:36] <wasabi> Sort of overlaps with network manager.
[17:36] <wasabi> (which might be a good thing)
[17:37] <wasabi> Maybe a sub-network device pseudo device for each assigned IP.
[17:38] <wasabi> With the possibility of seeing how that IP originated, dhcp or otherwise, and if so, pulling otu teh dhcp options.
[17:38] <Keybuk> network manager is basically just mechanism
[17:38] <wasabi> Basically then it would come down to making Samba pull it's information from there. And watch for changes.
[17:38] <Keybuk> for a given interface, it can bring it up or down
[17:38] <wasabi> Which would be a very nice way to go about it.
[17:38] <wasabi> Yeah.
[17:38] <Keybuk> and uses dhclient and/or wpa_supplicant to do that
[17:39] <wasabi> Applications can query NM to determine up/down state, though.
[17:39] <Keybuk> right, though arguably that should be in HAL
[17:39] <wasabi> Yes.
[17:40] <wasabi> DHCP can be used to push time servers too, syslog servers, cookie servers, lpr stuff.
[17:40] <wasabi> Tons of stuff in there which has never even been touched on in Unix because there has never been a good way to get it to userspace.
[17:41] <wasabi> Heh. Can push SMTP servers, POP3 servers, NNTP.
[17:42] <wasabi> Would be slightly interesting (though maybe an abuse of DHCP) to put that into Evo, so when setting up an account, it defaults to those.
[17:43] <Chipzz> wasabi: yes, but those settings may be transient, and when the dhcp server on another network does not supply them you're stuck with the old ones
[17:43] <Keybuk> actually, you'd just have a transient evo account
[17:43] <Chipzz> *old and incorrect
[17:43] <Keybuk> so when I login at home, there's an extra private e-mail account for cron mail
[17:44] <Keybuk> but when I login elsewhere, that account isn't accessible
[17:44] <Keybuk> (unless I've checked the [X] Available Offline button)
[17:44] <wasabi> Yeah, combined with Kerberos and friends, that would be pretty slick.
[17:44] <wasabi> For an office, etc.
[17:44] <Keybuk> imagine if DNS information was retrieved from HAL by the resolved
[17:44] <Keybuk> resolver
[17:44] <Keybuk> instead of some static file on the disk
[17:44] <wasabi> That would be nice. ;0
[17:44] <Keybuk> then we wouldn't have a lot of the problems we have today :)
[17:45] <wasabi> Yeah. You could enumate multiple sources of DNS information: VPNs, DHCP.
[17:45] <Chipzz> but I don't think even MS uses dhcp for mail
[17:45] <wasabi> In some sort of described priority level.
[17:45] <wasabi> (vpn A runs on top of connection B)
[17:45] <wasabi> No, MS doesn't use DHCP for mail. It's just an ideea.
[17:45] <wasabi> My bigger point is to simply see about putting that info SOMEWHERE>
[17:46] <wasabi> And HAL is probably closer to the right place.
[18:09] <warp10> Hi all!
[18:09] <keescook> soren: I need to convince you to use subprocess.call([]) instead of os.system.  :)  (submittodebian)
[18:10] <keescook> soren: also, what do you think of an env variable like "OVERRIDE_DEBEMAIL" or something so that reportbug will use something other than the currently set DEBEMAIL var?
[18:19] <soren> keescook: No no, you got it all wrong. You need to convince yourself to go fix that. :)
[18:21] <keescook> soren: no way, security through education.  :)
[18:21] <jdong> I thought the catchphrase around here is "open a launchpad bug"?
[18:21] <jdong> :D
[18:22] <keescook> for my second item, yeah.  But mostly I'm trying to stamp os.system() out of anyone's mind.
[18:22] <keescook> newly written code should always use an array-based "system" call.
[18:23] <keescook> (in python's case, that's subprocess.call())
[18:23] <jdong> keescook: yeah I just read up on subprocess.call(), I will transition my stuff to use that too, it makes a lot more sense
[18:24]  * jdong watches his todo list grow even more
[18:24] <keescook> jdong: cool!  yeah, it's a bit weird in some cases, but just not using a shell-backed exec of a string is a win.  :)
[18:25] <jdong> keescook: wholeheartedly agreed :)
[18:25] <soren> keescook: hm... So what's the deal with the subprocess.call thing?
[18:26] <soren> keescook: Just that it doesn't get parsed by a shell or something else?
[18:26] <soren> keescook: Er..
[18:26] <keescook> soren: while I don't suspect anyone will pwn you via submittodebian, I just saw the use of os.system and had to soap-box about subprocess.call().  ;)
[18:26] <jdong> soren: yeah the main point is it precludes accidental shell escaping by not having a shell interpret the arguments
[18:26]  * soren opens his eyes and notices that kees already answered that.
[18:27] <keescook> soren: what jdong said.  :)
[18:27] <soren> Sure, I dig that.
[18:27] <jdong> also makes sure your own arguments don't need to have annoying quoting, so win-win for laziness
[18:27] <soren> Yeah, I know. :)
[18:51] <norsetto> riddel: ping
[18:51] <norsetto> riddell: ping
[18:51] <Riddell> hi norsetto
[18:51] <norsetto> riddell: hi!
[18:52] <norsetto> riddell: just wondering, I've seen that tagtool was accepted in gutsy-proposed but I can't find the source in the archive?
[18:54] <Riddell> norsetto: hmm
[18:56] <Riddell> norsetto: I think the publisher is still doing its thing, it just turned to needs building https://launchpad.net/ubuntu/gutsy/+source/tagtool/0.12.3-2ubuntu0.1
[18:57] <norsetto> riddell: ok, so the source will not show up until it is built?
[18:58] <Riddell> norsetto: it should show up before then, best wait an hour and see if it has appeared
[18:59] <norsetto> riddell: okki, thanks
[19:15] <cjwatson> lamont: what are the changes?
[19:15] <lamont> apt-get update; apt-get dist-upgrade
[19:15] <lamont> --> shorter build logs, and slightly faster build times
[19:18] <cjwatson> lamont: FWIW, if I'm not mistaken, ebug-http is looping on palmer
[19:22] <cjwatson> lamont: updated *7, thanks
[19:28] <\sh> re
[19:29] <\sh> keescook, you found the patches for feisty+gutsy for openldap2.3?
[19:33] <lamont> cjwatson: I don't see any runaway procs on palmer
[19:34] <cjwatson> lamont: https://launchpad.net/+builds/palmer has been spewing "Please enter your CPAN site: []" / "CPAN.pm needs at least one URL where it can fetch CPAN files from." for six hours apparently
[19:38] <lamont> ah
[19:38]  * lamont checks again
[19:39] <lamont> ah, ebug-http build. doh
[19:39] <lamont> killed with prejudice.
[19:40] <lamont> and it's arch-all, apparently (just i386 build record)
[19:40] <cjwatson> oh, sorry, guess I should have made it clear I meant a build
[19:40] <lamont> so no extra cleanup to do
[19:40] <cjwatson> have you filed a bug?
[19:40] <cjwatson> (hang on, why am I telling *lamont* to file a bug?)
[19:40] <lamont> I have not
[19:40] <lamont> heh
[19:41] <lamont> I'll go file one
[19:41] <cjwatson> ta
[19:41] <lamont> right after I do a build on i368/debian, so I can file it against debian, where it should be
[19:41] <cjwatson> heh
[19:41] <cjwatson> has anyone here encountered bug 162638? If so, we are desperate for an installer log file so we can track it down
[19:41] <ubotu> Launchpad bug 162638 in user-setup "sudo - first user not in sudoers file" [Undecided,Incomplete] https://launchpad.net/bugs/162638
[19:47] <lamont> cjwatson: heh.  #450423, 13 days old.
[19:47] <lamont> I'll import it to launchad
[19:47] <warp10> hi pitti! bug #164143
[19:47] <ubotu> Launchpad bug 164143 in gwhois "Please sync gwhois 20071030  (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/164143
[19:48] <cjwatson> lamont: ah yes
[19:49] <lamont> bug 164166 linked
[19:49] <ubotu> Launchpad bug 164166 in ebug-http "FTBFS: tries to download from CPAN" [Undecided,New] https://launchpad.net/bugs/164166
[19:50]  * lamont always feels a little guilty when he confirms his own bug reports
[19:51] <pitti> warp10: hi!
[19:52] <DktrKranz> Riddell, ping
[19:53] <Riddell> hi DktrKranz
[19:54] <DktrKranz> Riddell, I just redid upload for bug 162843. Mind checking?
[19:54] <ubotu> Launchpad bug 162843 in docbook2odf "Package dependency missing : perlmagick" [Medium,Confirmed] https://launchpad.net/bugs/162843
[19:55] <Riddell> DktrKranz: looks good, accepting
[19:56] <DktrKranz> Riddell, thanks
[19:58] <warp10> pitti: I used requestsync for that sync. Anyway, the changelog is rather long, and it shows changes much older then the latest ubuntu version. I don'think this is an expected behaviour... should I manually shorten the description?
[20:05] <mdz_> pitti_: we're discussing your proposal on #-meeting if you're around
[20:05] <pitti_> mdz_: oh, I am; seems I just broke hardy, so I'm going to fix that, but I'll join
[20:17] <nixternal> pitti: I was going to let you know that hal didn't devistate hardy, but it added icons to my desktop (kubuntu) and knetworkmangler doesn't show any devices after the update...I know you are in a meeting, so have fun :)
[20:18] <pitti> nixternal: thanks; but I already found the cause
[20:18] <pitti> and why I didn't notice it when I tested that stuff
[20:18] <pitti> policykit ships /var/run/PolicyKit and relies on it
[20:18] <pitti> wham :)
[20:18] <nixternal> ahhh
[20:18]  * pitti will fix tonight
[20:18] <nixternal> I did see policykit as well
[20:18] <nixternal> groovy, keep on rockin'!
[20:19] <pitti> sorry for the breakage
[20:19] <nixternal> easy work around, so it isn't major
[20:20] <nixternal> just a bit of a scare until I decided to read /etc/networks/interfaces and seen my old comments from 2006 in there :)
[20:23] <ajmitch> pitti: I'm interested to hear your SRU plan there :)
[20:23] <pitti> ajmitch: it was just decided upon, I'll communicate the result to the MOTU council shortly
[20:24] <ajmitch> right, I was just watching -meeting
[20:24] <bryce> pitti, I've fleshed out more details about xorg hardware detection (particularly vis-a-vis input hotplug / hal) at https://wiki.ubuntu.com/HardyHardwareDetection - the section entitled X.org configuration refactoring
[20:25] <bryce> pitti, hope that's okay...  I didn't touch other parts, but I think it doesn't conflict with anything said elsewhere
[20:25] <pitti> bryce: ah, thanks; I'll have a look
[20:31] <ivoks> fabbione: have you seen bug 158288?
[20:31] <ubotu> Launchpad bug 158288 in redhat-cluster-suite "Node hangs at clvm when joining cluster" [Medium,Confirmed] https://launchpad.net/bugs/158288
[20:31] <fabbione> ivoks: no..
[20:32] <fabbione> oh yeah hell yes
[20:32] <fabbione> i know that problem
[20:32] <fabbione> it's new..
[20:32] <ivoks> just kicked me in the a... :)
[20:33] <fabbione> ivoks: i think there is a workaround if you want to test.
[20:33] <ivoks> sure
[20:33] <fabbione> basically the problem shows up only when a node has more than one ip address
[20:33] <fabbione> like a vip or so
[20:33] <ivoks> that's the case at my node
[20:33] <ivoks> 4 IPs :/
[20:33] <fabbione> the cman/dlm do not know which one to use for outgoing connections
[20:34] <fabbione> before we fixed the security stuff to restrict 2 connections from each node to each node
[20:34] <ivoks> that makes sense...
[20:34] <fabbione> cman/dlm were trying to connect * to *
[20:34] <ivoks> so it tries on all, yeagh..
[20:34] <fabbione> so at some point the right combination would kick in and work
[20:34] <fabbione> but
[20:34] <fabbione> with the restriction you need to make sure that the right 2 will start from the beginning
[20:34] <fabbione> or bad things happen
[20:35] <ivoks> hm :/
[20:35] <fabbione> so the workaround is to make sure that each node can only talk to the other from one IP
[20:35] <fabbione> for example
[20:35] <fabbione> node1 resolves to 4 IPs
[20:35] <fabbione> make node1 (as specified in cluster.conf) to resolve to only 1 IP
[20:35] <fabbione> do the same for all the nodes
[20:35] <fabbione> and that should work
[20:35] <fabbione> without crapping out the services
[20:36] <fabbione> so basically ccs/cman/etc. will know each node by only one ip that should be forced as source at that point
[20:36] <ivoks> you mean arp resolve?
[20:36] <fabbione> -no
[20:36] <ivoks> cause, it allready resolves to single IP
[20:36] <fabbione> dns/hosts resolve
[20:37] <ivoks> node1 resolves always to same IP
[20:37] <ivoks> so does node2
[20:37] <ivoks> 3...
[20:37] <ivoks> etc
[20:37] <fabbione> ok
[20:37] <ivoks> if i start them all together, everything is ok
[20:37] <ivoks> but if i reboot one, that one will not boot
[20:37] <fabbione> no, it will just take hell of a time to boot
[20:38] <ivoks> well, i'm waiting for a hour already :)
[20:38] <fabbione> it can take any random time... really
[20:39] <fabbione> i am trying to find the upstream patch
[20:39] <ivoks> this is what i get:
[20:39] <ivoks> dlm: connecting to 2
[20:39] <ivoks> then got connection, then extra connection, and then clurgmgrd says that it faild changing RG status
[20:39] <ivoks> and since then, nothing happens
[20:40] <fabbione> yeah
[20:40] <ivoks> i looked for a patch, but couldn't find it :/
[20:40] <fabbione> i am asking to the guy that did the first patch
[20:40] <fabbione> i can't find it
[20:40] <fabbione> it was either Lon or Patrick that did the patch
[20:40] <fabbione> IIRC Lon
[20:41] <ivoks> we can move conversation there, if you like
[20:41] <fabbione> it doesn't matter.. i found it
[20:41] <ivoks> i will test the patch and if it works, i'll let you know
[20:42] <fabbione> one second
[20:42] <fabbione> i need to see which one it is
[20:42] <fabbione> i found at least 2/3 on cluster-devel
[20:43] <fabbione> ivoks: the one in the bug is good
[20:43] <ivoks> ok
[20:44] <slangasek> lamont: is your disabling of db4.5 java on hppa still relevant if merging the -11 in unstable?  seems to be built fine on hppa in Debian
[20:46] <ivoks> fabbione: and, this is kernel bug :), so BenC will maintain it :)
[20:47] <fabbione> ivoks: well no.. i still need to provide a patch
[20:47] <fabbione> it's his problem to get it uploaded :)
[20:48] <\sh> ogra1, you use evolution right? do you think we can get another translation for "Benachrichtung bei neuen EMails" plugins? I have two with the same name but with different descriptions
[20:49] <fabbione> ivoks: if you are building kernel test packages, can you please provide them to the bug reporter too?
[20:49] <fabbione> and if you have issues to patch the kernel let me know
[20:49] <ivoks> yes
[20:49] <fabbione> the patch is based on a code that is slightly newer than the one we have in dapper
[20:49] <ivoks> um... i'm doing this on gutsy
[20:49] <fabbione> oh ok
[20:49] <fabbione> he reported in dapper
[20:49] <fabbione> no hold on
[20:50] <fabbione> your patch is different then
[20:50] <fabbione> i think
[20:50] <ivoks> joy :)
[20:50] <fabbione> gimme a sec
[20:51] <fabbione> ivoks: the patch is the same.. slightly different location. you want to patch kernel/fs/dlm/lowcomms.c
[20:51] <pitti> yay, I unbroke hardy
[20:51] <fabbione> ivoks: for dapper that file didn't exist :)
[20:51] <ivoks> :)
[20:52] <ivoks> now i just have to figure out how to properly patch kernel :/
[20:52] <fabbione> ivoks: it's easy.
[20:52] <fabbione> just apply the patch on top and build
[20:53] <ivoks> hm?
[20:53] <ivoks> ok
[20:53] <ivoks> that was backup solution :)
[20:53] <fabbione> gutsy didn't use any fancy pants patching system
[20:53] <fabbione> just apply the patch.. go for it :)
[20:54] <\sh> keescook, jdstrand : is anyone of you working on net-snmp sec fixes?
[21:06] <Nafallo> ion_: hehe. saw me joining the group on facebook, did you? ;-)
[21:07] <ion_> nafallo: Yeah. :-)
[21:08] <Nafallo> Keybuk: what the heck is smolt? :-)
[21:08] <pitti> Keybuk: ah, just talking to Lennart; the esd socket problem I mentioned to you this morning has a trivial solution
[21:08]  * Nafallo reads his e-mail :-)
[21:08] <pitti> Keybuk: -> go back to upstream's default and remove Debian's (small) change :)
[21:09] <Keybuk> Nafallo: http://rasher.dk/g/smolt
[21:09] <\sh> keescook, jdstrand : working on #164007 , gutsy just finished
[21:09] <Nafallo> Keybuk: cheers
[21:10] <Nafallo> lol
[21:10] <Nafallo> Keybuk: you could have just said jfgi ;-)
[21:18] <alex-weej> seb128: you say the "X system keyboard settings differ from your GNOME keyboard settings" dialog has been removed from GNOME -- what's the behaviour now?
[21:19] <seb128> alex-weej: dunno, I need to look, likely using the GNOME settings
[21:19] <alex-weej> ok -- has there not been a GNOME release since then?
[21:23] <seb128> alex-weej: re, did you get the reply?
[21:23] <alex-weej> no
[21:24] <seb128> dunno how they changed it, I would need to read the bug again, likely by always using the GNOME settings
[21:43] <DaBonBon> am i going wrong somewhere or is there no way to change LOCALE and LANG in ubuntu gutsy ?
[21:44] <pitti> DaBonBon: System -> Settings -> Language Support
[21:44] <DaBonBon> pitti: and for kubuntu ?
[21:44] <pitti> DaBonBon: or set it in /etc/environment
[21:45] <DaBonBon> thank you, pitti
[21:45] <pitti> DaBonBon: please ask in #ubuntu, this is not the right forum
[21:45] <DaBonBon> pitti: actually, i was going to file a bug
[21:45] <DaBonBon> because there is no localeconf in ubuntu, and unlike debians locale package, there is no dpkg-reconfigure frontend for it
[21:46] <DaBonBon> and i was wondering, is this a bug or an intentional thing ?
[21:48] <pitti> intentional, we prefer to use the language selector application
[21:48] <pitti> (there is a bug already, too)
[21:48] <DaBonBon> ah ok, thanks pitti
[21:48] <DaBonBon> sorry, i should have searched then.
[21:49] <DaBonBon> anyway pitti , thanks for the help.
[21:50] <\sh> pitti, could you do me a favour before you and I go to bed? ,-)
[21:52] <pitti> \sh: I guess I shuold ask for details before I say yes :)
[21:52] <\sh> pitti, just curious if this patch (http://sourceforge.net/tracker/download.php?group_id=12694&atid=112694&file_id=228217&aid=1712988) is not too dangerous for a security update...well actually this is what upstream of net-snmp was doing to fix this issue
[21:52] <ubotu> Gaim bug 1712988 "GETBULK with large max-repeaters DoS [CVE-2007-5846]" [Pri: 5,Closed fixed]
[21:53] <\sh> pitti, it's net-snmp not gaim...ubotu is wrong
[21:59] <pitti> \sh: upgrades will get the upstream defaults (100 responses or so?) without changing any config file, right?
[21:59] <pitti> \sh: I don't know snmp, but the patch logic seems ok if the point is to stop request flooding
[22:00] <\sh> pitti, yepp..if nothing is set in snmp.conf it will be set to the default 100/-1
[22:00] <\sh> pitti, yeah, the patch itself looks very safe..but I was unsure, if introducing new configuration settings is ok
[22:00] <pitti> seb128: ok for me to seed pulseaudio-esd-compat and perhals p-module-{x11,hal,gconf,zeroconf} to ubuntu-desktop?
[22:01] <\sh> pitti, so I backport all this stuff downto dapper tomorrow...gutsy is finished
[22:01] <seb128> pitti: sure, looks like a good idea to start giving those testing early
[22:01] <pitti> \sh: it's not common, but we did it in the past already, and sometimes it's just necessary
[22:01] <pitti> seb128: I just uploaded a fix for unbreaking multiuser, so it should be goo dnow
[22:01] <seb128> pitti: no option about the modules, not sure what they are useful for, but the pulseaudio-esd-compat looks a good thing
[22:01] <seb128> pitti: you rock
[22:01]  * seb128 hugs pitti
[22:02] <\sh> pitti, cool..so I'm on the secure side of life :) thx and good night :)
[22:02] <pitti> breaking policykit and pulse on one day and then going to holiday -- go me :)
[22:02] <pitti> \sh: sleep well, and thank you!
[22:02] <theunixgeek> How do I upgrade to GNOME 2.20?
[22:02] <pitti> "Ubuntu 7.10"
[22:02] <ogra> seb128, -x11 is the keyboard bell, -hal is used for device detection, -gconf puts the config into gconf
[22:02] <pitti> and zeroconf publishes your available audio sinks
[22:03] <ogra> i'm not sure why we want zeroconf though
[22:03] <ogra> sounds scary
[22:03] <pitti> you can route your desktop's sound output to your kitchen computer, and this makes it trivial to find :)
[22:03] <ion_> In a secure network, it’s awesome.
[22:03] <pitti> it's just about *finding*, not actually providing the server or service
[22:04] <pitti> but yeah, we can add that crack later :)
[22:04] <seb128> pitti: the set looks like some useful
[22:04] <pitti> I'll defer -x11 and -zeroconf, but gconf and hal are very useful IMHO
[22:04] <ogra> -x11 is great :)
[22:05] <ogra> configurable terminal beeps rock :)
[22:05] <ion_> Yeah
[22:05] <pitti> well, the standard bell is much nicer, yes
[22:05] <seb128> visual bell rocks
[22:05] <seb128> agressive beep on typo is not a good user experience
[22:06] <pitti> $ grep setterm .bashrc
[22:06] <pitti>     setterm -blength 15
[22:06] <pitti> FTW :)
[22:06] <Keybuk> compiz needs better visual bell animations
[22:06] <ogra> you can use a very nice and quiet calm beep :)
[22:06] <ogra> it accepts wav files iirc
[22:06] <Keybuk> like the bell-generating window should leap into the air, slam down on the desktop, sending ripples out across the screen
[22:06] <pitti> yeah, the current 'fade the entire screen' is horrible; I thought my driver was broken
[22:06] <seb128> ogra: you mean one that you don't hear? ;-)
[22:07] <Keybuk> pitti: you can change that to just fade the window
[22:07] <pitti> like Darth Vader's dark voice saying "ZOMG"
[22:07] <seb128> we should have a muted boot option
[22:07] <ogra> heh
[22:08] <Keybuk> seb128: heh, because the PowerBook Manoeuvre is so last year?
[22:08] <seb128> "PowerBook Manoeuvre"?
[22:09] <seb128> no, because having a laptop doing startup bong and beeps is annoying when you sit in a presentation or a meeting
[22:09] <Keybuk> that amusing moment when PowerBook owners turn it on, then suddenly cover the speakers with their hands in embarrassment
[22:09] <seb128> ah ;-)
[22:09] <Keybuk>  _
[22:09] <Keybuk> | |__  ___ _ _  __ _
[22:09] <Keybuk> | '_ \/ _ \ ' \/ _` |
[22:09] <Keybuk> |_.__/\___/_||_\__, |
[22:09] <Keybuk>                |___/
[22:09] <seb128> yeah
[22:09]  * pitti disabled that about 3 hours after getting his iBook
[22:09] <Keybuk> laptops should startup silent anyway
[22:09] <pitti> there's a MacOS app to disable it
[22:09] <Keybuk> why do we need a startup sound
[22:09] <Keybuk> what purpose does it actually serve?
[22:09] <pitti> you know, I hoped to get away with leaving it broken in Gutsy
[22:10] <pitti> but someone chased me up eventually to fix it :)
[22:10] <Keybuk> we should silently (heh) disable it, and see if anyone complains
[22:10] <pitti> "Acoustic OS fingerprinting"
[22:10] <pitti> Keybuk: we did, and they did
[22:10] <Keybuk> who was the "they" ?
[22:10] <ogra> well, that was a bug
[22:10] <ogra> Keybuk, they community :)
[22:11] <pitti> meh, lool killed the previous libgnome changelogs and didn't keep the bug numbers in the merge summary
[22:11] <Keybuk> bah, them :)
[22:11] <pitti> wasn't Dell involved there as well? in the bug?
[22:12] <seb128> Keybuk: the gdm sound is an accessibility thing, it tell you want the login screen is ready
[22:12] <Keybuk> sure, the gdm sound is vaguely useful
[22:12] <Keybuk> the Dum-di-dum-di-dum-dum-da-ting isn't
[22:12] <tkamppeter> pitti, msg
[22:12] <ogra> its branding
[22:12] <ogra> which makes it useful to some extent
[22:12] <pitti> bug 129029
[22:12] <ubotu> Launchpad bug 129029 in libgnome "[Gutsy Tribe-5] No Sound on Login Screen or during Login" [High,Fix released] https://launchpad.net/bugs/129029
[22:13] <pitti> NB the bug prio *sigh*
[22:13] <pitti> we should have mentioned it as a feature in the release notes
[22:13] <seb128> well, look like quite some users expect it
[22:13] <poningru> rofl
[22:13] <Keybuk> pitti: that's more likely because people assumed their sound cards were broken
[22:13] <seb128> dell being one of those (the bug has a dell task listed)
[22:13] <ogra> it makes you recognize other ubuntu users :)
[22:14] <Keybuk> it could probably have been commented as "we removed the sound because it embarrasses the hell out of people when their laptop sings to the world"
[22:14] <soren> pitti: "We've finally tracked down the setting that causes the annoying sound and startup and have disabled it."
[22:14] <poningru> Keybuk: its the same thing with the whole brown imho
[22:14] <Keybuk> and it would have gone silent
[22:14] <Keybuk> though some sounds are hilarious
[22:14] <Keybuk> like when a Thinkpad owner's battery goes low on a plane
[22:14] <slangasek> lamont: likewise, is there any reason to diverge from Debian on posix vs. pthreads mutexes?
[22:14] <Keybuk> the expression on some people's face is beautiful
[22:14]  * poningru thinks we should have sound like that
[22:14] <poningru> and it should sound like a ticking time bomb
[22:15] <Keybuk> NEEE-NAAW-NEEE-NAAW-NEEE-NAAW...ohfuckweregonnadie...Oh wait, Thinkpad user
[22:15] <ogra> heh
[22:15] <poningru> it would be hilarious on a plane especially
[22:15] <ogra> poningru, the brown is gone
[22:15] <poningru> yeah I was quite sad about that :(
[22:16] <Keybuk> ogra: it may be making a come back
[22:16] <ogra> really ?
[22:16] <Keybuk> the new theme Humans In Corduroy
[22:16]  * tonyyarusso prefers the current color scheme over the one mockup he's seen so far
[22:17] <ogra> lol, thats from dholbach, right ?
[22:17] <evand> bright yellow!
[22:17] <Keybuk> tonyyarusso: what mock-up is that?
[22:17] <poningru> link?
[22:18] <tonyyarusso> Keybuk: not sure - it was on digg a few days ago
[22:18] <Keybuk> oh
[22:18] <Keybuk> that amused me
[22:18] <Keybuk> it was, in no way, official
[22:18] <pwnguin> why doesnt someone just instrument human to have a color selector, and make the default orange?
[22:19] <tonyyarusso> 'k :)
[22:19] <pwnguin> at the moment, orange serves branding well. you can pick an ubuntu screnshot out from a mile away
[22:19] <Keybuk> pwnguin: there's two camps.  there's the "orange, because it's a colour from the ubuntu logo" and there's the "brown, because it's what we always used to have"
[22:20] <pwnguin> orange and brown are the same color :P
[22:20] <Keybuk> http://blog.eax.fr/images/blog/installation-ubuntu/20-ecran-login-gdm-ubuntu.jpg
[22:20] <Keybuk> ^ brown gdm
[22:20] <Keybuk> http://people.ubuntu.com/~mmueller/face-browser-2.png
[22:20] <Keybuk> ^ orange gdm
[22:20] <Keybuk> brown != orange :p
[22:21] <ion_> Was that the mockup you talked about?
[22:21] <pwnguin> brown is just a dark orange
[22:21] <Keybuk> ion_: no
[22:22] <poningru> http://blog.slyon.de/?p=154
[22:22] <poningru> that one?
[22:23] <evand> that looks fantastic
[22:23] <Keybuk> it does look rather nice
[22:23] <Keybuk> a bit too dark though
[22:24] <Keybuk> I really like the way he put the menu into the title bar
[22:24] <pwnguin> so is that an actual theme, or just a mockup?
[22:24] <Keybuk> just a mockup
[22:24] <Keybuk> I don't think some of the things there are even possible
[22:24] <pwnguin> like putting the menu bar into the title bar ;)
[22:24] <Keybuk> nice use of awn, shame it makes us look like apple
[22:25] <jdong> 17:21 < pwnguin> brown is just a dark orange
[22:25]  * jdong dies a little inside....
[22:25] <jdong> you're like my dad (colorblind) defending his assertion that my blue T-shirt is greenish grey.
[22:25] <pwnguin> except its true
[22:26] <ogra> Keybuk, awm is cool, i have a classmate image using only awn and compiz, makes it really uasable fast :)
[22:26] <pwnguin> grab a color picker and throw it into HSV
[22:27] <pwnguin> they're the same hues, just different brightness and saturation
[22:29] <Keybuk> ogra: I played with it for a while
[22:29] <Keybuk> the awn problem isn't the pretty, it's the interaction
[22:30] <ogra> errwell, my prob on the classmate was that you really need autohide with that screensize .... but thats not really practical imho
[22:31] <Keybuk> or make it so windows can overlap
[22:31] <Keybuk> is awn a window?
[22:31] <Keybuk> or is it above all other windows?
[22:31] <Keybuk> or below all other windows?
[22:31] <Keybuk> or is it in a special place no others windows can go until they've eaten the spice
[22:32] <Keybuk> and that's not even starting on what happens to icons there; if I start empathy, its icon should become interactive
[22:32] <ogra> for me it was always below all others
[22:32] <Keybuk> which works for screen size
[22:32] <ogra> which froced me to use autohide ... (which intrestingly is in fron of all other windows)
[22:32] <Keybuk> but then you have the application switching problem
[22:33] <ogra> right
[22:33] <Keybuk> and the notification problem
[22:33] <ogra> well, compiz helped here
[22:33] <Keybuk> I saw a cute demo of the problem
[22:33] <Keybuk> where the fullscreen window swung back out of the way (as if hinged at the top of the screen) so reveal the waiting dock underneath
[22:33] <Keybuk> so the notification revealed itself
[22:33] <ogra> heh
[22:34] <ogra> well, for its young age its a pretty good app imho :)
[22:34] <Keybuk> oh, it's totally a good app
[22:34] <ogra> just needs to mature a bit
[22:35] <Keybuk> I was playing with kde 4 stuff earlier
[22:35] <Keybuk> I really like the fact you can drag applets off the panel and onto the desktop
[22:35] <pwnguin> does the classmate have a touchscreen?
[22:35] <ogra> no
[22:36] <Keybuk> ah, my favourite UI problem
[22:36] <Keybuk> GNOME (and some apps in particular) is terrible for laptops
[22:37] <Keybuk> because it assumes you have a mouse!
[22:37]  * pwnguin has his tablet working okay with gnome+tablet
[22:37] <pwnguin> well, not in hardy right now, but dont blame GNOME for that
[22:38] <Keybuk> that's not what I mean
[22:38]  * ogra just upgraded to hardy, but fears the reboot sinc ehe heard pitti say he broke the world
[22:38] <Keybuk> like right now, I'm in xchat
[22:38] <pwnguin> alt+2
[22:38] <Keybuk> if I want to open another application, I have to move the MOUSE POINTER all the way across the screen to the top-right corner
[22:38] <Keybuk> without a Mouse, this is annnnoyingly hard
[22:39] <pitti> ogra: you are doomed if you have policykit 0.6-1ubuntu1
[22:39] <pitti> ogra: ubuntu2 is not built yet
[22:39] <pwnguin> eh
[22:39] <pwnguin> i knew it was smart not to install the policykit push
[22:39] <ogra> pitti, i have whatever was recent at 6pm UTC :)
[22:40] <pitti> ogra: but if you have and reboot, the workaround is to "dpkg-reconfigure policykit" and "/etc/init.d/hal start"
[22:40] <ogra> ah, trivial
[22:40] <pitti> it just stumbles over the fact that /var/run/PolicyKit is missing (with appropriate permissions)
[22:40] <pwnguin> Keybuk: how about quicksilver / deskbar / that new gnome app i saw
[22:40] <pitti> drwxrwxr-x 2 polkituser polkituser 60 2007-11-20 22:23 /var/run/PolicyKit/
[22:40] <ogra> i'm really scared about polkit
[22:40] <pitti> so was I :)
[22:40] <ogra> it might break the world in ltsp
[22:41] <pitti> that's why we break it that early
[22:41] <pwnguin> Keybuk: so you'd rather have the windows key be bound to the app menu, instead of alt+f1?
[22:41] <Keybuk> pwnguin: you're missing my point, I think
[22:41] <ogra> well, i have no ltsp code yet due to the upstream restructuring
[22:42] <Keybuk> the problem isn't that there aren't keyboard shortcuts
[22:42] <Keybuk> the problem is that the UI is designed to assume a mouse
[22:42] <Keybuk> in much the same way that the mobile UI doesn't
[22:42] <pwnguin> a mouse or a pointer device?
[22:42] <Keybuk> exactly
[22:42] <pitti> ogra: I think consolekit shuold be more relevant for LTSP, and we already have that in gutsy
[22:42] <Keybuk> it's the one thing you don't have an efficient version of on a laptop
[22:42] <pwnguin> is the problem that itt assumes a mouse or that it assumes a pointer device?
[22:42] <Keybuk> pointer device
[22:42] <ogra> pitti, well, they work hand in hand if they are both there
[22:42]  * pitti hails the .*kit invasion
[22:42] <Keybuk> at least, an efficient one
[22:42] <ogra> consolekit wasnt used much yet
[22:43] <pitti> yesterday I learned what "webkit" is
[22:43]  * pitti renames apport to crashkit
[22:43] <Keybuk> pitti: driverkit for restricted manager? :p
[22:43] <ion_> crapkit
[22:43] <keescook> \sh: cool, thanks for looking into net-snmp; I hadn't gotten to it yet.
[22:43] <pitti> Keybuk: well, I do need a proper name, but my current working theory is "Threepio" :)
[22:43] <keescook> er, \sh_away: ^^
[22:44] <Keybuk> pwnguin: again, another cute techo demo I've seen
[22:44] <Keybuk> using the touchpad on a laptop not as a pointer, but as a gesture device
[22:44] <Keybuk> to close a tab or window, you draw an X with your fingers
[22:44] <Keybuk> to move to the tab on the left, you draw a <
[22:44] <ion_> That’s a great idea.
[22:45] <Keybuk> to scroll, you draw a circle and keep drawing
[22:45] <pwnguin> meh. i just use the keyboard :P
[22:45] <mjg59> Easy enough to manage
[22:45] <Keybuk> yeah, probably quite easy
[22:45] <pitti> lool: hm, wrt. your DistCompilerFlags changes: I think you got the idea wrong, which indicates that the spec should explain it in a better way; let's discuss this in the next days
[22:45] <mjg59> For devices with a passthrough, you could even do it and keep that active
[22:45] <pwnguin> my desktop prety much lacks the normal mousy considerations
[22:46] <Keybuk> it obviously doesn't help with things like gimp and impress on a laptop, but you're pretty much doomed there anyway :)
[22:46] <pwnguin> Keybuk: if you really want a UI bug in gnome -- it assumes a keyboard!
[22:46] <Keybuk> pwnguin: again, a valid bug
[22:47]  * ogra wants sensoric gloves ... it looks good and you can make meaningful gestures in the air to steer your computer :)
[22:47] <pwnguin> Keybuk: ive chatted a bit with the CellWriter author, apparently metacity only allows gnome-panel to set up struts?
[22:47] <pitti> ogra: http://www.datahand.com/
[22:48] <ogra> pitti, well, i thought of somethig that looks a bit more .... like ... bicycle gloves or so :)
[22:49] <theunixgeek> How do I change the logo in the upper left (on the applications menu) to the GNOME foot?
[22:50] <ogra> pitti, they dont look like you could easily wave them around :)
[22:51] <ion_> Who wants to wave their hands around to control the computer?
[22:51] <ogra> ion_, me :)
[22:51] <pwnguin> i think the wii's pointed out the problems with that
[22:51] <pwnguin> its hella tiring
[22:51] <ogra> in a cape with a pointy hat :)
[22:52] <pwnguin> i saw a video of a guy who set up a wiimote and an led array to record fingers waved in the air
[22:53] <ogra> i think thats like bodybuilding ... or gardening ... its always tiring in the beginning ...
[22:53] <ogra> if you do it all the time its healthier than typing sitting on a desk all the time :)
[22:54] <pwnguin> ive heard of the marines using "hold your arms out level" as punishment
[23:01] <ogra> pitti, hmm, no hal issues here
[23:02] <pitti> ogra: maybe you didn't catch the latest hal yet
[23:02] <ogra>  0.5.10-2ubuntu1
[23:03] <pitti> yep, 2ubuntu2 enables PK
[23:03] <ogra> ogra@laptop:~$ COLUMNS=100 dpkg -l policykit
[23:03] <ogra> Kein Paket gefunden, das auf policykit passt.
[23:03] <ogra> ah, yep
[23:39] <lamont> slangasek: posix vs pthreads mutexes???
[23:47] <slangasek> lamont: as names of configure options, yes :)
[23:47] <slangasek> lamont: i.e., --enable-posixmutexes vs. --enable-pthreadsmutexes=yes; the latter is in your patch to db4.5 in Ubuntu, the former is what Debian is now using
[23:47] <lamont> where is that showing up?
[23:48] <lamont> package?
[23:48] <slangasek> db4.5
[23:48] <lamont> I don't think that was my doing... I'd ask doko.
[23:48] <slangasek> hmm, you uploaded it :)
[23:48] <slangasek> 4.5.20-5ubuntu2:   * enable NPTL across the board for linux
[23:49] <lamont> ok.  NPTL changes --> if I did it, it was because someone told me to (as in doko, jbailey, et al.()
[23:49] <slangasek> ok
[23:49] <slangasek> doko: ping
[23:51] <lamont> I do know that the switch to NPTL in ubuntu (1) is a precursor to debian eventually getting there (2) happened early in ubuntu because (a) we want it and (b) all of ubuntu architectures were ready for NPTL in edgy, and (3) is why hppa dropped out of ubuntu in edgy - it finally had working NPTL late in fiesty.
[23:51] <lamont> not sure which, if any, architectures are still holding debian back from going there.
[23:51] <slangasek> yeah, this was a fairly recent ubuntu change, db4.5 wasn't even around in etch
[23:52] <StevenK> lamont: Could I impose on you on raise the build priority of helix-player 1.0.9-0ubuntu3?
[23:53] <lamont> StevenK: arch?
[23:53] <StevenK> lamont: All of them :-)
[23:54] <lamont> StevenK: done.  you're at 900 now, so you still lose to all of main
[23:54] <lamont> but beat all of universe
[23:55] <lamont> have a nice day
[23:55] <StevenK> lamont: Thanks. It's been waiting for 7 hours already, hopefully it won't be too much longer.
[23:55] <ogra> woah, firefox 3 in hardy is evil if you have a self signed cert for our https site
[23:55] <ogra> *younr
[23:55] <ogra> gah
[23:56] <ogra> *your
[23:56] <lamont> i386 has 6 packages ahead of it
[23:56] <lamont> ogra: what does it do?
[23:56] <StevenK> lamont: For now :-)
[23:56] <lamont> StevenK: I have a hard time justifying putting universe packages ahead of main...
[23:57] <ogra> lamont, it doesnt offer any easy confirmation dialog anymore ... you have to dig into the guts of the config and manually add an exception
[23:57] <lamont> that requires a more compelling argument.  bumping something to the head of universe just takes asking for it.
[23:57] <lamont> ogra: neat
[23:57] <lamont> glad I have my own CA that I use to sign such things... much simpler. :-)
[23:58] <ogra> well, many people wont ... they will just self build a ssleay cert ... https apache in gutsy ia a pita anyway
[23:58] <StevenK> lamont: It's fine, I can wait - I just didn't want to be waiting another 7 hours or more
[23:59] <lamont> right