[06:32] <StevenK> infinity: Is it just me, or does artigas currently hate life?
[06:42] <untung> hello, how can i create my own ubuntu live cd distro?
[06:42] <untung> i want to put the softwares and drivers to be loaded for my laptop
[06:43] <LaserJock> untung: you probably want Reconstructor or Ubuntu Customization Kit
[06:44] <mikmor2> I don't think either of those handle adding drivers, etc very well
[06:49] <LaserJock> they can't? as long as they are in the repos it should be easy I'd think
[06:50] <untung> laserjock: where can i download the software
[06:50] <LaserJock> untung: google it, I'm not sure exactly
[06:54] <lifeless> mikmor2: its just a new kernel, or a modular driver package
[06:55] <untung> laserjock: i found the link http://uck.sourceforge.net/
[06:55] <mikmor2> yeah, UCK is probably your best bet then
[07:13] <pitti> Good morning
[07:14] <Fujitsu> Hi pitti.
[07:14] <LaserJock> hi pitti
[07:14] <StevenK> Morning pitti.
[07:15] <StevenK> pitti: I have a bunch of NBS stuff to do, do you have a sec? :-)
[07:15] <pitti> StevenK: sure
[07:16] <StevenK> pitti: Firstly, libklash0, libgnash0, libxfontcache1-dbg and libgcj8-0-awt can all be NBS'd out.
[07:17] <StevenK> pitti: Secondly, are you able to rescue libquicktime and mpfr from binary NEW?
[07:19] <StevenK> pitti: Of the ten rdepends of libquicktime0, I have got nine uploads just about prepared, and wanted to talk to you about the ten.
[07:19] <StevenK> s/ten./tenth./
[07:22] <mhb> hi pitti
[07:22] <pitti> hi mhb
[07:23] <pitti> StevenK: libgcj8-0-awt doesn't exist; I NBSed all the rest
[07:23] <StevenK> Interesting, since libgcj8-0-awt appears in the NBS list.
[07:24] <pitti> only libgcj8-0 here
[07:25] <StevenK> Curious. I shall sort out libgcj8-0 later today.
[07:26] <pitti> StevenK: quicktime NEWed, mpfr is already
[07:26] <StevenK> Neat, thanks.
[07:27] <pitti> StevenK: you can upload right now with the right build deps, too
[07:27] <pitti> StevenK: so what about the mysterious 10th package?
[07:28] <StevenK> pitti: Okay, so the last thing (for the moment, anyway :-) is the tenth package listed as depending on libquicktime0 - which is xmovie. It fails to build from source, as does the newest upstream version, it doesn't appear in popcon, and looks like we have about three better alternatives.
[07:29] <StevenK> pitti: Better, the package (and it's bug reports) have not been touched in Debian for the better part of 15 months.
[07:29] <StevenK> pitti: Are you against killing and blacklisting it?
[07:31] <pitti> StevenK: I'm not, no
[07:31] <pitti> StevenK: please file a removal bug with that reasoning (so that we have a record)
[07:31] <StevenK> pitti: I was just about to ask that. :-)
[07:31] <pitti> hm, apt-cache search doesn't have any results for xmovie
[07:31] <pitti> aah
[07:31] <pitti> i386 only
[07:32] <StevenK> Yup.
[07:36] <StevenK> pitti: Done. Bug 130582
[07:36] <ubotu> Launchpad bug 130582 in xmovie "Please remove xmovie" [Undecided,Confirmed]  https://launchpad.net/bugs/130582
[07:39] <pitti> StevenK: removed
[07:40] <wolfe> pitti: I'm reading the homepage for the software, they're using Fedora 5.0 and even 64bit
[07:41] <StevenK> pitti: Thanks!
[07:42] <StevenK> wolfe: Yes, and the upstream does this by including his own versions of quicktime4linux, libmpeg3 and libsoundfile.
[07:42] <StevenK> His rationale is "distributions libraries change too quickly", which is complete crack.
[07:42] <wolfe> StevenK: just statically compile?
[07:43] <wolfe> I mean, I don't see a problem with the software if it works
[07:43] <RAOF> What if the version of the libraries he ships have bugs, or security vulns?
[07:43] <wolfe> StevenK: well, I've been bitten in the past by distributions which want to use different versions of certain libraries, so it is not complete crack
[07:44] <wolfe> RAOF: like there isn't software which already ships with exploits?
[07:44] <Fujitsu> wolfe: It's a lot easier to maintain one copy of all these crazy codecs than a thousand.
[07:44] <RAOF> wolfe: No, but static linking makes it more difficult to fix.
[07:44] <wolfe> RAOF: not really, see osx ;)
[07:45] <StevenK> I wouldn't use OS X as an example of stuff done right.
[07:45] <RAOF> wolfe: IE: you just rebuild the lib *once*, rather than hunting down each package that includes it's own copy, munging it, and rebuilding.
[07:45] <Burgundavia> especially on a package management side
[07:45] <wolfe> StevenK: all I'm saying is it works.l
[07:46] <wolfe> RAOF: right, complete opinion of the community, the old static vs dynamic argument
[07:46] <wolfe> both are fine
[07:46] <Burgundavia> wolfe: usability must, by its very nature, include the idea of good security
[07:46] <Burgundavia> if you have bad security, you have bad usability
[07:46] <RAOF> wolfe: Indeed.  But when you have package management as good as apt, the advantages of static linking are hugely outweighed by the disads
[07:46] <wolfe> Burgundavia: okay, let me just install a pacakge which other programs depend on which is exploitable, now you've several exploitable programs instead of just 1
[07:47] <wolfe> I could do this all day, and nobody really wins
[07:47] <wolfe> the point is, static vs dynamic is pure opinion
[07:47] <RAOF> No, it isn't.
[07:47] <wolfe> yes, it is.
[07:47] <pitti> wolfe: no, it's not pure opinion, it's a question of maintenance costs
[07:47] <Fujitsu> If we were to link everything statically... well, I don't like to think about it.
[07:47] <wolfe> the whole "its insecure" argument depends on the maintainers
[07:47] <pitti> wolfe: if we had arbitrary amounts of maintenance power, it wouldn't be a problem, but we haven't
[07:48] <wolfe> pitti: right, which I'm not disputing.
[07:48] <pitti> wolfe: the nastiest thing about static linking is that there is *no* automated way to check which packages are affected by a bug
[07:48] <wolfe> we're disputing "static linking is not secure" which is complete opinoin
[07:48] <RAOF> In *practice* static linking is less secure?
[07:48] <wolfe> pitti: well if the package manager was built better to autocheck what was static cally compiled to begin with ;)
[07:49] <pitti> wolfe: right, it should be 'static linking is unmaintainable and can lead to covert security holes'
[07:49] <wolfe> I'm curious
[07:49] <pitti> wolfe: as I said, there are no tools which tell you which libraries have been statically linked to a program; package managers don't help there
[07:50] <pitti> wolfe: and here this just seems to be an excuse from upstream maintainers not keeping up with libraries; there's no inherent reason not to use the standard system libraries
[07:51] <wolfe> pitti: ahuh...
[07:51] <pitti> wolfe: as opposed to, say syslinux or grub which need to statically link libc parts
[07:51] <wolfe> pitti: so what are your thoughts when mplayer damned the debian project? :)
[07:51] <Fujitsu> With ffmpeg?
[07:51] <wolfe> Fujitsu: yeah, I think that was it. was years ago, but I remember it very clearly.
[07:51] <RAOF> ffmpeg being something of an oddity
[07:51] <Burgundavia> the ffmpeg developers need some education
[07:52] <RAOF> In that they are vehrmently opposed to releasing software.
[07:52] <Fujitsu> ffmpeg and mplayer upstream are the same, and its interfaces change quickly, AFAIK.
[07:52] <wolfe> pft
[07:52] <pitti> wolfe: right, xine-lib and mplayer ar the prime examples of evil static linking (I understand that because of ffmpeg upstream's unwillingness to provide a stable ABI)
[07:52] <wolfe> ABIs change, software changes..
[07:52] <pitti> right
[07:52] <wolfe> its up to OSes/distros to provide updated packages
[07:53] <wolfe> upstream only writes the software after all
[07:53] <pitti> but something like a video driver ABI should not change every week
[07:53] <Burgundavia> in the ffmpeg case, it is becasuse the developers refuse to even consider providing a stable api/abi
[07:53] <RAOF> But people worknig on a *library* should actually *release* the library.  At some point.
[07:53] <pitti> wolfe: gstreamer manages to provide a reasonably static ABI, too, so it's not impossible (in Windows this is common standard for ages already)
[07:54] <wolfe> huh, you guys don't have the Io programming language in packages :)
[07:54] <wolfe> Steve refuses to use dynamic linking, he is a osx guy
[07:57] <pitti> cjwatson: any idea why amd64/i386 livefs builds aren't even attempted today?
[07:57] <pitti> cjwatson: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/gutsy/ubuntu/20070806/
[07:57] <ajmitch> RAOF: don't let your prejudices get in the way of reality
[07:58] <ajmitch> RAOF: sometimes us users aren't worthy of having an actual release
[07:58] <wolfe> heh
[07:58] <wolfe> oh please, releases are so passe ;)
[07:59] <Fujitsu> 1.0rc1 was released 9 months ago.
[07:59] <RAOF> ajmitch: True.  Development would be stalled far too long if you couldn't break ABI/API at will.
[07:59] <wolfe> I use -HEAD on most of my libraries I use and media
[07:59] <Fujitsu> Enormous changes have occured in the codebase since.
[08:12] <pitti> ArneGoetje: are you aware of any fonts in ubuntu-desktop we could drop? we need to make some space on the CDs
[08:14] <LaserJock> pitti: how much space?
[08:14] <pitti> LaserJock: about 5 MB on amd64
[08:14] <Amaranth> RAOF: i would think after, say, a year you would be able to figure out a solid ABI/API that you wouldn't be limited by
[08:14] <pitti> LaserJock: probably some more, because seb128 wants to add tracker and consolekit today
[08:14] <StevenK> pitti: I am amused that both libgcj7-0 and libgcj8-0 appear on the NBS list.
[08:15] <LaserJock> pitti: heh, ogra can give you hints about skimming off .isos ;-)
[08:16] <LaserJock> poor guy was constantly oversized
[08:16] <Amaranth> s/was/is/
[08:16] <LaserJock> and yet he stays so skinny ;-)
[08:16] <pitti> heh
[08:18] <pitti> a-haa
[08:19] <pitti> ArneGoetje: ok, unping for now :)
[08:25] <RAOF> Amaranth: No, why on earth would you think that.  Alternative answers include: "That would require someone to *design* an API, rather than let one congeal" and "But that would prevent us from potentially increasing decode speed by 1.2% in this uncommon case!"
[08:27] <Amaranth> RAOF: I find it hard to believe they keep making the same API mistakes wrt decode speed after years of working on this stuff
[08:28] <Amaranth> It's like every new codec they add they repeat the same mistakes
[08:29] <RAOF> Amaranth: Yes, of course.  Opaque data structures are for people who don't know how many cycles a 32bit add + bitshift twice right operation takes on each major arch from the last 10 years.
[08:30] <RAOF> Amaranth: Every 6 months or so someone who actually wants to *use* the libraries will suggest that they do a release... with hilarious consequences!
[08:31] <Amaranth> RAOF: I've seen
[08:31] <RAOF> It would be so useful to get a release.  And I suppose Debian has, really.
[08:55] <pitti> Riddell: I gave bug 117731 to you, since that's marked as tribe-4
[08:55] <ubotu> Launchpad bug 117731 in python-kde3 "Python crashes after attaching pty to a konsole kpart" [High,Triaged]  https://launchpad.net/bugs/117731
[09:00] <pitti> TheMuso: here by chance?
[09:00] <pitti> TheMuso: in bug 122024, cjwatson talks about a 'partial fix merged into mainline'; what is the status of this?
[09:00] <ubotu> Launchpad bug 122024 in casper "orca should automatically get started when braille is activated" [Medium,In progress]  https://launchpad.net/bugs/122024
[09:02] <carlos> pitti: did you get Dapper's base update?
[09:02] <pitti> carlos: I got it, yes; packages should be built now, I'll test them soon
[09:02] <carlos> pitti: which one? (so I prepare the right incremental updates)
[09:03] <pitti> ~carlos/public_html/language-packs/dapper/rosetta-dapper-2007-08-03.tar.gz
[09:03] <pitti> carlos: timestamp matches, 20070803
[09:03] <pitti> good morning mvo
[09:05] <mvo> hey pitti
[09:08] <carlos> pitti: ok, thanks
[09:08] <carlos> mvo: morning
[09:09] <carlos> mvo: Are you updating DDTP in our archives?
[09:09] <carlos> mvo: we get many emails asking about it on ubuntu-translators and other per locale mailing lists
[09:09] <pitti> mvo: bug 122459 is fixcommitted, will you upload this soon?
[09:09] <ubotu> Launchpad bug 122459 in compiz "[gutsy]  cannot log in on edubuntu DesktopCD" [Undecided,Fix committed]  https://launchpad.net/bugs/122459
[09:10] <pitti> mvo: do you have an idea about bug 107109 yet?
[09:10] <ubotu> Launchpad bug 107109 in compiz "No "New Login" for user with Desktop effects enabled" [High,Triaged]  https://launchpad.net/bugs/107109
[09:10] <pitti> mvo: ^ I guess that is because there can only be one X server with composite at a time?
[09:13] <carlos> pitti: did you check whether it has now all files?
[09:13] <pitti> carlos: not yet
[09:14] <carlos> ok
[09:15] <carlos> pitti: French translation for alacarte is there so I guess the others should be there too
[09:16] <Amaranth> pitti: only one server with GL at a time
[09:16] <pitti> Amaranth: right
[09:16] <Amaranth> pitti: and I still have no idea how to fix that bug
[09:17] <pitti> Amaranth: so, can this be detected cleanly? or shall we work around it by only enabling compiz on :0?
[09:17] <mvo> carlos: I was kind of hoping that the new process we dicsueed gets into place, but I can do a upload now
[09:17] <Burgundavia> Amaranth: crack idea: is it possible to change the server that is currently doing GL?
[09:17] <Amaranth> Burgundavia: No
[09:18] <Amaranth> Burgundavia: That's determined at server start
[09:18] <mvo> pitti: I check out the bugs now. the one with fix comited was one I wanted to upload together with a new compiz snapshot, but I had issues last week while testing so I postponed it
[09:18] <carlos> mvo: even having the new process implemented in this cycle, it will not be deployed until end of the month
[09:18] <Amaranth> mvo: compiz 0.5.2 is out
[09:21] <mvo> carlos: ok
[09:21] <mvo> Amaranth: yeah!
[09:21] <Amaranth> mvo: need to push hard for a compiz-fusion release now too :)
[09:22] <mvo> Amaranth: indeed :)
[09:23] <pitti> doko_: any idea about 130428? I hope it doesn't require a soname bump?
[09:25] <ion_> I hope some player gets support for the compiz video plugin before gutsy gets frozen.
[09:25] <StevenK> ... except for sparc.
[09:26] <Amaranth> ion_: Not looking likely
[09:26] <Amaranth> ion_: Unless you'd like to volunteer?
[09:26] <Amaranth> At this point it'd be easier to just use Xgl
[09:27] <carlos> mvo: thanks
[09:28] <pitti> Riddell: another tribe4 bug for you: bug 124068
[09:28] <ubotu> Launchpad bug 124068 in kdepim "Akregator and Kontact File conflict" [Undecided,Incomplete]  https://launchpad.net/bugs/124068
[09:29] <pitti> Riddell: congratulations :)
[09:32] <RAOF> Amaranth: I really should look into a Gstreamer compiz-video output.  It shouldn't be *too* hard!
[09:43] <StevenK> Yay. Eight of my nine uploads have built everywhere but sparc.
[09:43] <cjwatson4> pitti: for amd64, you got up too early - you asked before the cron job fired
[09:44] <cjwatson> pitti: i386 is stuck for some other reason, though
[09:44] <doko_> pitti: looking
[09:45] <pitti> cjwatson: but there are no images for yesterday either
[09:46] <pitti> cjwatson: amd64 live today> I wonder what those 'Error in select()' is all about; is this apt?
[09:47] <pitti> oh, dpkg
[09:49] <ArneGoetje> pitti: not yet... I'm still examining the default font packages
[09:49] <pitti> seb128: deb http://people.ubuntu.com/~pitti/tmp/dapper-langpack/ ./   -> new dapper langpacks for testing; they should be complete now
[09:49] <seb128> pitti: ok, will give them a try
[09:50] <seb128> pitti: I commited the seeds changed for consolekit, fast-user-switch-applet and tracker
[09:50] <pitti> seb128: oh, good
[09:50] <pitti> I was just about to ask you when I can update *-meta
[09:50] <mvo> pitti: yes, that is apt
[09:50] <mvo> pitti: where have you seen this?
[09:50] <cjwatson> pitti: wow, no idea
[09:51] <cjwatson> mvo: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/gutsy/ubuntu/20070806/livecd-20070806-amd64.out
[09:51] <pitti> efs-build-logs/gutsy/ubuntu/20070806/livecd-20070806-amd64.out
[09:51] <pitti> oops
[09:51] <asac> stgraber: yt?
[09:51] <mvo> geeeh
[09:51] <seb128> pitti: I did merge with kubuntu, etc though because I'm not sure if the language pack changes apply to the other distros also
[09:52] <seb128> s/did/didn't
[09:52] <mvo> pitti, cjwatson: I check this out, also it should not make the thing fail
[09:52] <pitti> seb128: langpack changes don't
[09:52] <stgraber> asac: yep
[09:53] <asac> stgraber: cool
[09:53] <asac> stgraber: well ... i see these wpasupplicant issues even with last tribe nm
[09:54] <asac> stgraber: e.g. the failure to connect to wpasupplicant
[09:54] <asac> stgraber: are you sure that this doesn't happen for you with current gutsy versions?
[09:55] <stgraber> asac: Let me reinstall gutsy NM (I previously used a Live CD for testing) and I give you the result in a minute
[09:56] <asac> stgraber: point is that you might not see that message becase wpasupplicant is not started verbose in current gutsy version
[09:56] <asac> stgraber: but i definitly see that i cannot send commands to wpasupplicant
[09:56] <asac> on every second run
[09:57] <asac> stgraber: thanks
[09:58] <pitti> cjwatson: I do a test install of alternate/amd64 (without network); it asks me about a mirror now and (naturally) fails to connect to it; that didn't happen in the past
[10:02] <stgraber> asac: ok, indeed I don't see the supplicant error message but the disconection seems to happen anyway
[10:02] <stgraber> asac: I just had NM to switch from connecting to disconnected without any real reason
[10:02] <mikmor2> cjwatson: Hello
[10:02] <asac> stgraber: he?
[10:03] <asac> stgraber: i see this issue when i try to connect ... not when i am already connected
[10:03] <asac> stgraber: e.g. every second connect wpa supplicant fails to start
[10:03] <stgraber> NM was trying to connect to my wifi network, then suddenly switched to disconnected
[10:04] <asac> ah ok
[10:04] <asac> that might be the issue
[10:04] <asac> ok
[10:04] <asac> now it would be interesting to see if wpasupplicant 0.5.8 is better
[10:04] <asac> but i will try that for now :)
[10:04] <asac> will let you know if i see improvements
[10:06] <stgraber> my current NM doesn't seem to have this issue as I have added a sleep(2) right after the disconnect from the network (the ipw3945 hack) (I've put that here so I didn't have to write another patch :))
[10:06] <cjwatson> pitti: I don't think anything's changed there ...
[10:06] <cjwatson> mikmor2: hi
[10:06] <stgraber> but adding sleep() everywhere is not really a good idea imo :)
[10:06] <asac> stgraber: where exactly? i tried multiple places for that sleep
[10:06] <cjwatson> pitti: if it's *asking*, sounds like the CD's screwed
[10:07] <cjwatson> pitti: it shouldn't ask if /cdrom/.disk/base_installable exists
[10:07] <asac> stgraber: can you make a bzr diff or something and paste?
[10:07] <cjwatson> oh
[10:07] <mikmor2> cjwatson: Do you mind if I PM you?
[10:08] <stgraber> asac: 41d just before the nm_dev_sock_close(sk);
[10:08] <cjwatson> mikmor2: not at all
[10:08] <cjwatson> pitti: let me get IS to install debootstrap on antimony ...
[10:08] <stgraber> asac: but I think it could be better placed :)
[10:08] <pitti> cjwatson: base_components exists, but not base_installable
[10:08] <cjwatson> pitti: yeah, it's 'cos debootstrap isn't installed
[10:09] <pitti> ah
[10:09] <mikmor2> hmm.. for some reason messaging isn't working
[10:09] <pitti> cjwatson: is it worth filing a bug about that still?
[10:09] <asac> stgraber: before sock_close ... interesting
[10:09] <cjwatson> pitti: no
[10:10] <asac> stgraber: can you try if *after* sock close helps as well?
[10:10] <cjwatson> pitti: I've filed an RT request
[10:10] <pitti> thanks
[10:12] <pitti> wow, the "broken X" text dialog boxes don't have a hideously broken frame any more
[10:12] <stgraber> asac: building the deb
[10:13] <asac> stgraber: thx
[10:15] <seb128> pitti: weird
[10:16] <seb128> pitti: bryce sent me a gdm patch for that but I didn't upload it yet
[10:16] <pitti> seb128: for what?
[10:17] <seb128> pitti: " wow, the "broken X" text dialog boxes don't have a hideously broken frame any more"
[10:17] <pitti> seb128: ah; maybe the latest xorg merge?
[10:17] <pitti> seb128: the live fs is from Aug 04 (it failed to build later)
[10:17] <pitti> seb128: so it still has the broken dexconf, so I could see it :)
[10:17] <seb128> well, I've a gdm patch to apply, dunno what to do with it now :p
[10:18] <pitti> seb128: can you test it locally without your patch? just damage xorg.conf somewhat and restart gdm?
[10:18] <pitti> well, I can do it, too, if you want me to
[10:19] <pitti> I just saw it on the live system
[10:19] <seb128> pitti: yes, will do in a bit, I don't want to close my desktop session now
[10:19] <pitti> right, here too (test install running)
[10:19] <stgraber> asac: Seems to be working as well (I tried to connect 3-4 times from a network to another and was unable to make it disconnects)
[10:21] <asac> hmm
[10:22] <pitti> seb128: hm, not sure whether tracker and f-u-s-a make sense for edubuntu... ogra?
[10:23] <seb128> pitti: I would say they are not required no
[10:24] <pitti> seb128: ok, droping those changes on the edubuntu merge
[10:29] <pitti> seb128: just tried the "failed X" case in a fresh gutsy desktop CD install; looks fine
[10:30] <pitti> ok, all seeds merged
[10:30] <seb128> ok
[10:30] <seb128> I'll ask bryce about the patch then
[10:33] <pitti> RuntimeError: Command failed with exit status 768:
[10:33] <pitti>   'bzr checkout /home/jr/src/seeds/edubuntu-kde-meta/edubuntu.gutsy/ /tmp/germinate-jHthiF/checkout'
[10:33] <pitti> Riddell: ... :)
[10:37] <slomo> hi pitti :)
[10:39] <ogra> pitti, f-u-s-a ?
[10:39] <ogra> morning
[10:39] <pitti> ogra: fast-user-switch-applet
[10:39] <pitti> hey ogra, good morning
[10:39] <ogra> ah
[10:39] <pitti> ogra: I didn't add it to your seeds for now (neither tracker, I guess that'd kill your poor thin clients)
[10:40] <ogra> pitti, i was planning to fix the udeb today, but some other breakage showed up, i have to fis that first
[10:40] <pitti> ogra: ok for me to upload an up to date edubuntu-meta? changes look reasonable
[10:40] <ogra> looks somewhat like an apt breakage
[10:40] <ogra> sure
[10:40] <ogra> Vorkonfiguration der Pakete ...
[10:40] <ogra> openpty failed
[10:40] <ogra> Error in select()
[10:40] <ogra>                  Whle vormals abgewhltes Paket x11-common.
[10:41] <pitti> ogra: right, we saw that already on live cd build
[10:41] <pitti> ogra: mvo is taking a look
[10:41] <ogra> thats what i see ... with a new chroot it shows up in a different place
[10:41] <ogra> ah, k
[10:45] <mvo> ogra: does it break anything? or just pollute the world with this message
[10:45] <pitti> mvo: eventually dpkg bails out on the amd64 live fs log
[10:45] <ogra> mvo, it breaks my thin client builds
[10:46] <mvo> pitti, ogra: have you seen it on your regular systems as well? or only when livefs building?
[10:46] <pitti> mvo: I never saw it here, but I did my last few upgrades with u-m
[10:46] <pitti> a mere apt-get install <some packages> works fine here
[10:46] <ogra> mvo,only when thin client building
[10:47] <ogra> mvo, (chroot install)
[10:47] <ogra> http://paste.ubuntu-nl.org/32735/
[10:47] <ogra> thats the end of a ltsp build process atm
[10:47] <ogra> (sorry, localized)
[10:49] <mvo> ogra: cool, what command do I have to run to trigger it?
[10:49] <pitti> mvo: hmm, a simple gutsy debootstrap works fine here
[10:49] <pitti> mvo: that's in a gutsy chroot on ronne, though
[10:50] <ogra> mvo, ltsp-buil-client ... but thats after about 20min .... after the chroot built, and the script chrooted into it to install the client stuff
[10:50] <ogra> *ltsp-build-client
[10:50] <mvo> pitti: if I can reproduce with ogras commands, I will be happy
[10:50] <ogra> we divert start-stop-daemon ... i guess thats something the livefs scripts do as well ...
[10:51] <mvo> ogra: can you pinpoint what command is run when it fails? or it it the same apt-get run that worked earlier?
[10:51] <mvo> pitti: I wonder if it might have something todo with the amount of packages being installed? assuming a livefs build is big?
[10:51] <ogra> it worked last on aug 2nd for me ...
[10:52] <ogra> i can disg up the command, wait a min
[10:52] <pitti> mvo: hm, right
[10:52] <mvo> ogra: I merged new code that generates log files from the dpkg runs for better apport integration, I know what code is causing the issue, I just do not know why :) or how to reproduce it
[10:52] <pitti> mvo: the actual debootstrap part in the livefs build log is fine
[10:52] <cjwatson> ogra: debootstrap doesn't actually divert it, but it does move it aside
[10:52] <mvo> ha! fdleak or something, I bet
[10:53] <mvo> or on /dev/pts in the chroot?
[10:53] <pitti> mvo: that's the first thing where it breaks:
[10:53] <cjwatson> livecd.sh diverts invoke-rc.d
[10:53] <pitti> Preconfiguring packages ...
[10:53] <pitti> FATAL: Could not load /lib/modules/2.6.15.7/modules.dep: No such file or directory
[10:53] <pitti> Fetched 575MB in 1m5s (8769kB/s)
[10:53] <pitti> openpty failed
[10:53] <pitti> Error in select()
[10:53] <pitti> Selecting previously deselected package diveintopython.
[10:53] <pitti> (Reading database ... 10152 files and directories currently installed.)
[10:53] <pitti> Unpacking diveintopython (from .../diveintopython_5.4-2ubuntu2_all.deb) ...
[10:53] <pitti> Error in select()
[10:53] <ogra> cjwatson, ltsp-build-client diverts it
[10:53] <cjwatson> pitti: debootstrap doesn't use apt, so if it's an apt problem then debootstrap won't trigger it
[10:53] <ogra> mvo, chroot $ROOT apt-get $APT_GET_OPTS install $LATE_PACKAGES
[10:54] <mvo> openpty() is the bummer here
[10:54] <pitti> cjwatson: oh, I thought it would use it for stage 2?
[10:54] <ogra> mvo, export APT_GET_OPTS="$APT_GET_OPTS -o Acquire::gpgv::Options::=--ignore-time-conflict"
[10:54] <mvo> ogra: do you have /dev/pts in your chroot?
[10:54] <cjwatson> pitti: no, it's already got the logic to do everything with dpkg for stage 1 so it might as well just use it for stage 2 as well
[10:54] <pitti> ah, I see
[10:54] <cjwatson> since, well, that's the easy bit
[10:55] <ogra> mvo, nope
[10:55] <mvo> ogra: if you still can reproduce it, could you pleae try to mount /dev/pts and see if that fixes the issue?
[10:56] <mvo> I will add code so that failing in openpty() will work gracefully, I just want to confirm that this is the actual problem
[10:56] <ogra> root@laptop:/# apt-get -f install
[10:56] <ogra> Paketlisten werden gelesen... Fertig
[10:56] <ogra> Abhngigkeitsbaum wird aufgebaut... Fertig
[10:56] <ogra> 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
[10:56] <ogra> 3 nicht vollstndig installiert oder entfernt.
[10:56] <ogra> Es mssen 0B Archive geholt werden.
[10:56] <ogra> Nach dem Auspacken werden 0B Plattenplatz zustzlich benutzt.
[10:56] <ogra> openpty failed
[10:56] <ogra> Error in select()
[10:56] <ogra>                  Error in select()
[10:56] <ogra>                                   Error in select()
[10:56] <ogra>                                                    E: Sub-process /usr/bin/dpkg returned an error code (1)
[10:56] <ogra> root@laptop:/#
[10:56] <ogra> still reproducable
[10:56] <mvo> ogra: that is with mounted /dev/pts?
[10:56] <mvo> aha
[10:56] <mvo> :)
[10:59] <ogra> root@laptop:/# mount -t proc proc /proc
[10:59] <ogra> root@laptop:/# /etc/init.d/mountdevsubfs.sh start
[10:59] <ogra> root@laptop:/# apt-get -f install
[10:59] <ogra> Paketlisten werden gelesen... Fertig
[10:59] <ogra> Abhngigkeitsbaum wird aufgebaut... Fertig
[10:59] <ogra> 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
[10:59] <ogra> root@laptop:/#
[10:59] <ogra> mvo, ^^^
[10:59] <mvo> ogra: so that works? good. I will fix the code now, thanks a lot for reproducing!
[10:59] <ogra> :)
[11:01] <asac> stgraber: do you see issues with connecting to unencrypted net as well?
[11:10] <stgraber> asac: yes, sometimes it simply can't :)
[11:10] <stgraber> asac: like trying to connect but never succeeds
[11:10] <stgraber> and there doesn't seem to have any kind of timeout
[11:10] <doko_> pitti: it does, but adding a compatibility function seems to work as well
[11:11] <pitti> doko: that would be great
[11:16] <asac> stgraber: so it even fails with iwconfig only?
[11:16] <coNP> May I ask some core-dev to review/sponsor my magyarispell (Hungarian spell checker) update (0.99 -> 1.2) at http://revu.tauware.de/details.py?upid=6332?
[11:16] <asac> stgraber: maybe the same workaround helps? e.g. explicitly unsetting essid first?
[11:18] <seb128> coNP: subscribe the ubuntu-main-sponsor team and wait for somebody to upload ;)
[11:18] <coNP> Sure, thanks :)
[11:25] <stgraber> asac: nope, iwconfig+dhclient3 works
[11:26] <stgraber> asac: looks like NM doesn't detect when it's correctly associated and then never runs dhclient ...
[11:29] <pitti> mhb: what is data/kcm-fix.patch all about?
[11:30] <pitti> mhb: applying this in setup.py is rather evil (unexpected in the first place, and not idempotent)
[11:31] <asac> stgraber: hmm
[11:31] <asac> stgraber: btw, what dbus version do you use?
[11:32] <pitti> mhb: oh, I see now; gosh, that's evil
[11:36] <stgraber> asac: 1.1.1-3ubuntu1
[11:36] <mhb> pitti: fixes in .py templates that cannot be done in designer
[11:39] <pitti> ImportError: No module named pyqtconfig
[11:39] <pitti> make: *** [python-build-stamp-2.5]  Fehler 1
[11:40] <pitti> mhb: ^ seems it's missing a build dep; /me tries python-qt4
[11:40] <pitti> mhb: not in python-qt4-dev either
[11:41] <mhb> ./python-qt3.list:/usr/lib/python2.5/site-packages/pyqtconfig.py
[11:42] <pitti> mhb: erk, why qt3?
[11:42] <pitti> mhb: thanks, adding that
[11:43] <mhb> pitti: lots of reasons, mainly because python-kde4 doesn't exist yet
[11:43] <geser> ./usr/lib/python2.5/site-packages/PyQt4/pyqtconfig.py is in python-qt4-dev
[11:44] <pitti> mhb: ah, that helped a bit; now it fails with
[11:44] <pitti> running build_kcm
[11:44] <pitti> Failed to find the PyKDE directory: /usr/lib/python2.5/site-packages
[11:44] <StevenK> Hrm. I think the sparc buildds currently hate life.
[11:45] <pitti> mhb: maybe you can try to build this in a pbuilder and do the necessary fixes?
[11:45] <mhb> pitti: I'm pretty sure python-kde3-dev was a buil-dep
[11:45] <Riddell> you'll need python-kde3-dev
[11:45] <pitti> I have that, it's a b-dep
[11:45] <Riddell> and pykdeextensions and libpythonize0-dev
[11:46] <pitti> I have both, too
[11:46] <StevenK> I take that back, it seems artigas currently hates life.
[11:47] <highvoltage> hey Burgundavia
[11:47] <pitti> mhb: also, could you make RestrictedManagerCommon.runme_as_root() abstract? (I. e. raise NotImplementedError, 'this method must be implemented by a concrete subclass')
[11:47] <Burgundavia> hey highvoltage
[11:48] <pitti> mhb: having it default to sudo is prone to provoke a program hang
[11:49] <infinity> StevenK: What's artigas doing?
[11:50] <pitti> mhb: and clean leaves some autogenerated files behind
[11:51] <mhb> pitti: okay ... but I still can't understand your PyKDE error, if you have python-kde3-dev installed
[11:52] <StevenK> infinity: Nothing, which is the problem. It's been Idle (AUTO) all day.
[11:54] <infinity> StevenK: Fixed.
[11:57] <StevenK> infinity: Thanks!
[11:58] <StevenK> Gah, and artigas immeadiately grabs gcc-4.1.
[12:01] <pitti> seb128: German dapper update langpacks look good here (also debdiff)
[12:24] <mhb> pitti: I've fixed the setup.py file to clean up after itself and the runme_as_root() class, too. Should I also include some new deps or build-deps before I commit?
[12:24] <pitti> mhb: commit those fixes separately, please (that's always better)
[12:24] <asac> stgraber: i pushed a few new revisions that hopefully address your issues out of the box now ... would be great if you could test one more time before i upload to gutsy :)
[12:25] <pitti> mhb: fixing the build deps would be appreciated, otherwise I cannot even build and test it
[12:27] <mhb> pitti: I'll try to, but I don't know much about pbuilder
[12:28] <Amaranth> pitti: only starting compiz on :0 breaks Xgl
[12:29] <Amaranth> Well, I suppose you could add that check only if you know the user isn't using Xgl..
[12:29] <pitti> mhb: I'm also happy to assist you with debugging that build error
[12:29] <pitti> Amaranth: I don't understand
[12:29] <Amaranth> pitti: Xgl is :1
[12:29] <pitti> Amaranth: oh, and no :0?
[12:30] <Amaranth> :0 is Xorg
[12:30] <Amaranth> well, except sometimes Xgl is :0 and Xorg is :63 or some other high random number
[12:30] <pitti> Amaranth: ah, I was confused; Xgl, not aiglx
[12:30] <Amaranth> depends on how you start Xgl
[12:31] <keyes> hello
[12:32] <SynrG> good morning
[12:32] <keyes> is there a way to get the /dev/DEVICENAME using the device ID (st_dev) getted by stat() ?
[12:32] <mhb> pitti: splendid! could you give me advice on how to reproduce them?
[12:33] <pitti> mhb: I just installed python-qt3-dev, as advised, and tried to build the package
[12:33] <pitti> mhb: this is current gutsy
[12:33] <StevenK> pitti: Would you mind promoting libquicktime1 (binary) to main?
[12:33] <pitti> StevenK: oh, 0 was in main; my bad
[12:34] <pitti> StevenK: done
[12:34] <stgraber> asac: building, will be ready after lunch
[12:34] <Amaranth> mhb: build in pbuilder, it'll show you all your build issues
[12:34] <StevenK> pitti: I looked at the build failure of kino for 2 minutes going "Uhhh? pitti NEWed it, it should work fine", until it twigged.
[12:34] <StevenK> pitti: Thanks. :-)
[12:34] <asac> stgraber: thanks!
[12:35] <StevenK> pitti: That needs a publisher run before the buildds get at it, right?
[12:35] <pitti> StevenK: yes, it does
[12:35] <StevenK> pitti: Okay, I'll bug you in about an hour for a give-back.
[12:35] <pitti> StevenK: splendid
[12:37] <cjwatson> keyes: no - there are major() and minor() macros in <sys/sysmacros.h> to unpack st_dev, but to find the node you have to opendir("/dev"), readdir(), stat() each one, and compare
[12:38] <keyes> ok
[12:38] <keyes> so I must use major(), minor() and parse /proc/partitions ?
[12:38] <StevenK> pitti: It looks like db3 has been killed in Debian, do you think we should follow suit?
[12:39] <StevenK> pitti: (If so, happy to file another removal bug)
[12:39] <pitti> StevenK: hm, we still have ~ 50 reverse dependencies
[12:39] <pitti> StevenK: I'd rather not break all of those packages
[12:40] <StevenK> Hrm. When is UVF?
[12:40] <StevenK> Two weeks, or so?
[12:40] <Fujitsu> 16th?
[12:40] <pitti> yep
[12:40] <StevenK> Ten days. Good enough.
[12:41] <StevenK> pitti: Okay, I think I'll revisit it in a week, which should give Debian time to hopefully sort out most of them.
[12:41] <Fujitsu> Hah, like that'll happen.
[12:42] <StevenK> Why not? It did with removing libdb3 Build-Depends.
[12:42] <pitti> StevenK: that might be ubuntu specific
[12:42] <pitti> StevenK: a lot of those reverse dependencies are probably due to libtool .la stuff and such; there are no reverse build deps left
[12:42] <pitti> -Wl,--as-needed FTW :)
[12:43] <pitti> StevenK: so I guess most of those deps should ideally go away entirely (in Debian as well)
[12:43] <StevenK> pitti: Yeah, but I seriously doubt that can be scripted, and doing monkey work for 50 packages doesn't appeal.
[12:43] <pitti> right
[12:43] <pitti> StevenK: mere no-change rebuilds should do it as well, though
[12:43] <pitti> StevenK: btw, do you use a script for mass rebuilds?
[12:43] <StevenK> Yup.
[12:43] <pitti> (/me uses http://people.ubuntu.com/~pitti/scripts/update-maintainer-transition)
[12:44] <StevenK> Oh, I wrote my own. :-)
[12:45] <StevenK> pitti: I'm happy to take say, half of them and mass-rebuild them and see if the rdepends of libdb3 drop.
[12:45] <pitti> StevenK: just try it with three samples locally and check afterwards, or so?
[12:45] <StevenK> Sounds fine.
[12:45] <pitti> or, wait
[12:46] <pitti> StevenK: you could look up some samples in checklib output
[12:46] <StevenK> You and your checklib. :-)
[12:46] <pitti> it's not mine )
[12:46] <pitti> :)
[12:46] <pitti> but it's a great tool
[12:47] <StevenK> pitti: Apropos absolutely nothing, the NBS output for libmpfr1 is confusing me.
[12:47] <StevenK> -- gutsy/main i386 deps on libmpfr1:
[12:47] <StevenK> libmpfr1
[12:47] <pitti> heh, that package has a self-dependency
[12:47] <StevenK> Oh, it doesn't?
[12:48] <pitti> $ acsh libmpfr1|egrep '^(Package|Depends)'
[12:48] <pitti> Package: libmpfr1
[12:48] <pitti> Depends: libmpfr1 (= 2.3.0~rc1.dfsg.1-1ubuntu1)
[12:48] <StevenK> ARGH
[12:48] <Fujitsu> Wahah.
[12:48] <Fujitsu> *Bwahah
[12:48] <StevenK> Who is this Laurent Fousse guy? I'll kill him myself.
[12:49] <StevenK> And the only reason that installs is because dpkg breaks the circular dependancy and deals. Sigh.
[12:49] <StevenK> pitti: It gets better. Read the long Description.
[12:50] <Amaranth> i take it that's not really a transitional package?
[12:50] <StevenK> Uncertain.
[12:50] <Fujitsu> A transitional package that depends only on itself... wtf?
[12:51] <StevenK> I think the Maintainer/Uploader was aiming for libmpfr1ldbl
[12:51] <Fujitsu> ... but they missed.
[12:51] <StevenK> So it would seem.
[12:53] <StevenK> pitti: My script doesn't touch the Maintainer field, only adds changelog entry, rebuilds the source and generates a changes file.
[12:53] <pitti> StevenK: libmpfr1ldbl doesn't Provide: libmpfr1, though (and shouldn't either), so there are two rebuilds left AFAICS
[12:53] <pitti> StevenK: yeah, that sounds fine (I have a function for that case, too)
[12:53] <Amaranth> oh, are we getting rid of this package?
[12:53] <pitti> Amaranth: sure
[12:53] <Amaranth> phew :)
[12:54] <StevenK> pitti: Three.
[12:56] <pitti> StevenK: 'k, I'll try to drop my error margin below 50% in the future :-P
[12:57] <pitti> iwj: do you have some time to look at bug 63175? it's marked for tribe4, but mvo is currently overloaded fixing an apt bug and some compiz bugs
[12:57] <ubotu> Launchpad bug 63175 in e2fsprogs "Edgy Beta -- fsck on every (re)boot" [Medium,Incomplete]  https://launchpad.net/bugs/63175
[12:58] <StevenK> OUCH!
[12:58] <StevenK> The cell-gcc source package is ~ 50Mb
[12:59] <StevenK> pitti: Since I don't listen, can you paste me the link to checklib?
[01:00] <StevenK> Found it.
[01:01] <pitti> StevenK: I checked some samples there, they are not mentioned, hmm
[01:02] <StevenK> pitti: I've just looked at three. I think one of those pulls in libdb3...
[01:03] <StevenK> terraform looks to be the odd one out of the three I checked, it has a direct dependancy.
[01:06] <stgraber> asac: Those last changes seem to be fine, I just have some problem connecting to my Open wireless AP, but it's a Fonera running on the same chan as my main wireless AP, I'll just connect to it (ssh) remove the second AP it generates (keep only the public one) and put it on another chan and retest with NM
[01:07] <asac> stgraber: does it fix open network scenario as well?
[01:08] <stgraber> asac: Just let me put that AP on another chan and test it again
[01:11] <StevenK> pitti: It looks to be sort of easily scriptable to pull down the log for checklib. I'll ponder doing that while I deal with mfpr cruft.
[01:14] <iwj> pitti: Let me have a look.
[01:19] <StevenK> pitti: Sigh. It isn't, since the versions checked by checklib aren't consistent.
[01:21] <iwj> pitti: This doesn't look straightforward.  I'm worried by the fact that Scott is saying the system clock is set from the hardware clock by udev now.
[01:21] <mhb> pitti: I managed to build it using pbuilder. Your errors were actually a sign of bad dependencies of python-kde3-dev.
[01:21] <iwj> How do we make sure it's set by the time the fsck runs ?
[01:21] <stgraber> asac: Open network doesn't seem to be working better than before (I see it associated with iwconfig but NM still tries to connect (no green light))
[01:22] <elmo> hey, if I upgrade to gutsy, will I get working projector support for a radeon (free ATI driver) based laptop?
[01:22] <mhb> pitti: I've commited the fix now, feel free to test the pbuilder
[01:24] <stgraber> asac: just did one more test, it doesn't connect if it's already associated and then you try to connect (the driver seems to auto-associate on public network)
[01:24] <stgraber> asac: but it connects if you are connected to another network (my WPA one in my case) and then you switch to it
[01:26] <asac> stgraber: well ... ok ... its a bit wierd though as we now unassociate in stage1 for everyone
[01:27] <asac> e.g. not only ipw3945
[01:27] <asac> but lets see if that is really true
[01:28] <asac> stgraber: do you see nm_info ("%s: About to SET IWESSID.", iface); ... in log ?
[01:28] <asac> on initial connect
[01:31] <stgraber> asac: http://paste.stgraber.org/2369
[01:31] <mjg59> elmo: Gutsy currently has no improvements in that area
[01:32] <mjg59> elmo: There's a driver that should support that, but we're not currently shipping it
[01:32] <asac> stgraber: but the wpa case works now always?
[01:32] <stgraber> yes
[01:33] <stgraber> takes some time but works
[01:33] <asac> how long?
[01:34] <asac> stgraber: so with open network it now only fails on initial try?
[01:35] <stgraber> asac: 10s till first green light, 5 more seconds to receive IP
[01:35] <asac> and feisty?
[01:36] <asac> do you still see those 00:00:00 ... events?
[01:37] <asac> stgraber: ^^ ?
[01:39] <StevenK> pitti: Can you give-back kino on all arches, please?
[01:39] <stgraber> asac: iirc it was a bit faster to have the first green light (looking at a watch -n1 iwconfig eth1, it seems it tries to associate once, then reset and re-associate)
[01:39] <stgraber> asac: no, I don't seem to have those 00:00:00 things any longer, otherwise connect time would be >40s
[01:40] <stgraber> asac: for the open network I'm not still sure it's not AP-related, this AP really seems crappy, I'll boot another one for testing
[01:41] <asac> stgraber: thanks a lot
[01:44] <pitti> iwj: I noticed that my own system fsck's on every boot, too, but I haven't looked into it
[01:44] <pitti> mhb: splendid, pulling
[01:45] <pitti> iwj: if it's too hairy, then I'm fine with moving off to Tribe 5
[01:45] <pitti> StevenK: given back
[01:46] <pitti> mhb: oh, that actually seems to be a real bug in python-kde3-dev then
[01:46] <mhb> pitti: yes, I'm sorting it out with Riddell
[01:47] <iwj> pitti: TBH I don't have a great deal of time right now to look into it.  I'm trying to get triggers done by FF.
[01:47] <pitti> iwj: right, that's fine; thanks
[01:47] <iwj> pitti: Good luck :-).
[01:47] <stgraber> ethernet (not associated) -> open wifi == OK
[01:47] <stgraber> ethernet (associated with open wifi) -> open wifi == NOT WORKING (associated but not connecting)
[01:47] <stgraber> wifi (associated with other wifi) -> open wifi == NOT WORKING (unassociated, then reconnect to previous WiFi)
[01:47] <stgraber> open wifi -> open wifi == OK
[01:48] <stgraber> asac: ^
[01:48] <StevenK> pitti: Thanks!
[01:49] <stgraber> asac: for wifi (associated with other wifi) -> open wifi, it disconnects from the first wifi (I see it unassociated with iwconfig) but never connects to the open ne
[01:49] <stgraber> s/open ne/open one/
[01:49] <mjg59> stgraber: The adapter never connects, or n-m never connects?
[01:49] <pitti> mhb: still leaves behind install_log.txt, but builds fine now \o/; thanks
[01:50] <stgraber> mjg59: adapter (deassociate and never try to associate with the new one)
[01:50] <mjg59> stgraber: iwconfig shows what when it's in this state?
[01:50] <stgraber> mjg59: as it doesn't se the essid nor the bssid I think the problem is NM
[01:50] <stgraber> eth1      unassociated  ESSID:off/any Mode:Managed  Frequency=2.412 GHz  Access Point: Not-Associated
[01:50] <mjg59> Yes, ok
[01:51] <mjg59> That does sound more like an n-m problem
[01:51] <StevenK> doko: I'm going to do a upload of gjdoc, pdftk, postgresql-pljava and trang to clean up the rest of the rdepends on libgcj8-0.
[01:53] <doko> StevenK: not gjdoc please, please have a look why postgresql-pljava isn't linked with -fjni -findirect-dispatch
[01:53] <StevenK> doko: Sure.
[01:54] <StevenK> doko: Also I'm looking at uploading cell-gcc for the libmpfr1 -> libmpfr1ldbl transition, does that sound okay?
[01:55] <StevenK> Ah ha. gjdoc failed to build.
[01:58] <doko> StevenK: no, will need updates anyway
[01:59] <asac> stgraber: thats strange ... but trying a second time helps?
[01:59] <StevenK> doko: Okay, I'll leave cell-gcc alone, and do the other two. Thanks.
[01:59] <bbrazil> is dapper-updates meant to have build-deps outside of plain dapper? (gnome-panel/libgnomevfs2-dev)
[02:00] <Fujitsu> bbrazil: -updates can b-d on -updates
[02:00] <pitti> mhb: works fine here, and looks reasonable; good job!
[02:00] <Fujitsu> And -security, probably.
[02:00] <doko> StevenK: but you could look at libgcj7-1 rdeps and rebuild these
[02:00] <bbrazil> Fujitsu: hmm, that's going to be fun. -security can't, so I had assumed -updates was the same
[02:01] <mhb> pitti: thank you very much!
[02:01] <cjwatson> -security can b-d on -security; -updates can b-d on -updates and (I think at the moment) -security
[02:01] <cjwatson> bbrazil: -updates needs to be able to build-dep on -updates in order to be able to build updated versions of kernel modules when the kernel changes module ABI
[02:02] <pitti> mhb: ok, so I'll upload this in a bit and guide through NEW
[02:02] <bbrazil> cjwatson: well, I needed to add a chroot to our build system at some point...
[02:02] <pitti> mhb: I want to look into implementing something else, though, and maybe have you here for some questions
[02:02] <mhb> pitti: okay
[02:03] <pitti> mhb: hm, RMClean doesn't care for that install_log.txt; can you please have a look into that?
[02:03] <StevenK> pitti: genius and gretl uploaded, which is about 40% of the libgcj8-0 rdepends.
[02:03] <mhb> pitti: yes
[02:04] <pitti> mhb: I pushed trunk, please pull or merge from it first before doing further changes
[02:09] <mhb> pitti: why did you remove the RMClean() class from setup.py?
[02:09] <stgraber> asac: sorry, I need to leave for a good part of the afternoon, will be there tonight
[02:11] <asac> stgraber: no problem ... thanks
[02:11] <spike> hi
[02:12] <pitti> mhb: erm, did I?
[02:12] <spike> even if I've played with it for a while partman still confuses me terribly. I'm using the example-preseed from feisty, I have 2 disks showing up as sda and sdb, trying to write a custom recipe to get a simple /root partition on sda and then the rest of sda and sdb in lvm
[02:12] <pitti> mhb: I only removed the old commented setup() stuff
[02:13] <pitti> mhb: oh argh, must have accidentally killed it
[02:13] <pitti> mhb: let me fix this
[02:13] <spike> even in the debian-installer documentation a single disk is referred, no examples as to how using it for 2 disks
[02:13] <pitti> mhb: btw, can you please try to use some empty lines between functions, too?
[02:13] <mhb> pitti: okay
[02:14] <spike> and the expert recipe itself doesnt mention a disk, only partitions, so how could one tell it to create an lvm that spans two disks?
[02:16] <pitti> mhb: pushed
[02:17] <cjwatson> spike: unfortunately partman only supports automatically partitioning one disk at the moment
[02:17] <cjwatson> (damn)
[02:19] <cjwatson> and he blocks messages ... oh well
[02:20] <iwj> GHODS this parser needs to be THROWN AWAY
[02:20] <iwj> What was I thinking ?
[02:23] <elmo> mjg59: thanks
[02:25] <cjwatson> never make me a kernel hacker
[02:26] <mhb> pitti: added the newlines to my branch. install_log.txt gets removed trigerring debian/rules clean now.
[02:28] <pitti> mhb: thanks
[02:28] <mjg59> cjwatson: People who aren't hacking drivers tend to use uml or virtualisation...
[02:32] <pitti> hey Hobbsee! *hug*
[02:37] <pitti> Hobbsee: do you have time to fix bug 119664? if not, who can we give that to?
[02:37] <ubotu> Launchpad bug 119664 in kdepim "Kubuntu upgrade from Feisty to Gutsy failed due to conflicting file in kdepimlibs" [High,Confirmed]  https://launchpad.net/bugs/119664
[02:38] <Hobbsee> pitti: erm....i should.  i think
[02:39] <Riddell> erm
[02:39] <Hobbsee> unless Riddell wants to
[02:39] <Riddell> ok, it's not actually kdepimlibs
[02:39] <Hobbsee> pitti: i've just got home from uni and work.  let me eat my dinner first :)
[02:39] <Riddell> I can do it then
[02:40] <Hobbsee> Riddell: that last one is because /usr/share/services/kontact/ is in kontact.install
[02:40] <pitti> Hobbsee: sure, I didn't say "NOW!", just planning :)
[02:40] <Hobbsee> pitti: :)
[02:41] <Hobbsee> pitti: this was why i said no to doing large amounts of RM for t4, btw.  i knew that with large amounts of uni work (which somehow didnt get done over the holidays), and work work, and uni, i'd have little time
[02:41] <Hobbsee> StevenK: heh :)
[02:43] <StevenK> Ah, pitti is the poor sod^W^Whappy person doing Tribe4?
[02:43] <Hobbsee> StevenK: yeah, he's the head RM and such
[02:49] <Hobbsee> StevenK: just remember.  killing people is illegal.
[02:49] <StevenK> And against the CoC, etc...
[02:51] <seb128> pitti: those dapper language packs look better, only libxine1.mo has been dropped now
[02:52] <pitti> seb128: sure that it didn't just move from gnome to base or so?
[02:52] <seb128> $ for package in *deb; do dpkg -c $package | grep xine; done
[02:52] <seb128> $
[02:52] <seb128> doesn't look like
[02:52] <pitti> ./language-pack-gnome-fr-base/data/fr/LC_MESSAGES/libxine1.po
[02:53] <pitti> seb128: ah, because it's broken
[02:53] <seb128> $ dpkg -c language-pack-gnome-fr-base_1%3a6.06+20070803_all.deb | grep xine
[02:53] <seb128> $
[02:53] <pitti> libxine1.po:196: `msgid' and `msgstr' entries do not both end with '\n'
[02:53] <Hobbsee> pitti: you're on crack.
[02:53] <pitti> Hobbsee: ?
[02:53] <Hobbsee> okay, just incorrect, not on crack, looking at this.
[02:54] <Hobbsee> It would be great to fix this for Tribe 4, but I do not consider it a release blocker. On the Ubuntu CDs it works (because ooo-gnome is installed), and on Kubuntu it is not installed by default anyway, so it does not affect the Kubuntu CDs.
[02:54] <Hobbsee> pitti: kubuntu *definetly* installs ooo.
[02:54] <Hobbsee> koffice isnt mature enough yet
[02:54] <pitti> Hobbsee: oh, what happened to koffice?
[02:54] <pitti> Hobbsee: erk, then I was indeed on crack, sorry
[02:54] <Hobbsee> hehe :)
[02:54] <Hobbsee> pitti: unless we just add openoffice-gnome to the kubuntu seeds too....
[02:54] <Hobbsee> seeing as it with both -kde and -gnome installed, it'll use the -kde one, it seems
[02:55] <pitti> Hobbsee: that'd certainly pull in two tons of dependencies
[02:55] <Hobbsee> pitti: i thought ooo had most of those
[02:56] <Riddell> what's the issue here?
[02:56] <pitti> Hobbsee: not libgnomevfs2-0 and libgconf2-4
[02:56] <Hobbsee> pitti: ah right
[02:56] <Hobbsee> Riddell: ooo not opening
[02:58] <Hobbsee> Riddell: https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/127944
[02:58] <ubotu> Launchpad bug 127944 in openoffice.org "[gutsy] Open Office applications don't start " [High,Confirmed] 
[03:07] <pygi> hello folks
[03:07] <pygi> siretart, poke when you get time pls
[03:20] <StevenK> It's under /var/lock, but requires root privs to kill.
[03:20] <Hobbsee> nothing there.
[03:20] <Hobbsee> oh, i see.
[03:20] <Hobbsee> crud
[03:21] <TheMuso> pitti: re bug 122024 I have meant to chace this up, but time hasn't allowed me to do so. I have removed the milestone for now.
[03:21] <ubotu> Launchpad bug 122024 in casper "orca should automatically get started when braille is activated" [Medium,In progress]  https://launchpad.net/bugs/122024
[03:22] <pitti> TheMuso: ah, thanks for the feedback;
[03:22] <Hobbsee> https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/130636 doesnt look so great...
[03:22] <ubotu> Launchpad bug 130636 in sudo "[gusty]  [sudo command &]  shows password!" [Undecided,Confirmed] 
[03:22] <Fujitsu> pitti: Why is apport treating main crashes as universe crashes wrt. team subscription?
[03:23] <pitti> Fujitsu: it doesn't make a difference any more; it's all ubuntu-qa
[03:24] <Fujitsu> pitti: Ah.
[03:24] <Fujitsu> Hobbsee: Wouldn't backgrounding sudo have always done that?
[03:24] <StevenK> Yup.
[03:24] <Hobbsee> Fujitsu: well, yes.  i'm just surprised they let sudo be backgrounded at all
[03:25] <Fujitsu> Not letting it be backgrounded is wrong.
[03:25] <StevenK> Actually, I don't think you can stop it.
[03:26] <StevenK> You get a SIGSTOP when you're backgrounded, I'm not sure if you can do anything in the interrupt handler to not be backgrounded.
[03:27] <Fujitsu> StevenK: Well, & won't send a SIGSTOP...
[03:27] <StevenK> I think that just changes fd 1 to a pipe
[03:28] <iwj> StevenK: Err, no, surely.
[03:28] <iwj> That is, you get SIGCONT when you're backgrounded.  You get SIGTSTP (not STOP) when you're ^Z'd.
[03:28] <iwj> And SIGTSTP can be blocked, caught or ignored.
[03:29] <StevenK> iwj: This is from memory, and it seems my memory is faultly
[03:29] <iwj> Eg, vi uses a TSTP handler to put the terminal back into canonical mode and go back to the primary (rather than alternate) screen if appropriate and generally to leave things nice for you to interact with your shell.
[03:30] <iwj> Let me look at 130636.
[03:30] <iwj> Ah, yes.
[03:30] <iwj> I will write to the bug to explain.
[03:31] <stgraber> asac: finaly I'm back a bit earlier than expected :)
[03:32] <asac> stgraber: cool
[03:32] <asac> stgraber: i tried to assemble the most important patches to the core-dev branch
[03:33] <asac> stgraber: can you give it a try if its good for you before i upload?
[03:34] <asac> stgraber: hmm http appears not to update ... should be rev 45
[03:35] <alex-weej> mvo: notification-daemon still segfaulting with the countdown - did you manage to make a release?
[03:35] <asac> stgraber: ah ... now its synched: https://code.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x
[03:35] <iwj> StevenK, Hobbsee: I've followed up.
[03:36] <stgraber> asac: it's bzr getting
[03:36] <mvo> alex-weej: no, sorry.
[03:37] <alex-weej> mvo: as long as you haven't forgotten :P
[03:37] <alex-weej> i was under the impression you had fixed it the other day, my mistake
[03:38] <elmo>  /go cv
[03:38] <mvo> alex-weej: no, sorry. I just had a look at it, but that was it
[03:38] <alex-weej> ok
[03:40] <Slim> hello
[03:40] <stgraber> asac: bzr is sloooow ... :)
[03:40] <Slim> some one help me to run Beryl
[03:41] <pygi> Slim, #ubuntu pls
[03:41] <stdin> Slim: this isn't a support channel
[03:42] <Slim> ok
[03:42] <norsetto> Slim: start with this: https://help.ubuntu.com/community/BerylOnFeisty
[03:46] <Slim> norsetto : THANKS
[03:50] <Hobbsee> iwj: cool, thanks
[03:51] <iwj> Hobbsee: NP.  Note that there's no way to stop sudo being backgrounded.  It could ignore the TSTP but that would leave it fighting with your shell for your input.
[03:52] <iwj> But I think it's probably sufficient for it at least not to print the prompt.
[03:52] <Hobbsee> iwj: incidently, i only happened to learn about backgrounding tasks last year :-S
[03:52] <Hobbsee> er, last week
[03:52] <iwj> After all   sodo bash  lets you type your password into the shell too :-).
[03:52] <Hobbsee> true that
[03:52] <stgraber> asac: ouch, 15 minutes to get the code :), let's build it
[03:55] <pitti> hi mathiaz
[03:56] <mathiaz> hi pitti
[03:56] <mathiaz> I've seen your comment for bug #130114
[03:56] <ubotu> Launchpad bug 130114 in apparmor "#include files should be in apparmor itself" [Medium,In progress]  https://launchpad.net/bugs/130114
[03:56] <mathiaz> pitti: I'll prepare a debdiff to fix that.
[03:56] <Company> siretart: how much do i have to bribe you to make you fix https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/122266 ?
[03:56] <ubotu> Launchpad bug 122266 in ffmpeg "excess deprecation warnings" [Undecided,New] 
[03:56] <pitti> mathiaz: oh, you can't build the source right out of your branch?
[03:56] <pitti> mathiaz: (or trunk, rather)
[03:57] <mathiaz> pitti: it depends which branch you're talking about, at which revision.
[03:57] <mathiaz> pitti: from core-dev it should be build fine
[03:57] <pitti> mathiaz: well, usually there is one branch 'trunk' (or similar) which represents the uploaded source packages
[03:57] <mathiaz> pitti: from ubuntu-mathiaz the latest revision won't build as it contains the merge from upstream.
[03:57] <pygi> Company, hello
[03:58] <mathiaz> pitti: ok. ubuntu from ubuntu-core-dev then. that one should build.
[03:58] <pitti> mathiaz: does that have the fix for that already?
[03:58] <mathiaz> pitti: but my branch has more experimental stuff.
[03:58] <pitti> I see
[03:58] <mathiaz> pitti: yes.
[03:58] <pygi> Company, I've been thinking of creating some swfdec0.5.1 packages for ubuntu in the coming days or so, since the last debian and us have right now it 0.4.5 if I'm not mistaken
[03:58] <pygi> Company, 0.4.3*
[03:59] <Company> pygi: the debian maintainer complains about unstable being broken all the time so he can't upload a new package
[03:59] <pygi> Company, aha, oki .... just wait then.
[03:59] <Company> pygi: other than that debian is pretty current
[03:59] <mathiaz> pitti: if you could have a look at the changelog you'll see what is the state of my branch
[03:59] <Company> pygi: don't ask me why ubuntu doesn't pull automatically
[03:59] <mathiaz> pitti: https://code.launchpad.net/~mathiaz/apparmor/ubuntu-mathiaz
[03:59] <Company> pygi: 0.4.5 is in unstable afaik
[04:00] <pygi> Company, ok, we'll get it in :) Thanks ;)
[04:00] <mathiaz> pitti: the fix for bug 130114 is in revision 496.
[04:00] <ubotu> Launchpad bug 130114 in apparmor "#include files should be in apparmor itself" [Medium,In progress]  https://launchpad.net/bugs/130114
[04:00] <Company> pygi: i'm fine with having someone pushing it through the ubuntu package building process though
[04:00] <Company> pygi: i like having people i can poke directly ;)
[04:00] <pitti> mathiaz: ah, great; so I take this as 'plz sponsor'? :)
[04:01] <mathiaz> pitti: hum... it's a bit more complicated.
[04:01] <pygi> Company, well, I'm certainly interested in the packages. But if Debian will get it, I'm fine with fixing some stuff here if needed and when needed.
[04:01] <stgraber> asac: WPA is fine (connecting and reconnecting works), I'm booting my open AP now
[04:01] <pygi> Company, I did take a peek at the code lately (yesterday to be correct)
[04:01] <mathiaz> pitti: in ubuntu from ubuntu-core-dev
[04:01] <mathiaz> pitti: https://code.launchpad.net/~ubuntu-core-dev/apparmor/ubuntu
[04:01] <mathiaz> pitti: there is only the debian/ directory.
[04:02] <mathiaz> pitti: but in my branch the full tree is there, branched from upstream import.
[04:02] <pygi> Company, I'm gonna work on the debdiff for the ffmepg bug you just posted now
[04:02] <mathiaz> pitti: which all the dpacthes applied inline.
[04:02] <mathiaz> pitti: so I was waiting for kees review
[04:02] <Company> pygi: you should probably get in touch with ds (who does the debian packages) and/or danielk (who did its own packages for ubuntu once)
[04:03] <mathiaz> pitti: so that he can update ubuntu-core-dev.
[04:03] <mathiaz> pitti: I'm pretty confident that the move to complete bzr maintainance is correct.
[04:04] <pitti> mathiaz: ok, it's fine for me to wait for kees; he should be back today, right?
[04:04] <mathiaz> pitti: and then I've fixed a couple of new bugs and package a new library in my tree.
[04:04] <mathiaz> pitti: correct. But I hope he'll have some time
[04:04] <pygi> Company, let me first create this debdiff, then we'll talk :)
[04:04] <pitti> mathiaz: ok, let's wait for him first and ask him
[04:05] <mathiaz> pitti: beside that, we're trying to update the kernel module to the latest version of upstream.
[04:05] <pitti> mathiaz: I plan to be around a while tonight
[04:05] <Company> :)
[04:05] <mathiaz> pitti: which means that we have to update the userspace part also
[04:05] <stgraber> asac: automatic switch when removing ethernet work fine too, but open network doesn't work (same issue as I told you at the begining of the afternoon)
[04:05] <mathiaz> pitti: I've already started doing that in my branch.
[04:05] <stgraber> asac: so at least no regression from current gutsy
[04:05] <pitti> mathiaz: ok, that sounds a little too intrusive for tribe4
[04:06] <mathiaz> pitti: so I'd wait for kees and we may get the latest and greatest from AppArmor integrated by tomorrow
[04:06] <pygi> Company, nice work btw ;)
[04:07] <mathiaz> pitti: ok. Well - let's wait for kees and discuss that with him, and kyle.
[04:07] <mathiaz> pitti: (for the kernel update)
[04:07] <pitti> mathiaz: agreed
[04:07] <asac> stgraber: did you find a way to assist network manager by manual actions in open network scenario?
[04:08] <stgraber> asac: didn't really try, doing so now results in a minute
[04:13] <stgraber> asac: setting up the essid by hand doesn't help, I'll try with setting the bssid (btw, I came across something weird (unable to stop connecting to open wlan))
[04:15] <stgraber> asac: ok, kill switch and bssid doesn't help either
[04:15] <stgraber> asac: http://paste.stgraber.org/2370
[04:15] <asac> but retrying does help?
[04:15] <stgraber> asac: I can't due to above bug
[04:16] <asac> stgraber: maybe restart network manager
[04:16] <stgraber> asac: the only way I have to stop NM to try connecting to the network is to killall it (/etc/dbus/event.d/25NetworkManager stop hangs)
[04:16] <stgraber> asac: I do that before every test
[04:16] <asac> oh
[04:16] <asac> unload driver as well?
[04:16] <stgraber> yep
[04:17] <asac> hmm ... manually connecting works though?
[04:29] <stgraber> yes, and NM can connect when going from LAN to Open WiFI
[04:29] <stgraber> if the card didn't associate to it in the background
[04:29] <asac> stgraber: do you use the same network id as before?
[04:29] <asac> e.g. as in wpa setup?
[04:29] <stgraber> Open Wifi is "test" and WPA is "graber-wifi"
[04:29] <stgraber> so two different APs, channel and network name
[04:29] <stgraber> (test is on chan 11 and graber-wifi on 1)
[04:29] <stgraber> asac: my current test is : LAN -> Open WLAN (success) -> WPA WLAN (success) -> Open WLAN (fail, get stuck here)
[04:29] <asac> stgraber: what do you see in log?
[04:29] <asac> stgraber: what does iwconfig give you?
[04:29] <stgraber> asac: I just did another test : LAN (with wireless associated to "test") -> test (doesn't connect but not stuck)
[04:29] <stgraber> and if LAN is connected when doing : LAN -> Open WLAN -> WPA WLAN -> Open WLAN it simply fallbacks to LAN
[04:29] <stgraber> instead of getting stuck connecting
[04:29] <stgraber> (removing the LAN plug once connect to the WPA)
[04:29] <stgraber> asac: when it's stuck iwconfig shows nothing, no essid, no bssid and not-associated
[04:29] <Hobbsee> oh is this the "open networks with ipw3945 wont connect via the mangler?" bug?
[04:31] <Amaranth> ha
[04:31] <Amaranth> that's funny, i've had the exact opposite problem
[04:31] <Amaranth> but i don't have time to debug it so i just changed the security on my network
[04:32] <pitti> mvo: thanks for the apt fix
[04:34] <mvo> pitti: cheers, looks like I need to fix something in the apport generation code soonish too, just discovered some problem there too, but I'm not yet sure if its me or LP (when trying to submit I get a OOPS from LP)
[05:02] <Riddell> pitti: are you planning to merge/upload kde restricted-manager?
[05:02] <pitti> Riddell: does your recent k3b upload happen to fix bug 123760? (since you touched/uploaded it anyway)
[05:02] <ubotu> Launchpad bug 123760 in k3b "upgrade feisty to gutsy libk3b2 error" [Undecided,New]  https://launchpad.net/bugs/123760
[05:02] <pitti> Riddell: yes, indeed I am
[05:03] <pitti> Riddell: I was going to add another feature, but I'll upload it right now and do that later
[05:04] <pitti> mhb: I'll add the missing Conflicts:/Replaces:, and upload
[05:05] <mhb> pitti: okay, don't forget to merge the small commit I made a while back
[05:05] <pitti> yep
[05:05] <mhb> pitti: what is the feature you want to do for restricted-manager?
[05:05] <pitti> mhb: https://wiki.ubuntu.com/RestrictedManagerImprovements point 1
[05:06] <pitti> mhb: oh, and ${Source-Version} -> ${binary:Version}, fixing, too
[05:06] <Riddell> pitti: it doesn't, but I can look at that
[05:07] <mhb> pitti: the tray notification?
[05:08] <pitti> mhb: yes
[05:08] <pitti> mhb: ah, thanks for the fixes; I fixed s/rm/rm -f/, and merged
[05:09] <mhb> pitti: I thought that's already implemented - there were classes for that (Notification), and a --check option.
[05:09] <pitti> mhb: right, the tools are there, but not that behaviour
[05:10] <pitti> mhb: right now, it tells you 'new restricted drivers in use'
[05:10] <pitti> mhb: but not yet 'You can enable restricted drivers for more performance'
[05:12] <pitti> mhb, Riddell: r-m pushed/uploaded
[05:12] <pitti> mhb: please pull/merge
[05:13] <mhb> pitti: oh, I thought that's what it meant to say ... well, we'll talk about it once you have some time, okay?
[05:13] <pitti> Riddell: I'll be off for some hours to prepare for a nightshift; if you want this soon, please binary-NEW it in a bit
[05:13] <Riddell> sure
[05:13] <pitti> mhb: yes, let's
[05:13] <LaserJock> what's the ETA on Tribe 4 Freeze?
[05:13] <mhb> pitti: thank you for the push!
[05:13] <pitti> mhb: I don't expect it to be difficult, if the abstract class is actually good, it shouldn't require any porting
[06:01] <Riddell> "dch: you must have the liburi-perl package installed"  why don't we just have that as a depends?
[06:02] <cjwatson> devscripts has a lot of scripts with a lot of different dependencies and apparently intentionally doesn't depend on all of them
[06:02] <cjwatson> see its package description
[06:05] <Riddell> seems to defeat the point of having a package manager
[06:06] <StevenK> Riddell: Okay, so we add everything to Depends. This means gnuplot, debian-keyring and probably three or four other packages also get punted to main.
[06:07] <StevenK> I don't know about you, but gnuplot for one is a pig, and I don't particularly want it installed, even if it does show pretty graphs.
[06:09] <StevenK> And if we decide to promote a subset of dependancies to hard Depends, who's to decide which subset that is? It's a can of worms, and you can't please everybody, this way it annoys everyone equally.
[06:10] <LaserJock> StevenK: well, if it helps at all, I'll probably be getting gnuplot into Main ;-)
[06:11] <Hobbsee> LaserJock: run.  run now
[06:11] <LaserJock> hehe
[06:11] <StevenK> LaserJock: It doesn't, and bugger off. :-P
[06:11] <LaserJock> ouch
[06:13] <StevenK> LaserJock: I was picking on gnuplot because I knew it was in universe and it helps prove my point.
[06:14] <StevenK> What about R?
[06:14] <LaserJock> I don't do much stats
[06:14] <StevenK> Even if you don't, R's graphs kick ass
[06:15] <LaserJock> my lab uses gnuplot and pgplot for graphing, that's pretty much it
[06:33] <mvo> carlos: I uploaded new pots for ddtp, can you give me a hint where I find the import queue again to check if they are listed there already?
[06:34] <mvo> hey Hobbsee!
[06:34] <Hobbsee> :D
[06:35] <carlos> mvo: https://translations.launchpad.net/translations/imports
[06:36] <carlos> mvo: but I don't see your files...
[06:36] <mvo> carlos: I uploaded them some minutes ago
[06:36] <mhb> mvo: by the way, are ddtp translations imported correctly into gutsy? I haven't seen any Czech strings although my fellow translators did a handful
[06:36] <carlos> mvo: did you get any email about your imports?
[06:37] <mvo> mhb: I'm currently working on getting them in
[06:37] <mhb> mvo: okay, great.
[06:37] <mhb> thanks
[06:37] <mvo> carlos: not yet
[06:38] <carlos> mvo: are you completely sure your script worked?
[06:39] <carlos> mvo: I don't see any trace of your upload
[06:39] <carlos> and it should be there, even if the files are broken
[06:42] <mathiaz> keescook: what's the plan to update apparmor ?
[06:43] <keescook> mathiaz: waiting for kernel to include latest stuff.  kyle, was there an update already, or are the apparmor patches waiting until after this tribe?
[06:43] <mvo> carlos: checking now
[06:43] <carlos> ok
[06:43] <mvo> carlos: no, looks like the authentication mechanism changed again
[06:45] <carlos> mvo: :-(
[06:46] <mvo> carlos: heh :) not the authentication, but the cookie name is different it seems, I investigate
[06:46] <carlos> mvo: I think we had to change it a while ago to fix a problem with our authentication code
[06:48] <mvo> carlos: yes, that was it
[06:49] <carlos> mvo: yeah, I see it now
[06:49] <carlos> mvo: so, was that encoding problem related with your files or a bug in Launchpad?
[06:50] <mvo> carlos: not sure yet
[06:50] <carlos> ok
[06:51] <mvo> carlos: hrm, no, it looks like this is a encoding problem in the package description
[06:53] <carlos> ok
[06:53] <carlos> thanks for checking
[06:54] <mvo> carlos: will it be enough to write the encoding in the header? everything in there should be utf-8
[06:55] <carlos> mvo: so the .pot file content is UTF-8 but the .pot file header doesn't note it?
[06:55] <mvo> carlos: yes
[06:55] <carlos> mvo: in that case, yes, adding UTF-8 as the charset should be enough
[07:02] <jwendell> Hi, seb128
[07:02] <jwendell> seb128, a doubt: is tracker useful without tracker-search-tool package?
[07:03] <ion_> jwendell: Yes.
[07:03] <jwendell> ion_, how?
[07:03] <mvo> carlos: if I upload new translations now (for ddtp from debian), rosetta will do the right thing? i.e. merge those with the ubuntu translations and not throw away any of them, right?
[07:04] <ion_> jwendell: Programs can use tracker as a generic shared metadata database. The sooner they do that the better. In the meantime, tracker-utils contains command line clients for trackerd, which are also useful.
[07:05] <jwendell> ion_, do you know any GNOME program which uses tracker?
[07:05] <ion_> jwendell: Nautilus
[07:06] <Amaranth> bingo
[07:06] <Amaranth> nautilus can do it's saved search thing using tracker
[07:06] <Amaranth> that's like the #1 use, i think
[07:07] <ion_> Hopefully Nautilus, F-Spot etc. support shared tags in the future, using tracker as the backend. That would also fix some other things from the F-Spot TODO list for free, e.g. adding images automatically when they appear in the filesystem and tracking moved files.
[07:08] <coNP> BTW, do you know if F-spot Picasaweb export has been recovered?
[07:11] <jwendell> ion_, where is the nautilus option to use tracker?
[07:11] <jwendell> ion_, i'm not finding
[07:12] <Amaranth> jwendell: have to rebuild nautilus with a build-dep on tracker
[07:12] <jwendell> hmm
[07:13] <jwendell> i guess this is happen for gutsy, right, seb128 ?
[07:13] <jwendell> s/is/will/
[07:13] <coNP> c-f in theory, but works not for me
[07:14] <jwendell> coNP, c-f?
[07:14] <coNP> ctrl+f
[07:15] <coNP> sorry /me tends to use emacs-style hotkey-abbreviations
[07:15] <coNP> that is Go / Search for files
[07:15] <carlos> mvo: if you upload a tarball in the template form, the new translations will be applied automatically, the changes will appear as suggestions
[07:15] <jwendell> coNP, yep, i have tested that, but Amaranth said that nautilus has to be rebuilt with a specifc flag
[07:17] <coNP> but it should work out of the box
[07:17] <coNP> with our without tracker
[07:17] <coNP> it is not nice that we have menu item that "does nothing"
[07:17] <Amaranth> coNP: it does something
[07:18] <Amaranth> coNP: just very slowly
[07:18] <jwendell> yep
[07:18] <Amaranth> coNP: and it only does filename matches, not file contents
[07:18] <coNP> no dialog for me
[07:18] <Amaranth> jwendell: no flag, just with a build-dep on libtracker-dev or whatever
[07:18] <Amaranth> coNP: it replaces the path buttons
[07:18] <Amaranth> or the location entry if you swing that way
[07:19] <coNP> okay, but if I launch nautilus, open the dialog and nothing happens... that is not good
[07:19] <Amaranth> what dialog?
[07:19] <Amaranth> there is no dialog
[07:19] <coNP> okay I noticed
[07:19] <coNP> it replaces the file locator
[07:19] <coNP> sorry :)
[07:19] <jwendell> seb128, and tracker should live in main, not in universe, right?
[07:19] <seb128> hi jwendell
[07:20] <seb128> jwendell: tracker is un main already
[07:20] <seb128> jwendell: not sure to understand your question
[07:20] <Amaranth> it'd have to be or it couldn't be in ubuntu-desktop
[07:20] <cjwatson> seb128:    tracker | 0.6.0-1ubuntu1 | gutsy/universe | i386, sparc
[07:20] <cjwatson> somebody screwed up
[07:21] <jwendell> seb128, apt-cache show tracker shows 'Section: universe/utils'
[07:21] <cjwatson> I suggest change-override.py again ...
[07:21] <seb128> cjwatson: I though pitti did promote consolekit, fast-user-switch-applet and tracker
[07:21] <seb128> doing it now
[07:22] <nekohayo> the tracker packages in gutsy's Main do not include translations, who should I be talking to? or what IRC channel?
[07:22] <seb128> nekohayo: that's not a bug, translations are in language packs in Ubuntu
[07:22] <cjwatson> nekohayo: they'll get into the language packs automatically some time after they're promoted properly to main
[07:23] <cjwatson> may not happen instantly so don't worry right now
[07:23] <nekohayo> is there a page explaining that whole concept of ubuntu's (time delayed) language packs? kind of confuses me :)
[07:24] <Amaranth> nekohayo: that's development for you :)
[07:24] <Amaranth> nekohayo: basically all packages in main have their translations stripped and we have big language pack packages instead
[07:25] <Amaranth> because our translations are worked on on rosetta and it's easier to update one big pack
[07:25] <nekohayo> Amaranth: well the thing that I was asking myself.... "wtf? installing a language pack installs ALL the translations of ALL the apps in Main?!"
[07:25] <cjwatson> nekohayo: which isn't true ...
[07:25] <cjwatson> they're split into base, gnome, and kde
[07:25] <nekohayo> well that's what I don't understand :)
[07:26] <Amaranth> nekohayo: Better than me getting translations for 50 languages I don't speak :)
[07:26] <cjwatson> it's a compromise between package size and overwhelmingly enormous numbers of packages
[07:26] <nekohayo> Amaranth: yeah I guessed that
[07:26] <seb128> nekohayo: you could ask why installing an application bring you translations for 60 locales you don't use ;)
[07:26] <cjwatson> lots of tiny packages would have a cost too, in terms of size of the package index files, memory use of dpkg, etc.
[07:26] <coNP> Maybe we should start a language school... :)
[07:26] <nekohayo> yeah, I kind of understand why packages are stripped, but I was puzzled as to how you did it
[07:27] <nekohayo> as in, "do they apply black magic so that it installs the translations depending on what you have installed?"
[07:27] <Amaranth> you choose your language in the installer :)
[07:27] <cjwatson> no, we just have the installer install the appropriate language packs and then they get upgraded whenever there are new versions
[07:28] <cjwatson> if you install KDE packages on top of a GNOME system, yes, you'd need to install language-pack-kde-$LL in order to get translations
[07:28] <cjwatson> but it's enough of a corner case that we don't worry
[07:29] <nekohayo> thanks for the explanation folks
[07:30] <seb128> jwendell: where is the vino password stored when use gnome-keyring?
[07:30] <seb128> use -> using
[07:31] <jwendell> seb128, in the keyring ??
[07:31] <seb128> jwendell: would changing from using gnome-keyring to not using would mean that users have to configure their password again?
[07:31] <seb128> jwendell: which would not be acceptable ...
[07:31] <nekohayo> oh, how often are the language packs updated/uploaded, typically?
[07:32] <jwendell> seb128, it's stored in gconf, but...
[07:32] <jwendell> i have to take a look....
[07:32] <seb128> jwendell: would be nice, thanks, because we need to make sure they can still log-in if we change the backend
[07:37] <jwendell> seb128, yep, users have to retype their passwords
[07:37] <jwendell> seb128, unless they used to use older ubuntu version, which doesn't use keyring
[07:38] <jwendell> seb128, so, the password is still on gconf
[07:38] <seb128> jwendell: what old version? feisty is already using the keyring
[07:38] <jwendell> nope
[07:38] <seb128> ?
[07:38] <jwendell> feisty doesn't use keyring...
[07:40] <jwendell> DEB_CONFIGURE_EXTRA_FLAGS += --enable-avahi --enable-libnotify
[07:40] <seb128> jwendell: http://launchpadlibrarian.net/6739390/buildlog_ubuntu-feisty-i386.vino_2.18.0-0ubuntu1_FULLYBUILT.txt.gz
[07:41] <mvo> iwj: pitti asked earlier if you have some spare cycles to look at bug #63175 ?  did you reply to that one (and I missed it)?
[07:41] <ubotu> Launchpad bug 63175 in e2fsprogs "Edgy Beta -- fsck on every (re)boot" [Medium,Incomplete]  https://launchpad.net/bugs/63175
[07:41] <seb128> jwendell: it's linking with -lgnome-keyring, would be nice to have the configure display a summary of options though
[07:42] <jwendell> seb128, yep, you're right
[07:42] <jwendell> i'll do it for tomorrow
[07:42] <seb128> thanks ;)
[07:46] <coNP> What happened to gnome-keyring-cil? Where do we have this now?
[07:55] <pitti>   ubuntu-desktop: Depends: fast-user-switch-applet but it is not installable
[07:55] <pitti> elmo: Broken packages
[07:55] <pitti> seb128: ^ hmm
[07:56] <pitti> with the usual "E:' instead, of course
[07:56] <seb128> pitti: is it in main?
[07:56] <pitti> seb128: it's already past that stage on i386, I think (on terranova)
[07:56] <pitti> just failed on king
[07:56] <pitti> and it's not on gutsy_probs.html,
[07:56] <seb128> pitti: dunno why, that's not enough informations
[07:57] <seb128> can you try to apt-get install fast-user-switch-applet ?
[07:57] <pitti> ast-user-switch-applet | 2.18.0-1ubuntu1 |         gutsy | source, i386, sparc
[07:57] <pitti> fast-user-switch-applet | 2.18.0-1ubuntu1 | gutsy/universe | amd64, ia64, powerpc
[07:57] <pitti> indeed
[07:57] <pitti> how can that happen?
[07:57] <seb128> dunno, that was the same for tracker
[07:58] <seb128> I just ran the change-override again some minutes before you joined
[07:58] <pitti> oh, it still is
[07:58] <pitti> seb128: ah, good
[07:58] <pitti> so, next publisher then
[07:58] <LaserJock> did the netinstall .isos go somewhere? I can't find them anywhere
[08:00] <Amaranth> didn't they used to be made with the debian-installer package?
[08:04] <Mithrandir> keescook: apxs, apparmor> no, it's not a problem, I was just wondering why on earth apparmor needed apxs, but then, I didn't know about the apache module.
[08:04] <LaserJock> Amaranth: like at build time?
[08:04] <pitti> mhb: is there no way around having restricted-manager-kde be arch:any?
[08:04] <Amaranth> LaserJock: well, i thought i found them in that dir anyway
[08:04] <pitti> mhb: it's only Python, after all
[08:04] <LaserJock> Amaranth: I don't see anything :/
[08:05] <Riddell> mhb: it's also a plugin to kcontrol, which needs c++ wrapper
[08:05] <mhb> pitti: it's not only python, it has to compile the bindings for system settings KCM
[08:05] <Riddell> err, pitti that was for
[08:05] <pitti> Riddell: ah, I see
[08:06] <pitti> Riddell: did you already NEW restricted-manager? it's not in the queue and not in accepted
[08:06] <pitti> Riddell: might be in-limbo publishing
[08:08] <Riddell> pitti: I did
[08:08] <Riddell> put the packages into restricted
[08:09] <pitti> ok, so it's being published now
[08:09] <pitti> Riddell: I'll trigger new CD images after that run
[08:09] <Riddell> I'm updating kubuntu-meta to add it
[08:10] <cjwatson> LaserJock: Amaranth is correct: http://archive.ubuntu.com/ubuntu/dists/gutsy/main/installer-i386/current/images/netboot/
[08:10] <Amaranth> right idea, though
[08:14] <mhb> pitti: what's the policy on adding new restricted drivers/firmware to restricted-manager? Is there a form for the users to fill, or is it "restricted" to the most used hw only?
[08:14] <Amaranth> mhb: it's restricted to things that can be legally redistributed and have a real use
[08:15] <Amaranth> real use meaning makes your computer usable
[08:15] <wasabi> where 'usuable' is subjectively defined.
[08:15] <Amaranth> well, yeah
[08:15] <stdin> mhb: you'd have to talk to the kernel team too, the restricted manager is just a frontend to the modules that are in the linux-restricted-modules packages
[08:15] <Amaranth> it's generally wireless and video
[08:17] <pitti> mhb: you can add as many handlers as you wish, but it does not make sense at all to add actual firmware to it
[08:18] <pitti> mhb: if we can redistribute firmware, we just do it in l-r-m, instead of writing complicated code around it :)
[08:19] <mhb> pitti: yeah, I guess so. When I filed a bug about a piece of firmware that could be handy for a class of dvb-t adapters, nobody ever looked at it.
[08:20] <mhb> so I'm wondering what the policy is.
[08:20] <mhb> thanks for the answers, folks!
[08:20] <pitti> mhb: that's just a question of bug triage capacity
[08:21] <pitti> cjwatson: ah, alternate CD behaves now (u-desktop isn't installable, but it doesn't insist on a mirror any more); thanks
[08:22] <jwendell> seb128, talking on keyring, every time when i need to type my ssh password, ssh-agent asks for it, but don't save it on keyring
[08:23] <jwendell> since i updated to gutsy
[08:23] <jwendell> is that an know issue?
[08:23] <cjwatson> pitti: you're welcome
[08:23] <cjwatson> pitti: still working on syslinux/gfxboot
[08:24] <geser> jwendell: does ssh-add -l list your key?
[08:25] <jwendell> geser, yep
[08:25] <jwendell> geser, but it asked for my phrase
[08:26] <jwendell> geser, and, in that dialog, the checkbox 'save on keyring' is not working
[08:26] <seb128> jwendell: I think there is a bug about it
[08:26] <jwendell> ah ok
[08:30] <mathiaz> keescook, pitti: I've pushed a new version of apparmor package that fixes bug 130114.
[08:30] <ubotu> Launchpad bug 130114 in apparmor "#include files should be in apparmor itself" [Medium,In progress]  https://launchpad.net/bugs/130114
[08:30] <mathiaz> keescook, pitti: https://code.launchpad.net/~mathiaz/apparmor/ubuntu-mathiaz-130114
[08:30] <pitti> mathiaz: yay
[08:31] <mathiaz> pitti, keescook: it only contains the fix for the bug. All the bzr merge, upstream update, etc... is not there.
[08:32] <mathiaz> pitti, keescook: hum... forgot to commit...
[08:35] <pitti> keescook: do you want to upload this, or shall I?
[08:35] <mathiaz> pitti, keescook: I've fixed it. The branch has the fix.
[08:38] <pitti> mathiaz: right, I mean uploading it
[08:39] <pitti> mathiaz: and I guess keescook wants to merge it into the 'ubuntu' branch at the same time, to not diverge
[08:39] <pitti> mathiaz: did you see keescook today already?
[08:45] <pitti> mathiaz: works fine, thank you!
[08:46] <pitti> mathiaz, keescook: I pulled ubuntu-mathiaz-130114 into ubuntu, released, uploaded, and pushed
[08:56] <mathiaz> pitti: excellent - thanks.
[08:56] <mathiaz> pitti: I had a talk with kees today.
[08:56] <mathiaz> pitti: it seems that we won't have time to update to the latest version of apparmor for tribe-4.
[08:56] <psusi> anyone familiar with, and care to discuss https://wiki.ubuntu.com/UdevLvmMdadmEvmsAgain?
[08:56] <mathiaz> pitti: so we've decided to postpone it.
[08:57] <mathiaz> pitti: and we've just released a new version to fix bug 130114
[08:57] <ubotu> Launchpad bug 130114 in apparmor "#include files should be in apparmor itself" [Medium,Fix released]  https://launchpad.net/bugs/130114
[09:00] <Riddell> calc: are you going to ask for a freeze exception for openoffice?
[09:01] <calc> Riddell: not for the initial upload, but to let the final version in, yes
[09:01] <calc> Riddell: i am hopefully doing the last test build before upload for m224 right now
[09:04] <Riddell> well you have until pitti wakes up tomorrow to get it uploaded :)
[09:06] <jwendell> seb128, http://svn.gnome.org/viewcvs/vino?view=revision&sortby=date&revision=643 ;)
[09:07] <calc> Riddell: ok :)
[09:07] <seb128> jwendell: that was quick ;)
[09:07] <calc> Riddell: oh you mean for tribe-4 then?
[09:07] <Riddell> calc: yes
[09:07] <calc> Riddell: freeze doesn't happen until aug 16 iirc
[09:07] <calc> but yea i want it in tribe-4 also
[09:07] <seb128> calc: archive is frozen for tribe
[09:08] <calc> oh i see
[09:08] <seb128> calc: you should subscribe to ubuntu-devel-announce
[09:08] <Riddell> it is?  u-d-a said tuesday
[09:09] <LaserJock> yeah
[09:09] <seb128> Riddell: no, I meant that the archive is frozen for every tribes
[09:09] <infinity> Doesn't look very frozen to me. :P
[09:09] <Riddell> right
[09:09] <calc> seb128: thanks for reminding me about that freeze as well :)
[09:09] <Riddell> hey, I reminded you first!  (just wasn't very clear about it)
[09:10] <calc> Riddell: thank you as well :)
[09:10] <Riddell> :)
[09:10] <seb128> looks like I was not clear neither ;)
[09:10] <calc> either way there isn't much time left, heh
[09:10] <seb128> anyway, let's get some other crack in before the freeze
[09:17] <infinity> calc: Best to get it in before the tribe freeze (so, now), than to wait post-tribe... Especially if it might not build on all arches, or have other problems that will take a while to hunt down.
[09:17] <infinity> calc: "Upload early, upload often" being the Ubuntu release and debugging motto. :P
[09:17] <pitti> seb128, calc: yeah, I'll freeze tomorrow morning (i. e. now plus some 12 hours)
[09:18] <pitti> depending on how the archive status looks like, of course
[09:22] <calc> pitti: ok
[09:23] <calc> pitti: what would i need to do to get libsvg into main, just fill out a MIR?
[09:24] <calc> i can do an internal build for now, but would be nice to use the one in the repo if possible
[09:26] <ajmitch> hello keescook
[09:26] <keescook> mathiaz: did pitti just upload the fix?
[09:26] <keescook> hiya ajmitch
[09:27] <calc> keescook: will you be around later tonight? i should have a OOo upload ready before tomorrow morning
[09:28] <keescook> calc: ooh, excellent.  yup, I'll be around.
[09:30] <pitti> hi keescook
[09:30] <mathiaz> keescook: yop
[09:30] <keescook> hiya pitti!
[09:30] <pitti> calc: yes
[09:31] <keescook> pitti: nothing in CUPS is setuid, right?  It just is started as root?
[09:32] <pitti> keescook: right
[09:32] <pitti> keescook: it drops the backend privileges, though
[09:33] <keescook> okay, cool.  I'm not suring using apparmor profile for a setuid tool can ever be safe, so I just wanted to make sure that wasn't true for cups
[09:33] <keescook> s/suring/sure
[09:34] <keescook> i should clarify: "can ever be safe" when starting outside of isolation
[09:36] <pitti> keescook: ah, did you take a look at the profile?
[09:36] <keescook> pitti: not yet, I want to do that, but thought I'd ask about my only serious concern.  :)
[09:36] <pitti> keescook: there were some things which could be much tighter, but it would have taken me a lot of time
[09:37] <pitti> keescook: also, I need to extend it a little bit for things like cups-pdf, which need to write into /home
[09:37] <keescook> pitti: ew, really?
[09:37] <keescook> why is that?
[09:37] <pitti> keescook: well, that's its very nature
[09:37] <pitti> keescook: it's a 'pdf file printer' backend
[09:37] <pitti> keescook: i. e. anything you send to it will land as pdf in your home
[09:38] <pitti> keescook: i. e. the more general solution of OO.o's "export pdf" button
[09:38] <keescook> ugh, so the cups daemon writes to the user's dir instead of a client talking to the server?
[09:38] <pitti> keescook: yeah :/
[09:38] <keescook> but that part at least doesn't run as root?
[09:38] <pitti> keescook: it starts as root
[09:38] <pitti> keescook: I didn't look into its priv dropping
[09:38] <pitti> keescook: ideally it would open and chown the fd, and then drop to the system user
[09:39] <infinity> It needs to be able to change it's EUID to that of the user making the printing request, so it's got to be pretty rootish.
[09:39] <pitti> ('lp')
[09:39] <pitti> keescook: it's only in universe, but it's quite popular, and we even have a spec for it
[09:39] <keescook> a print server should write to its queue or a printer -- not user's home directories!
[09:39] <pitti> keescook: so I'd rather make it work halfway sane
[09:39] <keescook> okay, sure.
[09:40] <pitti> keescook: full ack, but what do you want to do? :-) "Ooh, PDF writer, *clickcklick* install *shiny*
[09:40] <infinity> As broken as the design may be, it's incredibly useful. :/
[09:40] <keescook> infinity: sure, I realize the utility of course.  I'm just amazed at the implementation.  :)
[09:41] <pitti> keescook: problem is, there's nothing on the user's side which could listen for it and isn't confined to gnome/kde/etc/
[09:41] <pitti> keescook: and, TBH, if it's done right, it doesn't need to be less secure than a client-server
[09:42] <infinity> If the few lines of root-run code are just that -- a few lines.
[09:42] <infinity> open fd, chown, drop privs.
[09:42] <keescook> yeah, I can agree with that.
[09:42] <pitti> (and take care not to stumble over symlinks and existing files etc.)
[09:42] <infinity> Yeah.
[09:43] <infinity> But all that should be an easily-auditable block before the big blinking "We're dropping privs now!" marker.
[09:43] <infinity> Probably some very hackish guesswork. :/
[09:43] <pitti> that's where the scary part comes in
[09:44] <pitti> cupsd will call it with the uid, I figure
[09:44] <infinity> Should look at it to see if it's spoofable.
[09:44] <pitti> yay, the tribe 4 bug list just dropped below 20
[09:45] <infinity> pitti: Are we keen on seeing that MySQL root user feature request (I refuse to call it a "bug") fixed for gutsy?
[09:45] <Kmos> pitti: you are counting the bugs reported with "Gutsy" in title ?
[09:45] <pitti> infinity: I am, very much
[09:45] <infinity> pitti: If so, I think I might have to take some time and just write it myself.
[09:46] <pitti> infinity: I just kept moving it from one tribe to the next so far
[09:46] <infinity> pitti: Yeah, I noticed you retargetting it, which is why I asked. :)
[09:46] <pitti> Kmos: no, https://bugs.launchpad.net/ubuntu/+bugs?field.milestone:Alist=556
[09:46] <pitti> infinity: it's not a Tribe4 blocker
[09:46] <Kmos> pitti: ah.. ones with milestone set
[09:47] <infinity> pitti: Apparently, it's a Tribe-5 blocker. :)
[09:47] <pitti> and soren is on vac, so I didn't have much hope
[09:47] <mvo_> pitti: FYIW I can not reproduce #107109 here
[09:47] <infinity> pitti: After soren and I discussed it, the buck was passed to me/ch/seanius anyway.
[09:47] <pitti> infinity: my optimism is infinite :)
[09:47] <infinity> pitti: And ch is rapidly losing interest in Debian MySQL, so it's me or seanius... I have yet to discuss it with Sean.
[09:48] <pitti> Kmos: erm, https://bugs.launchpad.net/ubuntu/+bugs?field.milestone:Alist=471 of course
[09:48] <pitti> mvo_: wow, you can get two X sessions with compiz on both?
[09:49] <pitti> mvo_: last time I even attempted that, my entire screen went black, with no way whatsoever to recover (VT switching, blind typing, etc.)
[09:51] <mvo_> pitti: no, but it fallsback to metacity just fine for me
[09:51] <pitti> yay http://cdimage.ubuntu.com/daily-live/20070806.2/, live images!
[09:51] <fednube> are there any info on jailing users to uload, download and delete......... how easy is it tosetup ?
[09:51] <infinity> fednube: -> #ubuntu
[09:52] <mvo_> pitti: yeah!
[09:52] <fednube> ok thx
[09:52] <pitti> infinity: re mysql, I just wonder why it is so hard to do; in my naive thinking, this would be a ten line patch or so (but it probably requires mangling test suite, etc., too)
[09:53] <cjwatson> woo, got gfxboot at least running, though now the theme crashes
[09:53] <pitti> go, cjwatson, go!
[09:53] <cjwatson> still, at least it's now a less hard problem
[09:53] <Nafallo> pitti: will we have dvds in tribe4? :-)
[09:54] <pitti> Nafallo: hm, ATM they are hopelessly oversized
[09:54] <infinity> pitti: It's probably going to be a reasonably compact patch when done, sure, but it's the doing (and the making those 10 lines be the correct 10 lines) that takes some monkeys and typewriters. :P
[09:54] <infinity> pitti: In other words, I (or someone) just need a tuit rounded.
[09:55] <Nafallo> pitti: that's what I thought then :-P
[09:55] <Nafallo> pitti: the question would be why... :-P
[09:55] <pitti> Nafallo: main is too big :)
[09:56] <Nafallo> pitti: throw useless stuff out then... exim4, courier etc... ;-)
[09:57] <pitti> Nafallo: see, that's the problem; there's nothing where I could 'throw out' stuff
[09:57] <pitti> there's no 'dvd' seed
[09:57] <pitti> Nafallo: AFAIK, the DVD is either the union of all seeds, or entire main
[09:57] <Nafallo> main -> universe? :-)
[09:58] <Nafallo> the union of $dist-* I think?
[09:58] <Nafallo> Riddell had some nice diagram the other day... :-)
[09:59] <Nafallo> http://kubuntu.org/~jriddell/tmp/seeds.png
[09:59] <Riddell> https://wiki.kubuntu.org/SeedManagement
[09:59] <Nafallo> Riddell: aha. there is no dvd on your diagram :-P
[09:59] <cjwatson> pitti: the DVD is built from the supported seed for the relevant flavour
[10:00] <Riddell> as indicated in the diagram
[10:00] <cjwatson> contrary to popular belief, it is not all of main
[10:00] <pitti> cjwatson: ah, thanks
[10:00] <Nafallo> Riddell: ah, right. just read the text... *blushes*
[10:05] <cjwatson> the usual solution to the DVD being too big is to take some crap out of supported
[10:05] <cjwatson> Extra-Exclude is useful
[10:05] <Nafallo> so just throw stuff out of supported then... ;-)
[10:05] <calc> need ubuntu bluray disk to hold all of main ;)
[10:05] <pitti> cjwatson: so the trick would be to fan out some stuff in supported to the various seeds?
[10:05] <Nafallo> exim4, courier etc... ;-)
[10:05] <infinity> Nafallo: Shush, you.
[10:05] <Nafallo> *s*
[10:05] <infinity> I'll see Openoffice out of main before I lose exim.
[10:05] <Nafallo> but really... I thought we didn't want duplicate functionality?
[10:05] <pitti> Nafallo: second thing is that some actually needs to test the DVDs
[10:05] <infinity> Nafallo: Which is why we ship both GNOME and KDE?
[10:12] <Nafallo> infinity: not on the same dvd we ain't...
[10:12] <Nafallo> pitti: right...
[10:15] <infinity> Nafallo: So, we'll just randomly pick one MTA per flavour, and mix it up a bit!
[10:15] <Nafallo> pitti: I need a to get my laptop so I can buy another one then :-P
[10:15] <infinity> Nafallo: (MTAs are tiny anyway, you may be barking up the wrong tree)
[10:15] <Nafallo> infinity: hehe. sounds fun! let's do it! :-)
[10:15] <Nafallo> Mixbuntu :-)
[10:23] <cjwatson> pitti: no, that won't help - I mean unsupport some big irrelevant binaries
[10:23] <pitti> what's wrong in this diff between the 20070804 and 20070806.3 live manifest?
[10:23] <pitti> -ubiquity 1.5.6
[10:23] <pitti> -ubiquity-casper 1.95
[10:23] <pitti> -ubiquity-frontend-gtk 1.5.6
[10:23] <pitti> -ubiquity-ubuntu-artwork 1.5.6
[10:23] <cjwatson> pitti: should only have been lpia ...
[10:23] <cjwatson> but, indeed. huh?
[10:23] <pitti> I wondered why I didn't see an ubiquity icon on the live
[10:23] <siretart> Company: actually not that much, but I think it is very likely that this has been already fixed upstream, and we need to update the package anyway
[10:23] <pitti> hm, this morning's ubuntu-meta upload looked fishy, I'll check that
[10:23] <Company> siretart: pygi already looked at it
[10:23] <siretart> yes, I saw
[10:23] <Company> siretart: but yeah, it seems to be in upstream, so go pull a new ffmpeg so i have something else to complain ;)
[10:23] <siretart> Company: the thing is that we carry quite a lot of patches with us around, which need all to be checked and adapted :/
[10:23] <Company> yeah, so 1 patch more doesn't hurt ;p
[10:23] <pygi> siretart, can't we just get that debdiff applied for him temporarily?
[10:23] <cjwatson> pitti: I don't think it can be that
[10:23] <pygi> Company, no, he meant when getting new upstream
[10:23] <cjwatson> Package: ubiquity
[10:23] <cjwatson> Task: kubuntu-live, edubuntu-live, xubuntu-live
[10:23] <Company> it's just really annoying because everyone runs into that problem when compiling git
[10:23] <Company> (of swfdec)
[10:23] <pitti> ubuntu-meta-1.58$ grep ubiquity *  -> no result
[10:23] <pitti> cjwatson: ^
[10:23] <siretart> pygi: the debdiff undeprecates the structure struct ImgReSampleContext, AFAIU
[10:23] <cjwatson> pitti: ubuntu-meta hasn't produced a live metapackage since dapper, so that's expected
[10:23] <pygi> siretart, correct behaviour
[10:23] <pitti> ah, ok
[10:23] <cjwatson> the problem is that IS have not applied the germinate changes to drescher that I asked for a while ago
[10:23] <pygi> siretart, tested building package with debdiff, builds fine
[10:23] <cjwatson> I'll nag them
[10:23] <pygi> siretart, according to Company it also should fix the problem
[10:23] <pygi> I'm also after getting swfdec in shape for gutsy
[10:23] <siretart> Company: do you know if that struct has been undeprecated or remove?
[10:23] <siretart> removed upstream?
[10:23] <Company> siretart: it's either removed or undeprecated, no idea - lemme look
[10:23] <Company> http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/avcodec.h?revision=9933&view=markup
[10:23] <Company> removed afaics
[10:23] <pygi> siretart, I'd also discuss how we'll manage the cdrecord/wodim/cdrskin situation, with update-alternatives, ln's and conflicts or what?
[10:23] <siretart> great!
[10:23] <siretart> pygi: I need to leave soon today, I just wanted to quick check my mail. would you mind if we can discuss this tomorrow afternoon?
[10:23] <pygi> siretart, ofcourse, it's mess now anyway :)
[10:23] <pygi> a lot of work
[10:23] <pygi> thanks
[10:32] <evand> I aplogize about the cross post of "One Click Installer" between ubuntu-devel and ubuntu-devel-discuss.  I didn't notice the extra address in the To field before I submitted the approval.  Rest assured I will be much more careful in the future.
[10:41] <jwendell> seb128, still around?
[10:41] <seb128> jwendell: yes
[10:43] <jwendell> seb128, is there any issue with glibc on amd64 related with g_timeout_add() ?
[10:43] <jwendell> do you know?
[10:43] <seb128> glib2.0 you mean?
[10:43] <seb128> not that I know, no
[10:43] <jwendell> yeah, glib 2.14
[10:43] <jwendell> seb128, bug 129843
[10:43] <ubotu> Launchpad bug 129843 in vino "vino-server crashed with SIGSEGV in g_main_context_dispatch()" [Medium,New]  https://launchpad.net/bugs/129843
[10:43] <jwendell> seb128, i'm unable to reproduce it here, and everything (on code) seems to be ok...
[10:49] <seb128> jwendell: might be a corruption, I can ask for a valgrind log if you want
[10:49] <jwendell> seb128, it would be nice
[10:49] <jwendell> seb128, also, bug 128842 seems not to belong to vino, right?
[10:49] <ubotu> Launchpad bug 128842 in vino "vino-session crashed with SIGSEGV in ubuntulooks_draw_arrow()" [Medium,New]  https://launchpad.net/bugs/128842
[10:50] <seb128> jwendell: not really, no
[10:51] <seb128> jwendell: I've asked questions on it
[10:51] <jwendell> seb128, thanks
[10:52] <seb128> you're welcome
[11:07] <mikmor2> I have an rc script S20foo that I want to execute before S70x11-common,
[11:07] <mikmor2> Is there a way to force my script to be executed atomically?
[11:15] <pygi> your new tracker stuff crashes like crazy, thank you very much xD
[11:15] <mikmor2> ah.. nevermind
[11:15] <Chipzz> infinity: if you're working on mysql, would you consider splitting the test-cases off in a seperate package; the mysql-server package is obscenely big, and splitting out the tests would reduce its size significantly (I've been wanting to file a bug about this, but I keep postponing it)
[11:16] <seb128> doko: why did you subscribe ubuntu-archive to bug #124778 ?
[11:16] <ubotu> Launchpad bug 124778 in expat "linux grashed" [Undecided,New]  https://launchpad.net/bugs/124778
[11:16] <Chipzz> grashed? heh :)
[11:17] <mathiaz> Chipzz: you'd better file a bug so that we can keep track of your request.
[11:22] <Chipzz> mathiaz: I know, I'm aware of that ;) like I said, I keep postponing/forgetting, but I do intend to file a bug :)