[01:03] <geser> keescook: Hi, have you time to sponsor bug #137644?
[01:03] <ubotu> Launchpad bug 137644 in tar "[Fake sync]  tar 1.18-2build1 from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/137644
[01:04] <geser> it's the last tar upload to Debian unstable fixing CVE-2007-4131
[01:18] <keescook> geser: cool, thanks.  I will get to it.
[01:22] <keescook> geser: odd; I wonder why the orig is different?
[01:24] <geser> keescook: I don't know. The last upload was also a fake-sync.
[01:27] <keescook> geser: odd.  ubuntu's orig's base path is tar-1.18.orig whereas debian is tar-1.18.  No other file differences.  freaky
[01:28] <keescook> perhaps we had a 0ubuntu during early gutsy.
[01:28] <geser> yes, there war 1.18-0ubuntu1
[01:28] <keescook> aah, okay.
[01:30] <geser> keescook: interesting is that the tar from gnu.org has also a different md5sum (neither matching Debian nor Ubuntu) as is also bigger
[01:30] <keescook> hah.  odd
[01:33] <geser> looks like the texinfo files got removed (GFDL 1.1 licensed)
[01:33] <crimsun> 3/win 21
[01:33] <crimsun> (sorry)
[01:33] <geser> Hi crimsun
[01:35] <keescook> geser: uploaded :)
[01:37] <geser> keescook: thanks
[01:38] <keescook> thank you!  one less thing on my CVE merge list.  :)
[01:41] <ajmitch> speaking of CVEs, I should sync or patch phpgroupware
[02:12] <ion_> iwj: ldconfig doesnt seem to ever use triggers, since DPKG_RUNNING_VERSION is 1.14.5, not 1.14.5ubuntu11.
[02:52] <mekius> I have a PC with a via video card. When the xorg.conf gets created, it contains the vesa driver and not the via driver.  I have created a custom cd with the openchrome driver and need to know how to autodetect via chips and load these drivers.  What controls the creation of the xorg.conf?
[03:15] <Hobbsee> bad pygi!  no cookie!
[03:19] <ion_> But what if Im hungry?
[03:20] <Hobbsee> ion_: you're not pygi, you're OK
[03:20] <Hobbsee> oh, fudge.  the new openoffice has messed with my data.
[03:20] <Hobbsee> or maybe it was gnumeric
[03:20] <ajmitch> hello Hobbsee
[03:20] <StevenK> Bad calc? No cookie for him, either?
[03:20] <Hobbsee> hi ajmitch
[03:20] <Hobbsee> StevenK: exactly
[03:22] <ion_> hobbsee: I just had to continue the quotation of The Office. :-)
[03:22] <ion_> (US)
[03:23] <Hobbsee> ion_: ahhh.  havent seen that.
[03:23] <ion_> Its one of the best comedy series ive seen.
[03:24] <StevenK> The Office is a series, and The Castle is a movie ...
[03:24] <Hobbsee> still...
[03:26] <StevenK> The Office is also a US series, and a UK series.
[03:26] <StevenK> And it isn't clear which one ion_ is talking about.
[03:27] <ion_> to042254 < ion_> (US)
[03:27] <StevenK> Ah
[04:15] <sbalneav> Hobbsee: You about?
[04:16] <mneptok> HIIIIIIIIIIIIIIIIIIIIIIII!
[04:16] <sbalneav> heh
[04:16] <mneptok> drat. no one falls for that.
[04:16] <ajmitch> scary...
[04:16] <mneptok> must be my lack of body odor.
[04:17] <sbalneav> There a regression in Pidgin? I can't seem to add a Jabber account.
[04:17] <mneptok> sbalneav: i *think* the generic "Jabber" protocol type has been supersceded by a "Google Talk" type
[04:18] <mneptok> try adding your Jabber account as a Google Talk account. wha'ppens?
[04:18] <sbalneav> So, google talk is now jabber?
[04:18] <mneptok> always has been.
[04:18] <sbalneav> ok, I'll find out
[04:18] <mneptok> Jabber on Google infrastructure.
[04:18] <ion_> I guess its too late to get a new version of LLVM to gutsy. :-\ Gutsy has 1.8, 2.0 has been released and 2.1 will be released in three weeks.
[04:18] <Hobbsee> sbalneav: hiya!
[04:19] <sbalneav> Hobbsee: Just trying to figure out pidgin...
[04:19] <ion_> sbalneav: XMPP is the name of the protocol.
[04:19] <ajmitch> ion_: given that it's been a debian sync in the past, someone would need to package, test & get approval for the new version
[04:19] <mneptok> ion_: suave catch. thanks guy.
[04:20] <sbalneav> ah
[04:20] <mneptok> (XMPP)
[04:20] <ion_> It wouldnt hurt to say XMPP (Jabber) or something like that in the dialog.
[04:21] <Hobbsee> sbalneav: right...
[04:22] <mneptok> ion_: if we make it obscure we keep the n00bs off the protocol. unless you *want* North Korean feline horror-porn ads in Jabber.
[05:17] <bddebian> I don't suppose there are any archive admins awake at this hour?
[05:33] <ion_> Does anyone else notice tracker 0.6.2 searches not working?
[06:03] <fabbione> morning
[06:05] <bddebian> Hello fabbione
[06:05] <ion_> ning.
[06:59] <tepsipakki> crap, UDS overlaps with the Rush concert on 29.10. in Helsinki :/
[07:00] <desrt> and what do you feel is more important? :)
[07:01] <tepsipakki> desrt: well, I booked the tickets in April ;)
[07:02] <tepsipakki> Rush hasn't been to Finland before
[07:03] <tepsipakki> three years ago I had tickets to Stockholm, but it was too close to the birth of our first-born
[07:08] <Luke> asac: can you read the email I sent you a few days ago when you have a chance?
[08:20] <tepsipakki> keescook: thanks for doing the pam-0.99 merge, I'll test it right away
[08:30] <tepsipakki> keescook: seems to work just fine, with krb5 & ldap
[08:51] <dholbach> good morning
[09:31] <asac> Luke: i told you that i didn't receive any mail
[09:32] <asac> 21:36 < asac> Luke: yes ... haven't received any mail
[09:32] <asac> 21:37 < asac> even looked in spam folder
[10:49] <dholbach> mdke: I changed the version number of the ubuntu-docs upload to 7.09.1
[10:49] <seb128> siretart: why did you upload cdrtools, we already have cdrkit no?
[10:50] <StevenK> seb128: Do you have a moment for some archive admin type stuff/questions?
[10:50] <seb128> StevenK: yes
[10:51] <StevenK> seb128: Okay, it appears we can't distribute the virtualbox packaged called virtualbox due to trademark issues. Debian has sorted this, and has a virtualbox-ose package. The Debian Maintainer was nice to e-mail me to tell me about this.
[10:52] <TheMuso> If a build/archive admin is around, could they please give back synfigstudio on i386 and powerpc? Thanks.
[10:52] <StevenK> seb128: Shall I forward his e-mail into Launchpad, and you can tack the "Fine, everything removed" message on it?
[10:52] <StevenK> seb128: I've prepared a merge for virtualbox-ose, I'm in the middle of test building it.
[10:53] <seb128> TheMuso: needs to be a build admin, maybe ask Mithrandir or doko_
[10:53] <seb128> StevenK: yes, please open a bug
[10:53] <StevenK> seb128: Shall do.
[10:54] <StevenK> seb128: I'll bounce the original mail into Launchpad, and then fiddle the package and so on.
[10:54] <seb128> ok, thanks
[10:56] <pygi> seb128, wrt cdrtools : afaik, because users need a choice, and because it's better then  cdrkit
[10:57] <seb128> pygi: why do they "need a choice"?
[10:57] <seb128> pygi: isn't cdrkit already shipping cdrecord?
[10:57] <seb128> pygi: that's Debian modified version against stock upstream code?
[10:57] <pygi> seb128, it's shipping wodim, a counterpart. And it's not maintained, and it's buggy as hell
[10:58] <cjwatson> fix it?
[10:58] <pygi> cjwatson, fix unmaintained software? Interesting
[10:58] <cjwatson> err ... yes?
[10:58] <cjwatson> happens all the time
[10:58] <pygi> cjwatson, you'd be fixing it forever then
[10:59] <cjwatson> we call this "maintaining"
[10:59] <cjwatson> did whoever uploaded cdrecord remember to include the fix for bug 130376?
[10:59] <ubotu> Launchpad bug 130376 in cdrkit "crash while checking MD5sums on jigdo include list" [High,Fix committed]  https://launchpad.net/bugs/130376
[10:59] <ion_> pygi is a libburnia author. libburnia > cdrtools in the long run.
[10:59] <cjwatson> s/cdrecord/cdrtools/
[10:59] <cjwatson> ion_: speaking as cdimage admin, software that works now > libburnia right now
[11:00] <cjwatson> (the bug above existed in cdrtools too)
[11:00] <pygi> cjwatson, it existed in what revision of cdrtools? Newest?
[11:00] <pygi> ion_, let them use whatever they want, be shhh =)
[11:01] <cjwatson> pygi: since edgy
[11:01] <pygi> cjwatson, ergh, well, that's not newest
[11:01] <cjwatson> up to when I fixed it
[11:01] <pygi> perhaps it was fixed back then
[11:01] <cjwatson> it was hardly likely to be fixed by upstream now was it?
[11:01] <pygi> but I have a feeling I should rather withdraw from cd-recording -related discussion
[11:01] <cjwatson> given that jigdo is a Debian patch
[11:01] <pygi> true that
[11:01] <cjwatson> and it was not fixed in cdrkit until I sent the patch
[11:02] <cjwatson> so no, it was not fixed in the current version
[11:04] <pygi> plus, probably the only thing you're missing from libisofs now (tho there is still no  command line interface) is HFS/HFS+ for Mac spins
[11:07] <seb128> geser: cvxopt src/C/SuiteSparse has files under the LGPL but that's not mentioned in the debian/copyright, could you sort that with Debian?
[11:11] <dholbach> mdke: for gnome-user-docs, please pull from http://bazaar.launchpad.net/~dholbach/gnome-user-docs/fixes
[11:11] <seb128> cjwatson: there is a cvxopt upload in NEW (package coming from Debian with one change) which has some files under the LGPL but the debian/copyright only mentions GPL
[11:11] <seb128> cjwatson: the LGPL license text is shipped in the tarball though
[11:12] <seb128> cjwatson: would you accept the upload and bug Debian to fix it or reject it until that's fixed?
[11:22] <geser> seb128: will do
[11:23] <seb128> geser: thanks
[11:23] <soren> Do any of you have experience with this otpw solution? http://www.cl.cam.ac.uk/~mgk25/otpw.html
[11:24] <soren> It seems to work fairly well (it's been in Debian for about a month), but if you have bad experiences with it or something like that, I don't want to bother filing a NPFe for it.
[11:30] <StevenK> seb128: bug 137719
[11:30] <ubotu> Launchpad bug 137719 in virtualbox "Virtualbox under Gutsy" [Undecided,Confirmed]  https://launchpad.net/bugs/137719
[11:31] <StevenK> seb128: virtualbox-ose builds fine, I'll upload it in about 45 minutes.
[11:31] <seb128> StevenK: ok, so I just have to remove virtualbox for now?
[12:33] <iwj> stgraber: I've just got a bunch of bugmail due to you doing something not entirely comprehensible to a whole pile of bug reports.  Would you care to explain ?
[12:35] <dholbach> What does the state 'Failed to upload' mean? that happened to gnome-user-docs
[12:36] <Riddell> dholbach: it means soyuz broke
[12:36] <Riddell> or that the package failed one of soyuz' tests
[12:36] <dholbach> ok good, so it has nothing to do with me
[12:36] <dholbach> mdke: ^
[12:37] <Riddell> ask infinity to investigate
[12:37] <Riddell> infinity: so, can we get the sun-java debconf licence agreement pre-seeded in the buildds?
[12:38] <soren> dholbach: It may have something to do with you. Soyuz has implemented some new checks what we need to deal with.
[12:38] <soren> dholbach: It requires the existence of debian/copyright, for instance.
[12:39] <dholbach> hrm
[12:39] <dholbach> well, it exists :)
[12:39] <soren> dholbach: The REJECT mail didn't say what the problem was?
[12:39] <soren> dholbach: debian/copyright was just an example. I don't know if they added other checks, too.
[12:40] <dholbach> ok got it
[12:40] <dholbach> sorry
[12:41] <dholbach> mdke added the pre-depends on dpkg in debian/control, not in debian/control.in
[01:02] <pygi> cjwatson, would you be so kind to gimme the lines that ubuntu uses to do re-spins?
[01:03] <cjwatson> pygi: I'm sorry, could you clarify exactly what you're talking about? respins of what?
[01:04] <pygi> cjwatson, of iso images. mkisofs/genisoimage lines
[01:05] <cjwatson> pygi: we don't do respins; we build every image from scratch
[01:05] <pygi> cjwatson, that's what I meant :P
[01:05] <cjwatson> pygi: the code is all in http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ (check out the things listed in configs/devel as well)
[01:06] <pygi> cjwatson, will do, thank you
[01:06] <cjwatson> why does vmware drive my PC speaker mad?
[01:10] <pygi> cjwatson, no mkisofs lines in cdimage mainline, but I'll checkout the things in config/devel
[01:10] <cjwatson> pygi: it's in debian-cd
[01:10] <pygi> yup, hunting it now
[01:10] <cjwatson> easier to follow if you have all the bits though
[01:24] <StevenK> seb128: virtualbox-ose in the process of uploading. Please accept at your leisure.
[01:25] <pygi> cjwatson, I think amd64 and i386 images could easily be built by some simple libisofs frontend
[01:26] <pygi> I gotta create one for fedora some time in the future, so you might want to try it when it's done
[01:26] <iwj> ion_: You are correct.  The test system I was using evidently has some difference.
[01:26] <cjwatson> pygi: does libisofs do jigdo?
[01:26] <pygi> cjwatson, no, not really
[01:26] <cjwatson> that's necessary for us
[01:27] <pygi> sadly, I have 0 clues about jigdo :-/
[01:30] <pygi> cjwatson, are you aware of any specification for jigdo?
[01:33] <pygi> I guess jigdo isn't really the task for libisofs directly, but rather some fronted?
[01:33] <\sh> doko, when you listen, what could be wrong when gcc -m32 -o bla foo.c doesn't work
[01:33] <siretart> well, regarding cdrtools. I've been in contact with Joerg S. (upstream) and pygi about it.
[01:34] <siretart> we are both not really interested in maintaining it properly, like in doing more maintenance than packaging, mainly because we both think the support upstream gives is best suited for this package for several reasons (which do not really matter here)
[01:35] <siretart> its right that we have cdrkit, which is a fork from a quite old version of cdrecord
[01:35] <siretart> upstream of cdrecord has done quite a lot of work in cdrtools, like adding blue ray support and improving a lot of things in mkisofs
[01:35] <cjwatson> pygi: talk to Steve McIntyre
[01:36] <siretart> therefore I do think that it is worthwile to have it in multiverse
[01:36] <siretart> from the licencing, I do think the lincense should be good enough for multiverse
[01:36] <siretart> if the ftpmasters disagree, I'm curious to read the reject message
[01:36] <siretart> and will discuss it with upstream
[01:36] <pygi> cjwatson, oki, I'll try to hunt for him
[01:36] <\sh> siretart, you want to discuss it with joerg schilling?
[01:37] <siretart> \sh: I had a several hour phone conversation with him. yes
[01:38] <\sh> siretart, I wonder if Joerg is going away of his decission to change the licence...
[01:38] <pygi> cjwatson, would you mind telling me his nick if you know?
[01:38] <cjwatson> pygi: Sledge
[01:38] <\sh> anyways...I wonder what's wrong with gcc and friends not wanting to run with -m32
[01:38] <pygi> cjwatson, ah, right  ... he's always busy  :-/
[01:38] <cjwatson> pygi: have you tried e-mail, or only IRC?
[01:39] <pygi> cjwatson, irc, but I'll talk, no worries
[01:39] <cjwatson> or you could mail the debian-cd list
[01:39] <pygi> got it
[01:40] <cjwatson> Riddell: DESKTOP_SESSION is always set inside kdm, isn't it?
[01:40] <siretart> \sh: ideally, joerg wants to have cdrtools to be licenced as CDDL completely. this isn't possible atm because of 2 parts: smaller hfs related parts of mkisofs, the hfs support library and the schily autoconf system (which are all derived from GPL software)
[01:40] <siretart> \sh: he has no interest going back to GPL for reasons that are rather difficult to understand
[01:40] <geser> seb128: re cvxopt copyright file: I've looked at the copyright file again and it mentions the LGPL at the end of the file (see http://packages.debian.org/changelogs/pool/main/c/cvxopt/current/copyright)
[01:41] <\sh> siretart, yeah, I read some mails about those issues...
[01:41] <siretart> seb128: did that answer your question regarding cdrtools?
[01:42] <geser> seb128: the mentions projects have their files below src/C/SuiteSparse
[01:42] <Riddell> cjwatson: set to "kde" yes
[01:43] <Riddell> well, I suppose its different for other desktops
[01:43] <cjwatson> Riddell: excellent, thanks
[01:43] <cjwatson> gdm has it set to "default"
[01:47] <cjwatson> ogra: your seed change didn't work because you used a source package name
[01:47] <cjwatson> ogra: if you want to include all binaries from that source, the syntax is "* %edubuntu-addon-meta"
[01:47] <ogra> oh, crap, indeed
[01:56] <\sh> doko, I have the strange feeling that compiling 32bit on amd64 is somewhat broken...using -m32
[02:06] <\sh> argl
[02:06] <\sh> doko, unping..gcc-multilib was missing for building -m32 binaries on amd64
[02:07] <\sh> eventually you think about adding it as dep to lib32gcc1 package
[02:18] <stgraber> iwj: uhmm, Brian told me the same yesterday, I guess it has something to do with the QA Tracker being able to set tag (but had to use some forcing parameters to python-launchpad-bugs Brian gave me), now the tracker should be using the ubuntuqa account and shouldn't cause any kind of problem anymore (I'm looking at my bugmail though)
[02:18] <stgraber> iwj: It happened yesterday at ~20:00 UTC, did you see that again today ?
[02:20] <cjwatson> seb128: what bit of GNOME is responsible for starting gnome-settings-daemon?
[02:21] <Mithrandir> asac: did you see the mail from Jon Villalovos about invoke-rc.d and NM?  What do you think about his suggestion?
[02:23] <iwj> stgraber: I saw changes at 22ish UTC yesterday, yes, but nothing since then.
[02:23] <iwj> stgraber: The thing that's odd about it is that it seems to have involved changes to descriptions.
[02:24] <geser> Hi Hobbsee
[02:24] <asac> Mithrandir: I chatted with him yesterday ... I have to test it and will do a cherry-picked upload for that.
[02:24] <Mithrandir> asac: ok, it would be good if you could prioritise that, as it's causing them some pain.
[02:24] <iwj> Eg in bug 131284 a pair of leading spaces were mangled into a pair of =C2=A0 (in Q-P UTF-8).
[02:24] <ubotu> Launchpad bug 131284 in yelp "about ubuntu menu item results in page not found" [Medium,Fix released]  https://launchpad.net/bugs/131284
[02:25] <asac> Mithrandir: yes thats why i plan to do a quick upload for that
[02:25] <Hobbsee> hi geser
[02:25] <stgraber> iwj: yes and looking at the change I find no diff ...
[02:25] <Mithrandir> asac: excellent, thanks.
[02:27] <iwj> ** Description changed:
[02:27] <iwj> ...
[02:27] <iwj> -   Page not found
[02:27] <iwj> + =C2=A0=C2=A0Page not found
[02:28] <stgraber> ouch
[02:28] <iwj> (When I ask my MUA to show me the Q-P.)
[02:28] <stgraber> and that's the result of a .tags.append("iso-testing") and a .commit()
[02:29] <StevenK> Mithrandir, seb128: Could one of you accept virtualbox-ose in source NEW, please?
[02:33] <geser> StevenK: is that the version with non-free source in the orig.tar.gz? there was a discussion about virtualbox on the debian-devel ML
[02:34] <StevenK> It has dfsg in the version. So no.
[02:35] <geser> the problem is that it contains non-free source in the dfsg tarball
[02:36] <StevenK> It does?
[02:36] <geser> http://lists.debian.org/debian-devel/2007/09/msg00115.html
[02:36] <StevenK> geser: No spoiling my night.
[02:36] <geser> http://lists.debian.org/debian-devel/2007/09/msg00125.html
[02:40] <StevenK> Well, no fixed virtualbox-ose yet.
[02:40] <StevenK> seb128, Mithrandir: Please REJECT it, due to what geser pointed out.
[02:49] <Mithrandir> StevenK: rejected.
[02:49] <Hobbsee> yay, bloodbath
[02:54] <StevenK> Mithrandir: Thank you
[02:56] <\sh> did someone do something with ion3-xinerama-mod package?
[02:56] <\sh> I just received very strange mails about it
[02:56] <pygi> it was moved to multiverse afaik?
[02:57] <geser> yes
[02:57] <\sh> hmm...
[02:57] <\sh> see #launchpad pls :)
[03:03] <Luke> asac: ah sorry - I never got that. I'll resend it.
[03:19] <doko> Riddell: looking into the broken sip4-qt3 after your last upload ... do you really want to have sipconfig.py in python-sip4 ?
[03:21] <Riddell> doko: it was a quick fix because mountconfig needed it, I didn't look into why it was needed I'm afraid
[03:21] <doko> Riddell: your quick fix did remove sipconfig.py from all packages ...
[03:22] <doko> and missing replaces.
[03:31] <\sh> doko, is it possible to add gcc-multilib as dep or recommends to at least lib32gcc1? without this package nobody can compile 32bit apps/libs on amd64 (running x86_64 arch)
[03:33] <doko> \sh: absolutely no
[03:35] <asac> Luke: where did you send it? maybe open a bug ... thats far better to track for me
[03:37] <\sh> doko, and whatabout a hint in the description of lib32gcc1? ;) I wonder if it's obvious that you need gcc-multilib when you want to use e.g. -m32
[03:38] <doko> \sh: we usually don't add suggests in libraries for development packages
[03:40] <\sh> doko, I know...so, where do we document this for developers (!= package maintainers) who don't know about the existence of gcc-multilib
[03:43] <doko> \sh: why, or for what do you need to build something with -m32?
[03:44] <doko> we don't support a complete biarch development environment
[03:45] <doko> Riddell: fixed your "quick fix" ;p
[03:45] <\sh> doko, it hasn't to do anything with packaging, but when you need (as a software developer) some software, which doesn't run natively on x86_64, but as 32bit compilation (with the provided biarch libs we have) .. so you start with gcc -m32...and this doesn't work without installin this multilib package...
[03:47] <doko> \sh: as a developer you should install the compiler, and have a look what the compiler package suggests ...
[03:48] <Riddell> doko: great, thanks
[03:48] <Riddell> doko: did you look at the python qt dbus issue too?
[03:48] <doko> Riddell: would you mind building kde4 using g++-4.2 -fhidden-visibility?
[03:49] <doko> Riddell: I did, but the package did fail to build due to the python-sip4 mess
[03:49] <Riddell> doko: post feature freeze that would make me very scared
[03:49] <Riddell> what does kde 4 have to do with python sip?
[03:51] <doko> Riddell: I don't know
[03:54] <StevenK> doko: We played that game earlier - it made the modules not load at all.
[03:56] <doko> StevenK: with g++-4.2?
[03:56] <StevenK> Nope, not with g++-4.2
[03:57] <doko> StevenK: according to Riddell upstream builds their packages with 4.2 by default
[04:10] <bddebian> Heya
[04:11] <bddebian> Could some kindly archive admin please give back player?
[04:12] <bddebian> Should build with newer python-central
[04:13] <Riddell> StevenK: that was KDE 3, I've no idea how kde 4 reacts to hidden-visibility or even how to enable it
[04:16] <bddebian> do be do be dooo
[04:16] <StevenK> Ahh
[04:18] <seb128> cjwatson: gnome-session starts gnome-settings-daemon but it can also be spawned when required (that happens when running some applications like the appearance capplet out of GNOME)
[04:19] <Mithrandir> bddebian: archive admins can't do give-backs, buildd-admins can.  I've done a give-back now
[04:20] <seb128> siretart: yes, I'm not sure we should have it duplicated though
[04:20] <bddebian> Mithrandir: Oh, sorry, I did not know there was a difference
[04:20] <bddebian> And Thank You :-)
[04:22] <\sh> keescook, ping question about drupal in feisty (5.1 is exploitable...)
[04:24] <seb128> geser: alright, cvxopt accepted
[04:48] <ogra> sladen, bug 126987 sounds like the return of the broken icon cache (i think dholbach fixed that once in former releases)
[04:48] <ubotu> Launchpad bug 126987 in network-manager "The NetworkManager applet could not find some required resources.  It cannot continue." [Undecided,New]  https://launchpad.net/bugs/126987
[04:49] <dholbach> sladen: running it under  strace -e open,stat  could help to find out what's wrong
[04:50] <dholbach> but yeah, it could be the icon cache
[04:50] <ogra> in bug 137760 it reports some detail at least, i wonder why it doesnt do that with other stuff
[04:50] <ubotu> Launchpad bug 137760 in gnome-power-manager "Network Manager applet cannot show Connection Information window" [Undecided,New]  https://launchpad.net/bugs/137760
[04:51] <dholbach> although it should use dh_icons now - debian/rules looks fine
[04:53] <StevenK> seb128: Can you give the gimp 2.4.0~rc2 in my PPA a once over?
[04:53] <seb128> StevenK: will do
[04:53] <\sh> keescook, please have a look at bug 137762, I'm trying to secfix the dapper version as well, and will have a look at edgy..(dapper will be horrible)
[04:53] <ubotu> Bug 137762 on http://launchpad.net/bugs/137762 is private
[05:06] <Hobbsee> stgraber: ping/
[05:13] <siretart> seb128: we need to have it duplicated because of licencing reasons. cdrtools (IMO) not suitable for universe nor main, but that's something I cannot really answer. An archive admin would need to assess that
[05:15] <bddebian> Are we supposed to update the Maintainer field for -Xbuild1 revisions?
[05:16] <geser> bddebian: no
[05:17] <bddebian> geser: Thx
[05:21] <cjwatson> seb128: oh, right, it's hardcoded in /usr/bin/gnome-session; I was looking for configuration files. thanks
[05:24] <mathiaz> keescook, jdstrand: I've been looking at bug 120085
[05:24] <ubotu> Launchpad bug 120085 in sysklogd "Various problems running syslogd with "-u syslog" option" [Medium,Triaged]  https://launchpad.net/bugs/120085
[05:25] <mathiaz> it seems that syslogd is not running under the syslog user since edgy
[05:26] <keescook> mathiaz: so this may be an upgrade issue?
[05:26] <cjwatson> ogra did the first merge of sysklogd in feisty
[05:26] <mathiaz> keescook: well it seems that there are two issues in the bug
[05:26] <keescook> tepsipakki: great! I didn't get a lot of authentication users tested, so if you got ldap, that's good.  :)
[05:26] <mathiaz> one for dapper and one for gutsy
[05:26] <cjwatson> but he did not follow the merge policy so we cannot tell what he intended
[05:27] <cjwatson> (i.e. he didn't list the changes being kept)
[05:27] <cjwatson> oh, but that list went into 1.4.1-20ubuntu2 I think
[05:27] <cjwatson> it does not list pitti's privilege dropping patch, so it looks like that's when it was dropped
[05:28] <mathiaz> well.. the privilege dropping patch is still there
[05:28] <jdstrand> mathiaz: sure enough, I checked a dapper box and syslog is running as non-root
[05:28] <jdstrand> mathiaz: long-time dapper box too
[05:28] <cjwatson> mathiaz: clearly not working :)
[05:28] <ogra> oh, sorry
[05:28] <mathiaz> jdstrand: yes. in dapper in runs under syslog user
[05:28] <mathiaz> the user privilege patch is still there
[05:28] <jdstrand> mathiaz: well, that will make it easier to track down
[05:29] <mathiaz> well the problem is tracked down.
[05:29] <mathiaz> the reload action in the script has changed
[05:29] <cjwatson> the diff is a mess, it has a changelog.orig and random changelog edits
[05:29] <mathiaz> it sends a HUP signal instead of stop/start
[05:29] <cjwatson> control.orig
[05:29] <mathiaz> cjwatson: yes. I've seen that.
[05:30] <mathiaz> cjwatson: there is also a new version in debian (that is actually a new version from upstream)
[05:30] <mathiaz> cjwatson: after three or four years..
[05:30] <jdstrand> mathiaz: have you tried the old stop/start behavior on a newer than dapper box?
[05:31] <mathiaz> jdstrand: that would work then.
[05:31] <cjwatson> mathiaz: it's broken because it does SYSLOGD="-u syslog" and then sources /etc/default/syslogd, which sets SYSLOGD=""
[05:31] <mathiaz> jdstrand: but that means that logging stops for some time
[05:31] <cjwatson> it should source the configuration files and then do something like SYSLOGD="$SYSLOGD -u syslog"
[05:32] <mathiaz> cjwatson: correct. But running under the syslog user requires some changes in the cron script that rotates logs
[05:32] <mathiaz> cjwatson: and we should also take care of changing the ownership when upgrading the package
[05:32] <mathiaz> cjwatson: the ownership of log files I meant
[05:32] <cjwatson> yes
[05:33] <mathiaz> cjwatson: would this be accepted in gutsy ?
[05:34] <mathiaz> the other solution would be to remove the -u syslog option from the init script and run syslogd asroot
[05:34] <mathiaz> which is the case for edgy and feisty
[05:37] <cjwatson> mathiaz: yes
[05:37] <cjwatson> mathiaz: it's clearly a regression
[05:37] <cjwatson> privileges were intended to be dropped, and now they are not
[05:38] <cjwatson> ogra: ok, it was just hard to tell from the changelog whether it was your change or not :) changelog entries in edgy indicated that the privilege dropping patch had been preserved
[05:38] <cjwatson> and yours was the first one that wasn't clear
[05:38] <ogra> ah, right
[05:38] <ogra> intresting that it shows up in the edgy changelog but isnt used there either apparently
[05:39] <mathiaz> cjwatson: another solution would be to use an apparmor profile to protect syslogd
[05:39] <ogra> mathiaz, will that affect remote loggon in any way ?
[05:39] <ogra> *logging
[05:40] <ogra> (i need that in ltsp=)
[05:40] <mathiaz> ogra: I'm not sure if it would.
[05:40] <mathiaz> ogra: in ltsp you need to be able to enable remote logging on the server
[05:40] <ogra> right
[05:40] <mathiaz> ogra: and also on the clients
[05:40] <ogra> we have the override file in /etc/ltsp for that atm
[05:41] <ogra> (for the server)
[05:41] <ogra> well, the clients just use logger which points to the server
[05:41] <mathiaz> ogra: the client don't have a syslogd running ?
[05:41] <ogra> we dont add any extra confoig there
[05:41] <ogra> right
[05:42] <mathiaz> ogra: ok. So you just run syslogd with the -r option on the server.
[05:42] <ogra> oh, wait
[05:42] <ogra> we enabled it in feisty
[05:42] <ogra> so we have syslog running on the clients
[05:42] <ogra> and yes, we enable syslog with -r
[05:43] <ogra> the initscript respects /etc/ltsp/syslog if it exists
[05:43] <mathiaz> ogra: yes. correct.
[05:43] <ogra> err ... *syslogd
[05:43] <mathiaz> ogra: on the clients, syslogd is setup to do remote logging on the server ?
[05:43] <ogra> yes
[05:44] <mathiaz> ogra: I don't see any problem with an apparmor profile in that case.
[05:44] <ogra> /etc/syslog.conf gets: *.* @<serverip> during a client boot
[05:46] <cjwatson> mathiaz: I don't think apparmor is a substitute for dropping syslogd's privileges
[05:47] <geser> doko: can you please look at the build log http://people.debian.org/~lucas/logs/2007/08/28/libtritonus-java_20070428-3_gutsy32.buildlog
[05:47] <geser> doko: [javac]  /usr/bin/ecj-bootstrap: line 26: /usr/bin/gij-4.2: No such file or directory
[05:48] <mathiaz> cjwatson: why ?
[05:48] <geser> doko: who is missing the depends on gij-4.2? it is ecj-bootstrap or should libtritonus-java build-depend on gij-4.2?
[05:49] <jdstrand> cjwatson: I agree
[05:49] <jdstrand> mathiaz: I have been thinking about this and feel that apparmor would be good additional protection for remote logging
[05:50] <jdstrand> mathiaz: however, running it as an unprivileged user gives additional local protections (as keescook mentioned yesterday)
[05:51] <jdstrand> mathiaz: when it runs as root, a bug in syslog that could be triggered locally (eg via its conf file, etc) would allow full access
[05:51] <jdstrand> mathiaz: running as an unprivileged user protects against that
[05:51] <jdstrand> mathiaz: doing *both* is ideal
[05:52] <doko> geser: ecj-bootstrap is gone, this should be ecj
[05:52] <mathiaz> jdstrand: full access ? I don't see why - if access is not granted in the profile, the process won't have access to the ressource.
[05:52] <bddebian> geser: Well since you are the java expert now, fix freemind ;-P
[05:53] <stgraber> Hobbsee: pong
[05:53] <jdstrand> mathiaz: this gets at the hard links issue keescook mentioned
[05:53] <Hobbsee> stgraber: what did iyou actually change with https://bugs.launchpad.net/bugs/122500 ?
[05:53] <ubotu> Launchpad bug 122500 in ubiquity "Kubuntu - Mount dialog always gets shown when the disk is mounted, in the middle of the install" [Undecided,Fix released] 
[05:53] <keescook> just lots of security layers.  :)
[05:53] <stgraber> Hobbsee: tag using python-launchpad-bugs
[05:54] <stgraber> Hobbsee: it's the new script we are using for the QA tracker
[05:54] <mathiaz> keescook: ok. I see your point.
[05:54] <jdstrand> keescook: exactly
[05:54] <stgraber> Hobbsee: http://codebrowse.launchpad.net/~ubuntu-qa-tracker-devel/ubuntu-qa-tracker/trunk/annotate/stgraber%40ubuntu.com-20070904221630-ycv4fev6s04nqvbr?file_id=lpintegration.py-20070901183400-o9v3rkpvbowj3yam-3
[05:55] <stgraber> Hobbsee: it's the tagBug function
[05:55] <mathiaz> jdstrand, keescook: could you re-explain the hardlink issue ?
[05:55] <stgraber> Hobbsee: uhm, in fact that code isn't really up to date, let me upload the new one somewhere
[05:56] <keescook> mathiaz: sure.  in the case that you have unconfined processes that are "attacker controlled" (i.e. a local malicious user)
[05:56] <stgraber> Hobbsee: http://paste.stgraber.org/3407 here is the one that's currently running
[05:56] <keescook> you can (possibly) set up an environment that AppArmor wasn't expecting
[05:56] <Hobbsee> stgraber: ahhh....
[05:57] <keescook> hardlinks to areas like /tmp will "avoid" the apparmor profiles.
[05:57] <keescook> for example, let's say you hardlink to /root/.ssh/authorized_keys into /tmp, and then exploit something that causes the root-run process to write to /tmp
[05:58] <stgraber> Hobbsee: bdmurray suggested to put the force_changes=True,ignore_lp_errors=False as tag changes weren't saved previously
[05:58] <Hobbsee> stgraber: it's just doing annoying things via email
[05:58] <keescook> AA won't stop that, since the hardlink action was unconfined (and allowed)
[05:58] <bddebian> Heh
[05:58] <cjwatson> mathiaz: because we allow people to remove apparmor; it is not mandatory
[05:59] <cjwatson> mathiaz: we should be shipping a secure standard Unix system as well as supplementing its safeguards with tools such as apparmor
[05:59] <cjwatson> mathiaz: multiple safeguards are always better than just one, as jdstrand points out
[06:01] <StevenK> seb128: Any news about gimp?
[06:01] <seb128> StevenK: what do you need exactly about it?
[06:02] <StevenK> seb128: I've tested it myself, I'd just prefer someone else to also do so.
[06:02] <mathiaz> keescook: Thanks for the explanation.
[06:02] <mathiaz> cjwatson: Ok. I see your point and agree.
[06:02] <geser> doko: kaffe-pthreads still depends on ecj-bootstap which pulls ecj, but nothing pulls in gij-4.2
[06:03] <mathiaz> keescook: would this be fixed in AppArmor itself ?
[06:03] <StevenK> geser: I think kaffe currently fails to build.
[06:03] <keescook> mathiaz: no, since it's outside of confinement, there is nothing that can be done.
[06:04] <unggnu> hi all
[06:04] <keescook> however, I have some patches from GRsecurity that I'm trying to get into the mainline kernel that would address the specifics of hardlink and symlink abuse.
[06:04] <keescook> not happening for gutsy (if ever)
[06:06] <doko> geser: I see, as a workaround, let kaffe-pthreads depend on ecj-gcj
[06:06] <unggnu> mvo: Hi, I have red that you are the assignee of "System cleanup". Doesn't it makes sense to run "apt-get autoclean" after upgrade or is already run?
[06:06] <doko> will fix it
[06:07] <StevenK> mvo: Around?
[06:09] <geser> doko: how does this help with finding /usr/bin/gij-4.2 (not gcj-4.2)?
[06:09] <unggnu> mvo: I think that most people upgrade from Internet and not CD so I guess that there will be around 500 MB of unneeded package installation files or at least all updates installed since first installation.
[06:09] <mvo> unggnu: yes, but its not that important IMHO as the apt cleanup cronjob will take care of this after 1 days normally anyway
[06:09] <mvo> StevenK: yes
[06:09] <unggnu> mvo: There is a cronjob which cleans it?
[06:09] <doko> geser: /usr/bin/ecj
[06:10] <dr1> hey guys, I need to make changes to an ISO file, is there a way to mount it such that I can write to it in linux
[06:10] <unggnu> mvo: Btw. thanks for your reply :)
[06:10] <StevenK> mvo: sexy-python is now called python-sexy. Do you have changes to gnome-app-install, or should I just change that bit and upload it?
[06:10] <mvo> unggnu: yes, there is a apt.cron that regularly cleans out /var/cache/apt/archives
[06:10] <Hobbsee> dr1: #ubuntu for support
[06:10] <dr1> ok
[06:10] <dr1> thanks
[06:10] <Hobbsee> dr1: and man mount
[06:10] <unggnu> mvo: Ok, thanks.
[06:10] <mvo> StevenK: thanks! let me change it please, I have some other pending changes in my bzr tree
[06:10] <StevenK> mvo: Sure. Glad to help.
[06:10] <mvo> unggnu: but thanks for raising it, I will look at this again
[06:11] <seb128> StevenK: the gimp upload looks fine and work correctly
[06:11] <seb128> StevenK: I've tried on i386
[06:12] <StevenK> seb128: And it worked for me on amd64, excellent.
[06:12] <StevenK> cjwatson, Hobbsee: So, shall I upload gimp 2.4.0~rc2? :-)
[06:12] <seb128> StevenK: they should stop versionning the binary though
[06:12] <seb128> the update broken my panel launcher
[06:12] <seb128> s/broken/broke
[06:12] <StevenK> seb128: I can fix that, if you like.
[06:12] <geser> doko: I see now
[06:13] <seb128> StevenK: would be nice to have a the desktop using "gimp" rather than "gimp-version"
[06:13] <StevenK> seb128: Quick fix would be to add a symlink
[06:14] <seb128> there is a symlink gimp -> gimp-2.4
[06:14] <StevenK> Hrm. What is actually broken? I'm sure something is...
[06:16] <StevenK> Damn it, Thunderbird, check *all* of my folders for new mail!
[06:19] <seb128> StevenK:
[06:19] <seb128> $ grep Exec /usr/share/applications/gimp.desktop
[06:19] <seb128> Exec=gimp-2.4
[06:19] <seb128> StevenK: it should use "gimp" there
[06:19] <StevenK> Ah ha. I shall fix that.
[06:19] <seb128> otherwise if you dnd it to a panel it'll get the version coded to the launcher
[06:19] <seb128> and we update to 2.5 it'll be broken
[06:19] <seb128> and we can't change the user config on upgrade
[06:21] <StevenK> Exec=@GIMP_COMMAND@ %U
[06:21] <StevenK> Ugh. I'll dig when I get up.
[06:21] <Mithrandir> StevenK: you can tell it not to, at least on IMAP
[06:21] <seb128> don't bother with that now, we can fix later
[06:21] <Hobbsee> StevenK: it's a public holiday.  you can stay up late.
[06:21] <seb128> you can upload the new version if you want ;)
[06:21] <Hobbsee> well...fsvo public holiday, anyway.
[06:22] <StevenK> Mithrandir: Ah, it was only checking Inbox. My IMAP server sorts mail itself using sieve.
[06:22] <StevenK> Mithrandir: I found the magical switch
[06:22] <StevenK> Hobbsee: By rights, I should have gone to bed about 2 and a half hours ago.
[06:24] <StevenK> seb128: Right, Exec=gimp-2.4 can be fixed by just not replacing it in the .desktop, or by hacking configure.in. Personally, I prefer the first.
[06:25] <stgraber> Hobbsee: When was the last bugmail you receive from me (stgraber@ubuntu.com) or the tracker (qatracker@ubuntu.com) ?
[06:25] <seb128> StevenK: works for me
[06:26] <stgraber> Hobbsee: the automatic tag thing as been turned on yesterday at 22:00 (20:00 UTC) and there was a python-launchpad-bugs update since then, does that still happen ?
[06:26] <Hobbsee> stgraber: ~18 hours
[06:26] <iwj> ion_: Thanks for that report.  That was due to me not having rerun autoconf before uploading.  I keep getting caught out by that - must pay better attention.
[06:26] <iwj> 1.14.5ubuntu12 should fix it.
[06:29] <mvo> iwj: what is the issue with -ubuntu11? I just uploaded a version for the upgrade-pre-requists based on this ubuntu11
[06:30] <StevenK> seb128: You're sure it's okay to upload gimp? :-)
[06:35] <iwj> mvo: I forgot to run autoconf.
[06:35] <iwj> Looks like I got there first.
[06:35] <iwj> If you mail me your debdiff I'll merge it.
[06:36] <iwj> The consequence of not running autoconf is that the version number dpkg thinks it has is not correct and as a result the triggerisation of ldconfig doesn't take effect.
[06:36] <mvo> iwj: oh, I see. thanks, I will update my package tomorrow then. the upload is a "fork" (a new source package) that is build as a udeb just for the release upgrader
[06:37] <iwj> Glrgk.
[06:37] <iwj> What's the version number ?
[06:37] <iwj> I really mean: what's the version number in ./configure ?
[06:39] <iwj> Sorry to cause you inconvenience, anyway.
[06:47] <mvo> iwj: I don't know, no worries, I can attack the problem tomorrow
[06:48] <iwj> Sure.  If you took ubuntu11 then if you just rerun autoconf it will fix it.
[06:49] <iwj> Your build processes may have done that already.
[06:49] <iwj> grep 1.14.5 dpkg-strange-thing/configure will tell you too
[06:50] <iwj> PACKAGE_VERSION='1.14.5'    ... wrong
[06:50] <iwj> PACKAGE_VERSION='1.14.5ubuntu12'    ... right (provided value of 12 is at least 10)
[06:51] <iwj> If you get at all bogged down point me at the package and I'll fix if need be.
[07:01] <norsetto> keescook: ping?
[07:03] <keescook> norsetto: hello!
[07:03] <norsetto> hi :-)
[07:03] <norsetto> keescook: I wonder if you can give a look @bug 136302?
[07:03] <ubotu> Launchpad bug 136302 in sylpheed-claws-gtk2 "Sylpheed POP3 Format String Vulnerability" [Medium,Confirmed]  https://launchpad.net/bugs/136302
[07:04] <keescook> norsetto: yup, I've been following it.  I was going to get the patches built and uploaded shortly.
[07:04] <norsetto> keescook: ok, thanks. what do you think about sylpheed?
[07:06] <norsetto> keescook: I hope you don't mind to be referred to as the "security advisor" :-)
[07:07] <keescook> norsetto: ah, there has been a lot of discussion since I last looked
[07:08] <keescook> norsetto: I'm so confused.  What is adnarim saying is missing?
[07:09] <norsetto> keescook: he is complaining about sylpheed; I did not fix that becuase he cannot provide any reference to the needed code change
[07:09] <norsetto> keescook: I could fix the other two, the reference is clear. Mind you, it makes sense that that function call is wrong too.
[07:10] <keescook> ah, it seems like the issue is identical (i.e. the code is the same between both packages?)  I haven't looked at the cod yet.
[07:10] <keescook> what have other distributions fixed for their updates?
[07:10] <norsetto> almost sylpheed-claws, sylpheedclaws-gtk2 use the alertpanel_error_log function, sylpheed the alertpanel_error one
[07:11] <norsetto> keescook: indeed by looking at the changelog of other distros could help, but he hasn't done so, and I was busy doing the 8 patches....
[07:12] <keescook> norsetto: hehe, understood.
[07:12] <norsetto> keescook: I don't know if I will do another 8 patches in a row like this ;-)
[07:13] <norsetto> keescook: hope I didn't screw anything
[07:13] <keescook> norsetto: heh, yeah, it can be a lot of work!
[07:15] <keescook> norsetto: yeah, looks like sylpheed is buggy too, as adnarim says
[07:15] <norsetto> keescook: it seems reasonable to me as well
[07:16] <norsetto> keescook: but if you or somebody else ask for a reference , it cannot be provided (not now at least)
[07:16] <keescook> sure, it's the same reference.  (same code)
[07:17] <norsetto> keescook: well, it isn't, its "similar"
[07:19] <keescook> norsetto: for future security patches, also please include the CVE in the changelog (i.e. CVE-2007-2958)
[07:20] <norsetto> keescook: ok, will remember that
[07:22] <keescook> norsetto: ah, and please follow the security versioning.
[07:23] <keescook> e.g. 2.1.1-1ubuntu1 -> 2.1.1-1ubuntu1.1
[07:23] <norsetto> keescook: ok, I didn't know about that!
[07:23] <keescook> It's in the middle in https://wiki.ubuntu.com/SecurityUpdateProcedures
[07:23] <norsetto> keescook: should I resubmit the patches?
[07:23] <keescook> (step 4)
[07:24] <keescook> norsetto: that would be great, yeah.  you can add the CVE too.  :)  thanks!
[07:24] <norsetto> keescook: I'm quite sure its in there, but I got an headache in the middle of it :-)
[07:24] <keescook> norsetto: hehehe, understood.  :)
[07:25] <norsetto> keescook: any tip about the CVE? I actually tried to gather it, but I couldn't find a way to do it
[07:25] <keescook> norsetto: I'm not sure what you're asking.  The CVE for this issue is already linked (on the left) to the bug report (CVE-2007-2958(
[07:26] <keescook> norsetto: if you wanted to look for a CVE, you could start at http://cve.mitre.org/cve/cve.html
[07:26] <keescook> and that gets you to http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sylpheed  which confirms the CVE-2007-2958
[07:27] <norsetto> ok, got it now
[07:27] <stgraber> asac: good, I'm finally back at home. Do you have anything you want me to try to fix that wpa_supplicant issue ?
[07:28] <keescook> norsetto: thanks again for preparing all those patches!  I know it's a lot of work.
[07:28] <norsetto> keescook: thanks for the comments, if you have anything else please let me know?
[07:28] <keescook> sure, it looks good -- you're already using the built-in patching systems, so that's perfect.  :)
[07:29] <norsetto> keescook: yeah, that saved some work :-)
[07:30] <silwol> is this the right channel to get help in packaging best practices with bzr?
[07:30] <Hobbsee> er, #launchpad or #bzr is better, i suspect
[07:31] <silwol> okay, then i'll have a look there... thx Hobbsee
[07:38] <iwj> Oh, bugger, debian-changelog-mode made me upload -2 rather than -1ubuntu2.
[07:43] <Hobbsee> asac: is the updated ipw3945 driver in yet?  -10 seems to be there fo nm
[07:45] <seb128> StevenK: yes
[07:45] <seb128> StevenK: upload, if there is a breakage we can fix it
[07:56] <iwj> Uh, do uploads to LP missing `ubuntu' in the version number silently disappear or something ?
[07:58] <bryce> seb128: I have fixes to the BPX bugs you discovered yesterday
[08:03] <bryce> seb128:  The core problem we ran into was that issue with kde-guidance not allowing the 'disable' keyword.  I have a tiny patch to fix this issue:  http://people.ubuntu.com/~bryce/Uploads/ kde-guidance*.  Would you or Riddell be able to upload this fix?
[08:03] <calc> can someone bump stlport4.6 into main for me? :)
[08:04] <calc> it was already in main in the past but fell back into universe
[08:04] <bryce> I'm going to test the fixes for BPX and should have that upload ready in a little bit.
[08:05] <Riddell> bryce: I'll do it (so I can put the patch upstream too)
[08:05] <bryce> Riddell: excellent, thanks
[08:07] <calc> Riddell: ^ ? ;)
[08:07] <Riddell> calc: let me look
[08:07] <calc> Riddell: thanks :)
[08:08] <calc> stlport5.1 fell back into universe recently, and it didn't seem to work properly with OOo anyway, but 4.6 does
[08:08] <Riddell> calc: do you know why it was dropped?
[08:08] <calc> Riddell: i believe it was due to doko using 5.1 for OOo for a while but it had issues
[08:08] <bryce> Riddell: sebas says he's committed the fix upstream (lp #137683)
[08:08] <ubotu> Launchpad bug 137683 in kde-guidance "[PATCH]  xorgconfig.py crashes on "disable" in Modules section" [Undecided,New]  https://launchpad.net/bugs/137683
[08:08] <calc> i was using internal stlport in the meantime and stlport5.1 went back into universe recently
[08:08] <Riddell> bryce: oh, cool
[08:09] <calc> i think stlport 4.6/5.1 was only being used by OOo at least afaict
[08:10] <Riddell> calc: done
[08:10] <calc> Riddell: thanks! )
[08:10] <calc> :)
[08:10] <Riddell> will take the usual hour before the next publisher run
[08:10] <calc> yea
[08:11] <calc> it will be a while before my next upload i still have to verify that ooo-l10n-common isn't completely broken, which means a l10n build, heh
[08:11] <calc> that takes quite a few hours
[08:12] <doko> Riddell, calc: I'd rather use the internal copy now that OOo is the only user of 4.6 in main
[08:12] <calc> doko: oh ok
[08:12] <calc> doko: i can go back to using internal copy that is fine
[08:12] <doko> then we don't have to support 4.6 in main
[08:12] <calc> ok
[08:17] <Riddell> calc: shall I demote again?
[08:18] <calc> doko: would it be better to demote it or to have OOo use it instead of its local copy for security fixes, etc?
[08:18] <evand> It's too late to get a package into universe then main, correct?
[08:19] <calc> evand: depends on how important it is i think ;)
[08:19] <calc> evand: if you make a really good case you may be able to get it done
[08:19] <calc> evand: i got some stuff in that way just a week or so ago
[08:20] <evand> I don't think it's critical.  It's the usplash for gobuntu.
[08:20] <keescook> calc: odd, how did stlport5.1 end up back in universe?
[08:20] <keescook> if it compiles against 5.1, I think we should try to use it.  4.x is totally unsupport upstream.
[08:20] <calc> keescook: apparently only OOo used it and it didn't use it anymore due to issues with 5.1/OOo interaction
[08:21] <keescook> bleh
[08:21] <doko> calc: well, maybe, but I never did see an security update for stlport, and upstream plans to drop the use of stlport completely
[08:21] <calc> i can try to see if i can get it to work with 5.1 i don't recall what the old issues with 5.1 were
[08:21] <calc> doko: do you happen to know what the 5.1/OOo problems were?
[08:21] <keescook> doko: they've had security issues, but they're mostly impossible to exploit
[08:21] <calc> doko: oh if they are dropping using stlport altogether then i can just use internal copy in the meantime
[08:22] <calc> Riddell: yea demote it
[08:22] <calc> evand: new is frozen but there is exception process
[08:22] <evand> ok, I'll give it a shot.  Thanks calc
[08:24] <Riddell> down it goes
[08:24] <doko> calc: crashes =)
[08:25] <calc> doko: ok :)
[08:25] <calc> crashes are fun >;-)
[08:25] <calc> except when i get a lot of reports about it
[08:25] <calc> lol
[08:26] <calc> doko: btw the changelog/copyright missing files issue had existed since sometime in 2.2.1, got it fixed with the current build though
[08:27] <doko> nice
[08:27] <calc> it appeared to be caused by the ordering of installchangelogs/installdocs along with some if stmts, but i'm not really sure when it was broken due to not finding the full history of the rules file from back then
[08:28] <calc> its good now which is all that really matters
[08:30] <calc> asac: you still here?
[08:36] <geser> doko: re your mail to my libvte-java upload: the build fails with -I/usr/jvm/java-gcj-compat/include in CFLAGS: error: jni.h: No such file or directory
[08:37] <doko> geser: -I/usr/jvm/java-gcj/include
[08:38] <calc> doko: how is the icedtea debs coming along?
[08:39] <doko> not ready for upload
[08:39] <calc> ok
[08:42] <bddebian> Am I supposed to poke someone about an upload to feisty-proposed, or do you folks just see it?
[08:43] <jdong> they sense it...
[08:43] <jdong> with their whiskers of archivedom...
[08:43] <seb128> bddebian: we see it when we look at the queue but feel free to ping if you think there is an hurry
[08:44] <bddebian> No no hurry, but if anyone is bored I uploaded a rebuild of mod-cband to feisty-proposed.  Though I think I did it a little wrong because I filed the bug after I uploaded so there is no reference in the changelog :-(
[08:46] <bddebian> jdong: :-)
[08:47] <geser> doko: still the same with -I/usr/jvm/java-gcj/include, jni.h isn't found
[08:47] <bddebian> So fix it! ;-P
[08:47] <jdong> lol :)
[08:48] <doko> geser: $ ls /usr/lib/jvm/java-gcj/include/
[08:52] <tkamppeter> doko, I have corrected HPLIP now.
[08:53] <seb128> bddebian: upload accepted
[08:53] <bddebian> seb128: Oh, excellent, thanks
[08:53] <seb128> you're welcome
[08:54] <doko> tkamppeter: looking
[08:54] <geser> doko: ah, it's /usr/*lib*/jvm and not /usr/jvm as you told me twice
[08:54] <doko> geser: dlocate jni.h usually helps ;)
[08:58] <geser> doko: I used packages.u.c to find it in libgcj8-dev
[08:58] <geser> doko: it works now. Should I reupload the java package with set CFLAGS instead of CC?
[08:59] <doko> geser: not that important, keep it in mind for the next upload
[09:00] <geser> doko: ok, thanks for your help
[09:57] <seb128> evand: around?
[09:57] <evand> seb128: ja
[09:57] <seb128> evand: gobuntu-artwork-usplash usplash/usplash-theme-gobuntu.c is under GPL but the license text is not distributed in the tarball and that's not mentioned in the debian copyright
[09:58] <seb128> evand: could you fix that?
[09:58] <evand> seb128: whoops, sure thing
[09:58] <evand> thanks for looking at it in the first place
[09:58] <seb128> evand: xubuntu-artwork has the same bug, bonus point if you also fix this one ;)
[09:58] <evand> will do
[09:58] <seb128> thanks
[09:58] <seb128> I'm rejecting your upload for now
[09:59] <evand> still needs a version bump though, right?
[09:59] <seb128> no
[09:59] <evand> ok
[10:12] <evand> seb128: can I upload it to upload.u.c, or will it reject it because I'm not in core-dev?  Sorry if this has an obvious answer.
[10:12] <seb128> evand: are you a MOTU now?
[10:13] <evand> yes
[10:13] <seb128> evand: gobuntu-artwork-usplash has not been promoted yet so that's an universe package you can upload
[10:13] <asisak> evand: IIRC you can upload to universe and multiverse, main and restricted will get rejected.
[10:14] <evand> ah, I should've specified.  gobuntu I know is fine, but I'm assuming I'll have to upload xubuntu elsewhere for sponsorship, right?
[10:14] <seb128> correct
[10:14] <seb128> I'm happy to sponsor it for you
[10:14] <seb128> just copy it on people.ubuntu.com or somewhere else
[10:15] <evand> seb128: http://people.ubuntu.com/~evand/upload/xubuntu-artwork_0.18_source.changes
[10:15] <evand> thanks!
[10:15] <seb128> thank *you* for doing the work ;)
[10:17] <asac> calc: ?
[10:18] <mekius> hi, does the auto X configuration on the live cd only support loading drivers for nvidia/ati and all others just get vesa?
[10:19] <asisak> evand: Another obvious question: can anyone have people.ubuntu.com access?
[10:20] <evand> asisak: I believe you have to be a Canonical employee on the distro team or in MOTU or core-dev.
[10:20] <asisak> I mean MOTUs or ubuntu members
[10:21] <evand> MOTUs get access, afaik, but I'm pretty sure ubuntu members do not
[10:22] <evand> mekius: It loads the same driver that it would use on an installed system
[10:22] <calc> asac: sorry i forgot what i was going to ask you, if i remember i'll email you
[10:23] <mekius> evand: ok, i'm trying to do a custom live cd, PC has a via video card, yet the vesa driver is chosen, how can i make it recognize the card?
[10:24] <seb128> evand: can you mention before the next text that usplash/usplash-theme-gobuntu.c is the file under the GPL? The tarball also need to contain the GPL license text, you can copy /usr/share/common-licenses/GPL-2
[10:24] <evand> seb128: sorry, will do
[10:25] <evand> mekius: to be quite honest X is not my area of expertise.
[10:27] <Kopfgeldjaeger> gn8
[10:28] <mekius> evand: alright, wasn't sure if you knew somewhat how it handles that, do you know who would and when they are around?
[10:28] <evand> seb128: actually, I'm somewhat confused.  What do you mean by "before the next text", and doesn't copyright already contain the GPL v2 text?
[10:29] <ajmitch> asisak: no, only canonical people get access, MOTUs & other core-devs don't
[10:29] <seb128> evand: in the copyright, do something like that
[10:29] <evand> asisak: whoops, sorry for leading you astray there
[10:29] <seb128> "usplash/usplash-theme-gobuntu.c:
[10:29] <seb128> 
[10:29] <evand> ohh
[10:29] <seb128> This package is free software; you can redistribute it and/or modify
[10:29] <ajmitch> evand: it's ok, it was discussed at a TB meeting sometime last year :)
[10:30] <asisak> evand, ajmitch: thanks, I was asking because I did not now :)
[10:30] <seb128> evand:  and the 10 lines you copied != license text
[10:30] <evand> seb128: does ubuntu-artwork need to be modified then?  It doesn't do that.
[10:30] <asac> calc: i think it was about nm/ipw ?
[10:30] <evand> ok
[10:31] <seb128> evand: ubuntu-artwork has no .c under the GPL, does it?
[10:31] <dobey> hmm
[10:31] <dobey> hey seb128
[10:31] <seb128> ajmitch: hi
[10:31] <seb128> hi dobey
[10:31] <seb128> ajmitch: did you read what I wrote about f-spot yesterday?
[10:32] <ajmitch> seb128: yes
[10:32] <evand> seb128: ah, sorry, I was looking at the wrong package
[10:32] <seb128> ajmitch: do you plan to do an upload or should I do one with this patch?
[10:32] <ajmitch> seb128: yes I plan on doing an upload tonight (after work)
[10:32] <seb128> ajmitch: ok, cool, thanks ;)
[10:33] <evand> mekius: as I believe it's not a live cd issue, bryce would probably be the best person to answer questions as to which driver is used for which card and why.
[10:34] <seb128> lamont: what do you need?
[10:34] <lamont> I just figured it'd be a good thing to double check before I upload util-linux_2.13-3ubuntu1 to replaces the 2.13~rc3 version already in gutsy
[10:35] <lamont> it's only minor tweaks between them, etc, etc.  The intent was always to make it the non-RC version once it came out and had some time in debian to cook
[10:35] <lamont> -1 hit debian on aug 27
[10:38] <seb128> lamont: you want to ping Riddell or Hobbsee
[10:38] <lamont> Riddell/Hobbsee: what seb128 said
[10:38] <lamont> seb128: thanks
[10:38] <seb128> no problem
[10:39] <mekius> evand: alirght
[10:39] <mekius> evand: i agree that it isn't a live cd issue, just want to know how it is determining which video card, so i will ping him
[10:40] <mekius> bryce: ping
[10:42] <Riddell> lamont: yeah, go ahead, assuming it's only bugfixes, final release is better than a candidate
[10:43] <lamont> that was my thinking.  uploading
[10:46] <lamont> Riddell: most of the diff is po file updates
[10:46] <lamont> bug fixes and debian/rules cleanup to make my life sane
[10:46] <lamont> that last part being the reason I wanted to let it age in sid for a bit before I uploaded to ubuntu
[10:46] <Riddell> lamont: all sounds fine
[10:53] <lamont> thanks.  done.
[10:56] <evand> seb128: http://pastebin.ubuntu.com/51/ , better or does it really need to have the entire GPLv2 rather than just the reference to /usr/share/common-licenses/GPL in there?  I know the lines I copied are not the entire license, but I thought that block was the proper debian procedure, no?
[10:56] <seb128> evand: it needs the complete license text to be distribuable
[10:57] <evand> am I missing something obvious?  No other packages seem to take this approach.  Ubiquity, for example, has the exact same block.
[10:57] <seb128> hum
[10:59] <seb128> evand: ubiquity has a d-i/source/console-setup/GPL-2
[10:59] <seb128> evand: usually softwares have a COPYING and a COPYING.LIB
[11:00] <seb128> which has the license text
[11:00] <seb128> dunno why that's not the case for ubiquite, cjwatson should know ;)
[11:00] <evand> ah, indeed
[11:03] <evand> seb128: http://pastebin.ubuntu.com/52/ better? or should I just make a COPYING file?
[11:03] <seb128> a COPYING file would be nicer
[11:03] <evand> will do
[11:12] <Riddell> I don't require the whole licence for a native package, but it's still best to have one
[11:14] <evand> do I need to make a separate COPYING file for the artwork (licensed under CC SA), or is it suitable to put both licenses in the same COPYING file?
[11:14] <Luke> asac: sent it to your ubuntu account. I'll open a but report though. I just didn't know if this situation would be acceptable for that.
[11:15] <Riddell> evand: neater to have a separate one
[11:15] <Riddell> evand: and make it clear which files have which licence
[11:15] <evand> I figured as I saw that for DOCS, but is there a standard convention, something like COPYING-ART?
[11:16] <Riddell> evand: no, but that seems a good suggestion
[11:16] <evand> fair enough, thanks
[11:32] <cjwatson> iwj: e2fsprogs? all your uploads (including -2) got rejected due to "No copyright file found." which means that debian/copyright doesn't exist, which LP recently started enforcing (mistakenly in my view)
[11:33] <cjwatson> iwj: so you can safely go back to the -1ubuntu* versioning scheme
[11:33] <cjwatson> iwj: but I see you already did so :-)
[11:44] <xerakko> hi cjwatson
[11:51] <evand> Can I have an extra pair of eyes on http://people.ubuntu.com/~evand/upload/gobuntu-artwork-usplash_0.1_source.changes before I upload it, particularly the license text and whether I finally got it right :)?
[11:54] <mekius> hey, i'm doing the oem install and it makes you put in a password for the defautl user, how is a user who receives a computer with this oem account on it suppose to know how to login to make their account?
[11:55] <cjwatson> mekius: the password is only for the oem customisation user
[11:55] <cjwatson> mekius: after it's shipped to the end user, the end user will enter their own password
[11:55] <mekius> how do they do this?
[11:56] <cjwatson> mekius: the computer is not supposed to be shipped with the oem account still fully active
[11:56] <mekius> ok
[11:56] <cjwatson> mekius: per the instructions in the installer, you're meant to run 'oem-config-prepare', shut down, and then duplicate and ship
[11:56] <mekius> ah ok
[11:56] <mekius> sry :)
[11:56] <cjwatson> that causes oem-config to pop up next boot
[11:56] <mekius> ah ok, that is good, this makes sense now :)
[11:57] <cjwatson> gutsy should be clearer, there'll be an icon on the desktop to run oem-config-prepare
[11:57] <mekius> yep
[11:57] <mekius> we are basing our cd on gutsy
[11:57] <cjwatson> ah good
[11:57] <mekius> well dvd heh, it's a bit too big to do a cd :)
[11:58] <cjwatson> I just fiddled with oem-config today to actually make it use the right theme, only two years later ;-)
[11:58] <mekius> now we replaced gnome with enlightenment, will it still boot up and run oem-config?
[11:58] <mekius> or is it gnome specific?
[11:58] <cjwatson> err
[11:58] <cjwatson> I have no idea offhand
[11:58] <mekius> ok, i will give it a shot :)
[11:58] <cjwatson> oem-config's first-boot mechanism relies on metacity being present
[11:59] <wasabi> damn. i really should see about spending this evening to fix mdadm/lvm2
[11:59] <wasabi> what a pita.
[11:59] <cjwatson> if you've removed that it probably won't work right now - also gnome-settings-daemon as of today, to make the theme work
[11:59] <mekius> so when i restart after installing oem style, i just run the oem-config-prepare and probably answer some questions and on reboot it should give them something to create an account and such with?
[11:59] <cjwatson> oem-config-prepare is noninteractive
[11:59] <mekius> cjwatson: hmm, i see...
[11:59] <mekius> cjwatson: any way you can think to hack around that limitation?
[11:59] <mekius> it require gnome-settings-daemon?  doesn't respect a .gtkrc-2.0 in the users dir?
[11:59] <cjwatson> sure, file a bug and tell me how I can go about starting up the enlightenment window manager by hand
[12:00] <wasabi> Advice from udev pro's:   Currently during the initramfs boot, udev is used to activate MD volumes and also LVM volumes. Any suggestions on a design to alter teh way in which udev activates degraded volumes after a certain timeout?
[12:00] <cjwatson> oem-config has its own tiny display manager that starts up the stuff it needs
[12:00] <mekius> does it check for metacity and not run if it isn't running
[12:00] <mekius> ?
[12:00] <cjwatson> it runs some hardcoded programs
[12:00] <mekius> ah ok
[12:00] <mekius> i see
[12:00] <cjwatson> I can make it try something else too, if I know what to trry
[12:00] <cjwatson> try
[12:00] <mekius> is it a binary, or a script?
[12:01] <cjwatson> it's a python script, /usr/sbin/oem-config-dm
[12:01] <wasabi> Who is the best person to talk to about the structure of initramfs' local-init/top/bottom?
[12:01] <mekius> ok, so i could just modify it myself eh?
[12:01] <cjwatson> mekius: yes
[12:01] <mekius> ok, will give that a shot, thx for all the info :)
[12:01] <mekius> you've been a big help
[12:01] <cjwatson> I'm happy to integrate changes you send me to that
[12:01] <mekius> yeah, will do :)
[12:02] <mekius> you hang out here often, i can just ping you when i have something working?
[12:08] <cjwatson> mekius: sure, or just file a bug on https://bugs.launchpad.net/ubuntu/+source/oem-config/+filebug, which will ensure I don't lose it
[12:08] <mekius> ok :)
[12:09] <paran> how is updates of new changelogs to http://changelogs.ubuntu.com handeled?
[12:09] <paran> I it very often out of sync with the apt-archives which is quite annoying.
[12:09] <mekius> cjwatson: is this just a gtk program then?
[12:10] <mekius> ah i see :)
[12:13] <mekius> cjwatson: i will submit a patch if we create our own version of this program, but until then i'm just gonna hack it
[12:13] <cjwatson> mekius: no worries
[12:14] <mekius> cjwatson: also, the oem-config desktop icon that is there after the initial install only shows in GNOME;XFCE; is this file easily editable or is it part of the oem-config package?
[12:14] <cjwatson> it's copied to the desktop
[12:14] <mekius> cjwatson: where is it stored?
[12:16] <cjwatson> /home/oem/Desktop/ somewhere
[12:17] <mekius> alright, night :)
[12:22] <mekius> gah, it deletes the configuration stuff setup on the live cd :/
[12:29] <kevev> hello
[12:30] <kevev> is this the place to ask for support on Gutsy Gibon?