[12:02] <tseng> http://www.oxygen-icons.org/?cat=3
[12:03] <tseng> oh hey what does that top row of icons look like to anyone?
[12:03] <tseng> (and yes that is flamebait)
[12:03] <HiddenWolf> BenC, bull, it's just the easiest for linguisticly challenged nerds to brag about. ;)
[12:04] <HiddenWolf> I know C is something they first learned in pre-school. :)
[12:07] <Stormx3> Back
[12:07] <Stormx2> Stupid internet.
[12:10] <Keybuk> elmo: please sync autofs, all Ubuntu changes are in the Debian package
[12:17] <Keybuk> elmo: also please sync dsdo
[12:17] <HiddenWolf> poor elmo
[12:17] <HiddenWolf> he's being worked to exhaustion.
[12:20] <Keybuk> yeah, those buttons are hard work to push :p
[12:35] <Keybuk> elmo: and htmldoc
[12:35] <Keybuk> (was rebuild only)
[12:36] <Simira> Nafallo : I keep getting you @ubuntu.com mail in return
[12:37] <BenC> we _should_ get a ppc build out of this one
[12:37] <Nafallo> Simira: oh? nafallo@ ?
[12:37] <BenC> doko_: ping
[12:37] <Simira> Nafallo : that's it
[12:38] <BenC> doko_: FYI, I had to use gcc-3.4 for ppc64, so it ain't dead yet
[12:38] <Nafallo> Simira: you might want to try later, seems all mail I'm getting now are from several hours ago. might be something odd happening somewhere :-/.
[12:39] <Simira> Nafallo : It's the second time I got it
[12:40] <Nafallo> Simira: does it give a reason?
[12:40] <HiddenWolf> BenC, do you have a massively interesting changelog for us? :)
[12:40] <Simira> Nafallo : found it. It's rejecting my "@localhost.localdomain" address :p
[12:41] <Nafallo> lol
[12:41] <Nafallo> same as I had when I tried to send to you before ;-)
[12:49] <Simira> Nafallo : but you did get the other mails, right?
[12:49] <Nafallo> Simira: to magicalforest.se? yes :-)
[12:53] <Nafallo> :-)
[12:53] <Simira> Mithrandir : you.... feel.... sleepy ... 0_0
[12:54] <Nafallo> hmm
[12:54] <Nafallo> that worked on me
[12:54] <Keybuk> elmo: and pxlib (debian took our changes)
[12:55] <Keybuk> and reiser4progs (gcc 4 change taken by debian)
[01:00] <HiddenWolf> that shadow upload fixes 66 bugs in debian?!?
[01:02] <Nafallo> Keybuk: yay! 24h to faster boot ;-).
[01:05] <Nafallo> infinity: ping
[01:06] <Keybuk> elmo: and finally, can you sync zope-debhelper -- not sure why that was even an ubuntu rev
[01:06] <Nafallo> infinity, lamont-away: could one of you look if there is a dep-wait on plib and clear it please? :-)
[01:07] <Keybuk> Nafallo: well, maybe 24h
[01:07] <Keybuk> just been doing some merges
[01:07] <Nafallo> Keybuk: you still rock :-)
[01:08] <HiddenWolf> Keybuk, what's in 24h?
[01:08] <Nafallo> "I'm currently working on a total rewrite of the hardware detection stuff
[01:08] <Nafallo> that should hit the archive within the next 24 hours or so"
[01:08] <Nafallo> :-)
[01:09] <HiddenWolf> Nafallo, which could also mean total breakage. ;)
[01:09] <Nafallo> that's why I run dapper
[01:09] <Keybuk> oh, it'll break everything, muahahaha
[01:10] <Nafallo> it can be exciting ;-)
[01:10] <Keybuk> well, it'll break anyone not running 2.6.15
[01:10] <Keybuk> talking of breaking things ...
[01:11] <daniels> HiddenWolf: 'could'?
[01:13] <HiddenWolf> daniels, well, I'm giving him some credit. ;)
[01:13] <HiddenWolf> daniels, could is the polite version of "shall certainly" in this case. ;)
[01:13] <Keybuk> I am, after all, rewriting it all in Java
[01:14] <Nafallo> ;-O
[01:14] <Nafallo> boot-time: 5h :-P
[01:16] <daniels> Keybuk: dude, what about flash?
[01:19] <Nafallo> wow
[01:19] <Keybuk> Nafallo: nothing unusual in yours
[01:19] <Keybuk> looks pretty much like a stock dapper, without the silly ski-slope xfs produces for readahead
[01:19] <Nafallo> nope, not yet anyway :-)
[01:20] <Nafallo> I use ext3 :-)
[01:21] <Keybuk> shame you don't have earlier, as it'd be interesting to see how much of a speed-up you got from depmod (if any)
[01:21] <Keybuk> removal of depmod, that is
[01:21] <Nafallo> I think I installed right after reading your mail about it :-)
[01:22] <Nafallo> anyway, any new features will be shown in there ;-)
[01:22] <Keybuk> yeah
[01:34] <lamont-away> Nafallo: just passing through, but see http://people.ubuntu.com/~lamont/buildLogs/Lists/dapper.all.$arch
[01:35] <Nafallo> lamont-away: oki, thanx
[01:35] <Nafallo> yepp, dep-waits
[01:35] <Keybuk> elmo: please sync analog (change taken by Debian)
[01:35] <Nafallo> needs to be cleared.
[02:03] <infinity> Nafallo_away : Cleared.
[02:07] <elmo> Keybuk: all done
[02:07] <Keybuk> elmo: thanks
[02:08] <Keybuk> disregard the /msg ping too ... I was gonna ask whether you had some fancy "find the orig" script, because my "generate a changes file" thing had a typo in it and I wasn't including them for the first few I did this evening
[02:08] <Keybuk> but then realised that they'd all only been revision changes
[02:16] <Keybuk> elmo: you missed reiser4progs
[02:17] <elmo> oh, you didn't prefix it with elmo, so it wasn't highlighted.  done anyway
[02:17] <tseng> elmo: you tell him
[02:45] <devint> hey gang
[02:46] <devint> well, i'm trying my hand at my first ubuntu application, and i was wondering what package do i install to get the gnome headers like gnome.h? gnome-dev doesn't seem to work
[02:47] <bob2> packages.ubuntu.com allows you to search by filename
[02:47] <bob2> as does apt-file
[02:49] <doko_> BenC: that should be fixed with the next 4.0 upload
[02:52] <Evaso> hi guys any gnome team here?
[02:54] <HiddenWolf> Evaso, #ubuntu-desktop
[03:48] <Bicchi> what do i need to install to be able to use gtkmm in ubuntu? 
[03:55] <sajd> libgtkmm-2.4-dev
[03:55] <Bicchi> got that allready
[04:09] <devint> can somebody please tell me where i can find a tutorial to install the gnome development headers like gnome.h and glide.h?
[04:13] <devint> gnome.h: No such file or directory
[04:13] <devint> why am i getting that?
[04:31] <Keybuk> BenC: ping?
[04:32] <Keybuk> elmo: please sync pxlib
[04:34] <elmo> Keybuk: huh?  I already did
[04:35] <Keybuk> hmm, the changes didn't show up so thought I must've missed that
[04:35] <Keybuk> or is the list server just being slow?
[04:37] <elmo> dunno, but madison says there's a non-ubuntu version in dapper
[04:37] <Keybuk> ok
[04:41] <BenC> Keybuk: ping
[04:42] <Keybuk> BenC: it seems that the "standard" place for firmware to live has changed
[04:42] <Keybuk> I just noticed that the new udev looks in /lib/firmware rather than /lib/hotplug/firmware
[04:42] <BenC> ah
[04:43] <BenC> Keybuk: that may be a driver trying to be specific about the location
[04:43] <BenC> or is that coded somewhere else?
[04:43] <Keybuk> it's coded
[04:43] <sajd> is the updated 2.6.15-3.3 only for amd64 or are the i686 debs just lagged ?
[04:43] <Keybuk> we could always just keep using the old path
[04:44] <BenC> sajd: lagged
[04:44] <sajd> ok
[04:44] <BenC> sajd: it's done building, just has to make it's way into the archive
[04:45] <sajd> cool
[04:45] <Keybuk> wanted your opinion on which is the best idea, updating to the "new" path or just keep using the old one
[04:45] <BenC> Keybuk: makes no difference to me
[04:45] <BenC> changing it would require changes to kernel-wedge I think
[04:45] <BenC> kernel-wedge or make-kpkg, not sure which one
[04:46] <Keybuk> most HOWTOs seem to be being slowly updated to the new path, so it might make sense for us to make that change too
[04:46] <Keybuk> or it might make sense to make that change later
[04:48] <BenC> if we're going to do it, now's the time :)
[04:48] <Keybuk> yeah
[04:49] <Keybuk> we're already dropping /usr/lib/hotplug/firmware and /usr/local/lib/hotplug/firmware too
[04:49] <Keybuk> so maybe now is the time to just change all the paths :)
[04:49] <BenC> let's make it happen then
[04:50] <Keybuk> I can see it being used in kernel-wedge
[04:51] <Keybuk> ok, fixed the one :)
[04:52] <Keybuk> nothing in kernel-package about it
[05:00] <Keybuk> BenC: linux-source-2.6.15-2.6.15/debian/post-install has a bunch of references too
[05:00] <Keybuk> I'll let you change those
[05:00] <BenC> Keybuk: ok, I'll take care of those
[05:04] <sajd> the boot-splash was known to be broken right?
[05:06] <mdz> yes
[05:08] <sajd> booted fine on my ThinkPad T41, had to revert tho since i need the madwifi drivers :/
[05:18] <shadeofgrey> hey has anybody seen hidde recently?
[06:13] <infinity> keybuk, benC : l-r-m is waiting on the new xorg to actually build, which is waiting on the next glibc upload.
[06:13] <daniels> and the next glibc upload is waiting on new binutils.
[06:16] <daniels> (new binutils upstream, at that.)
[06:32] <pitti> Good morning
[06:42] <crimsun> just a note: if you use 2.6.15-3.3 and wpasupplicant in dapper with ipw2200, you should modify /etc/default/wpasupplicant to use the wext driver (options="-Dwext") instead of the ipw driver.
[06:47] <Lathiat> hrm whys that
[06:48] <Lathiat> ipw got merged and fixed to use wext?
[06:48] <crimsun> ipw is now in-kernel, yes.
[06:49] <Lathiat> i assume wext = wireless extensions
[06:49] <crimsun> yep
[08:00] <JaneW> **Reminder**  Dapper Development Status Meetings in #ubuntu-meeting in 1 hour.  
[08:14] <Keybuk> Rejected: linux-wlan-ng_0.2.2+dfsg-6ubuntu1.dsc refers to linux-wlan-ng_0.2.2+dfsg.orig.tar.gz, but I can't find it in the queue or in the pool.
[08:14] <Keybuk> ^ Anyone want to own up? :)
[08:16] <crimsun> hmm, main package, not me. :-)
[08:25] <minghua> Is there any plan about the libfreetype6 ABI change problem?
[08:25] <minghua> At least the shlib version should be bumped
[08:29] <fabbione> **Reminder**  Dapper Development Status Meetings in #ubuntu-meeting in 30 minutes.
[08:33] <mdz> morning
[08:37] <mdz> marilize: hey, your UBZ photos are not on the wiki yet
[08:40] <marilize> mdz: hi babes, yes, i know, i have it on F-spot, but i was just trying to figure out how to download everything at once to flickr...
[08:41] <fabbione> hey mdz
[08:50] <pitti> elmo: texinfo sync,  please
[08:50] <pitti> Hi dholbach 
[08:50] <dholbach> good morning, hi pitti
[08:51] <seb128> hey dholbach
[08:51] <seb128> pitti: hi too :p
[08:51] <pitti> Hi seb128 
[08:52] <pitti> dholbach, seb128: plesae do not set syncable merge bugs to pending
[08:52] <seb128> pitti: I had a good question for a french translator yesterday
[08:52] <pitti> dholbach, seb128: I set them to ACCEPTED now and change the bug title to make it searchable
[08:52] <pitti> PENDING will confuse MOM
[08:52] <dholbach> pitti: i see
[08:52] <dholbach> pitti: thanks for clarifying :)
[08:52] <seb128> pitti: is there any plan to roll language-pack candidates before the stable monthly update? So translators can play with them and squash some ugly typos and stuff?
[08:53] <pitti> seb128: hrmnnngpokecarlos
[08:53] <seb128> pitti: ACCEPTED doesn't really match my workflow
[08:53] <pitti> seb128: rosetta export is disabled ATM
[08:53] <pitti> seb128: mine neither
[08:54] <Keybuk> pitti: I would've thought PENDING is perfect
[08:54] <pitti> seb128: but if you accept the bug and change the title to 'package foo can be synced', it is not too ugly
[08:54] <seb128> hi Keybuk
[08:54] <pitti> Keybuk: but MOM files a new bug when one is pending
[08:54] <Keybuk> though I guess that's me thinking if a new version comes in, it might make you rethink the "yeah, sync it" thought
[08:54] <mdz> marilize: a likely story!
[08:54] <seb128> pitti: no, but PENDING is made for that ..
[08:54] <pitti> seb128: I know, but MOM doesn't
[08:54] <Keybuk> does elmo actually read Bugzilla anyway?
[08:54] <seb128> teach to MOM
[08:55] <Keybuk> he bitched at me earlier when I assigned some merge bugs to him that needed syncing :p
[08:55] <pitti> Keybuk: no, it is just to remind me to request syncs
[08:55] <pitti> Keybuk: so I keep requesting them until they are actually done (then I close the bug)
[08:55] <seb128> Keybuk: I would say no, I've reassigning a bug for a package removal and pinged him on IRC 3 month later since the package didn't got removed :p
[08:55] <seb128> same for me
[08:55] <pitti> Keybuk: I just search for 'sync' and get a package list that I push to elmo
[08:56] <Keybuk> ah, I use the status whiteboard for that
[08:56] <seb128> dholbach put PENDING when he ask for a sync and close when the package has built correctly
[08:56] <Keybuk> I was quite amused yesterday while doing merges
[08:56] <seb128> which is a slightly different usecase :)
[08:56] <Keybuk> I'd forgotten just how much mom's output was optimised for my workflow <g>
[08:57] <fabbione> 3 minutes to meeting
[08:57] <Keybuk> made me wonder how everyone else processes them, and whether they've adopted something similar to mine, or come up with different ways of doing it
[08:57] <pitti> Keybuk: I used pending, but then we had that big confusion with several bugs about a package
[08:58] <seb128> I put PENDING when I ask to elmo on IRC
[08:58] <seb128> I don't close them because he's not always around and sometimes I've to ask again
[08:58] <seb128> this way it's clear the bug is beeing worked, and it's easy for me to know what bug should be fixed now
[08:58] <pitti> seb128: that's what I mean, pending won't be respected by mom, she will file a new bug on further changes
[08:59] <fabbione> *** 1 MINUTE ***
[08:59] <Kamion> Keybuk: maybe in that -devel-announce post you might like to emphasise *why* you've made that change ...
[08:59] <seb128> teach to it
[08:59] <marilize> mdz: ja ja, whatever, will let you know when its done! I
[08:59] <Keybuk> Kamion: which post?
[08:59] <Kamion> Keybuk: the MOM -MERGE change
[08:59] <Keybuk> the one I quickly deleted out of the queue again? :p
[08:59] <Kamion> heh
[08:59] <Keybuk> because it didn't work
[09:00] <Keybuk> making invalid source packages means mom can't produce debdiffs <g>
[09:02] <mdz> BenC: development meeting is beginning on #ubuntu-meeting right now
[09:26] <Kamion> pitti: so ca-certificates is required for libcurl3 nowadays:
[09:26] <Kamion> +  * Started using the system-wide CA certificate file (closes: #308514).
[09:26] <pitti> Kamion: saw it, should not be a problem, but I'll take a look at it
[09:26] <Kamion> pitti: is this a relatively non-crackful thing for main?
[09:26] <Kamion> ok, thanks, we need this sorted out today one way or the other
[09:26] <pitti> Kamion: I'll clean up anastacia today
[09:27] <pitti> Kamion: a bunch of well-known CA certs is certainly worthwile for main; I wonder whether Firefox has its own copy?
[09:27] <Burgundavia> Keybuk, NM and atheros don't like each other?
[09:27] <seb128> pitti: uploading 0.9 package would require some packaging work, NEW process, Conflicts/Replaces, etc
[09:27] <pitti> seb128: no, not uploading, just for me
[09:27] <Burgundavia> Keybuk, only on resume from hibernation I have found
[09:27] <seb128> pitti: the Debian maintain has decided to wait for 0.10 to upload, first week of december
[09:27] <pitti> seb128: but it's not that urgent
[09:28] <seb128> pitti: hum, I can probably get you that next week
[09:28] <pitti> seb128: I have lots of other stuff to play with, so never mind
[09:28] <Kamion> pitti: we can ask Diziet when he wakes up
[09:29] <Kamion> Keybuk: udev> intersection of Debian and SuSE rules, not union?
[09:29] <pitti> Keybuk: now that we have 2.6.15 to play with, what's the plan with uploading udev?
[09:29] <pitti> Keybuk: I also need to update hal for the new kernel
[09:29] <pitti> and we should get these changes in pretty early IMHO
[09:35] <pitti> infinity: speaking of mass-rebuilds, we finally have openssl 0.9.8 in dapper main; do you have a clever script to do the mass rebuild?
[09:36] <sivang> Good morning
[09:39] <pitti> Hi carstenh 
[09:40] <pitti> moin carlos 
[09:40] <pitti> carlos: is rosetta export running again?
[09:40] <carlos> pitti, not yet
[09:41] <carlos> I will try to fix it later today
[09:41] <carlos> with latest version of our codebase
[09:42] <carstenh> hi pitti 
[09:44] <pitti> mvo: https://launchpad.net/distros/ubuntu/+spec/language-pack-vs-support requires changes to the lang selector - how many dev days do you estimate for that?
[09:46] <mvo> pitti: please ping me again after the meeting, I'm not sure about the scope of the changes
[09:46] <pitti> mvo: it needs to additionally install openoffice.org-l10n-lang etc. for translation support
[09:47] <Keybuk> Kamion: uh, did I answer your question before my ISP decided to explode?
[09:47] <seb128> pitti: one of the current installability issue is libcurl3 Depends on ca-certificates which is universe, are you working on it?
[09:48] <Burgundavia> Keybuk, did you get my comment about atheros and NM?
[09:48] <seb128> it breaks vorbis-tools, openoffice2.org and probably some other stuff
[09:48] <pitti> seb128: that's anastacia covered, will do it today, and work with Kamion
[09:48] <Kamion> Keybuk: no
[09:48] <Keybuk> Burgundavia: what was your comment?
[09:48] <pitti> seb128: I don't expect any problems for main
[09:48] <seb128> pitti: what is anastacia?
[09:48] <mvo> pitti: if that is all, it shouldn't be more than a day (at most)
[09:48] <Kamion> seb128: http://people.ubuntu.com/~mdz/anastacia.txt
[09:48] <pitti> seb128: http://people.ubuntu.com/~mdz/anastacia.txt
[09:48] <pitti> oops
[09:48] <seb128> thanks
[09:48] <Burgundavia> Keybuk, NM works for me on initial boot but fails on resume from hibernate (on wireless that is)
[09:48] <Kamion> seb128: automatic report of inconsistencies between germinate output and the actual contents of main/universe
[09:48] <seb128> I look on http://people.ubuntu.com/~cjwatson/testing/dapper_probs.html usually
[09:48] <Kamion> seb128: both are useful
[09:49] <Burgundavia> Keybuk, that the problem you are referring to?
[09:49] <pitti> that's installability
[09:49] <Keybuk> Burgundavia: Atheros can't do a scan and hold on an AP ... so every 30s when NM does an essid scan, atheros cards forget their essid/ap/key settings and drop off the network
[09:49] <Burgundavia> hmm, never seen that
[09:49] <pitti> seb128: anastacia evaluates main vs. universe inconsistencies
[09:49] <seb128> pitti: yeah, I though that installability what was matter to roll a CD :)
[09:49] <Kamion> anastacia-reported inconsistencies often lead to uninstallability, but sometimes to unbuildability
[09:49] <seb128> pitti: gotcha, thanks
[09:49] <Keybuk> Kamion: there's strange crack in the names outside of the intersection ... names randomly assigned for no noticeable reason, I figure the intersection is a sane base and then decide to rename things later
[09:49] <Kamion> seb128: it's kind of like fixing symptoms versus causes, depending
[09:49] <Kamion> Keybuk: hm, ok
[09:50] <Keybuk> like /dev/umad => /dev/infiniband/0
[09:50] <Keybuk> things we don't have explicit NAME= rules for just get the default kernel-assigned name
[10:01] <minghua> dholbach: ping
[10:01] <dholbach> minghua: pong
[10:01] <mvo> pitti: this "sudo test thing" can probably solve a few issues we have with gksudo as well, right?
[10:02] <minghua> dholbach: do you plan to do anything about libfreetype6?
[10:02] <pitti> mvo: might be
[10:02] <Kamion> doko: is hplip ok for main? anastacia wants to promote it, it just needs an "ok" not a report
[10:02] <mvo> pitti: like testing before the run if the user actually has to type a password
[10:02] <minghua> dholbach: at least bump the shlib version?
[10:02] <pitti> mvo: no, that won't work
[10:02] <pitti> mvo: sudo -t will never ask for a password
[10:02] <minghua> dholbach: it really should be renamed to libfreetype6a or something
[10:02] <pitti> mvo: oh, wait, you mean for the 5 minute ticket? I thought it already does that?
[10:03] <Kamion> doko: if so, we'll also end up pulling qt into desktop, which is suboptimal
[10:03] <Kamion> however it may be better than no CD build
[10:03] <dholbach> minghua: i will talk to the debian maintainers... i'd really like to be in sync with them
[10:03] <mvo> pitti: right now we don't deal with NOPASSWD in sudoers well, I was wondering if that change could help us here as well
[10:03] <Keybuk> isn't a "sudo test" an absolutely gaping security hole that would allow any user process to spin testing sudo until the user enters a password, then exploit it while the ticket is till open? ...
[10:03] <mvo> pitti: but apparently not :/
[10:03] <Kamion> Keybuk: it could do that anyway
[10:03] <minghua> dholbach: okay, thanks
[10:03] <pitti> Keybuk: the only thing 'sudo -t command' does is to check whether the user has the privilege to do so
[10:03] <doko> Kamion: Mithrandir did want to look at it today, but temporarily adding it might be ok as well (if space permits)
[10:04] <Keybuk> Kamion: true, but it'd show up a lot in the log
[10:04] <pitti> Keybuk: it's the same as trying 'sudo command' right away
[10:04] <seb128> minghua: there is not a lot to do, we probably don't want to diverge from Debian for something like that
[10:04] <minghua> dholbach: I'm keeping libfreetype6 hold here in my dapper, hoping to catch anything wrong
[10:04] <Kamion> Keybuk: we could make sudo -t log too, if it doesn't already
[10:04] <pitti> Keybuk: (but without a password)
[10:04] <Kamion> although I guess that'd be a lot of log noise
[10:04] <Keybuk> pitti: does it show up as an intrusion in the log if the user doesn't have privilege?
[10:04] <Kamion> (for menus)
[10:04] <pitti> Keybuk: and the spin testing is already there
[10:04] <seb128> minghua: what is wrong with the new version? you use .app applications?
[10:04] <pitti> Keybuk: no
[10:04] <minghua> seb128: I understand it's a Debian problem
[10:04] <Keybuk> see, that's what worries me
[10:04] <infinity> pitti : Yeah, but we already have "sudo -l" which won't tell you what you are allowed to run until AFTER you're authenticated.  Surely, there must have been a reason for that.
[10:04] <Keybuk> otherwise you may as well just make sudoers readable by everyone
[10:05] <pitti> Keybuk: you can already have a process that ptraces other processes to check whether they can sudo
[10:05] <Kamion> infinity: sudo -l tells you EVERYTHING, sudo -t is just one command
[10:05] <Keybuk> the reason it's not is that you're not supposed to be able to find out whether or not you have permission to do something
[10:05] <pitti> infinity: right, because that would be an information disclosure
[10:05] <minghua> seb128: no, I don't use .app stuff, but Chinese users generally have more unofficial packages installed
[10:05] <infinity> Kamion : Sure, but if what you really want to know is "sudo -t su -", you win. :)
[10:05] <pitti> infinity: but for -t you have to specify the complete command with arguments, so it's not an info disclosure
[10:05] <Kamion> infinity: it's just a logging question though
[10:05] <Kamion> infinity: if sudo -t logs, that's no different from just trying it
[10:06] <seb128> minghua: get those package officially to the distro so we can consider them
[10:06] <minghua> seb128: and now it's hard to tell if the are using a package linked to 2.1.10 while using 2.1.7
[10:06] <Kamion> but we are going to end up with a lot of log noise whenever a non-rootly user logs into GNOME
[10:06] <Keybuk> but sudo foo logs for a reason ... so a sysadmin can tell a user tried to run something they have no privilege to do
[10:06] <Keybuk> shortcutting that seems wrong
[10:06] <Kamion> I dunno, I thought this was better than the previous suggestion in the spec
[10:06] <Kamion> perhaps I was wrong
[10:07] <minghua> seb128: by unoffical I mean both unoffical softwares and unofficial versions
[10:07] <pitti> Keybuk: how should it be dangerous to check whether I can execute something as sudo?
[10:07] <pitti> Keybuk: i. e. why should I log that?
[10:07] <Keybuk> pitti: it allows a hacker to "test" the system for weaknesses
[10:07] <seb128> minghua: that's not a distro issue, you can't expect us to make sure than unofficial software we don't know about work fine
[10:07] <minghua> seb128: some people distribute the same packages in archive but some additional patches
[10:07] <Keybuk> and escape detection
[10:07] <Keybuk> sudo logs for a reason
[10:08] <seb128> minghua: that's their issue imho
[10:08] <minghua> seb128: I'm not trying to make a big fuss about it
[10:08] <infinity> pitti : "sudo -t foo && sudo foo" circumvents your running of "sudo foo" and getting logged for not being allowed.
[10:08] <pitti> Keybuk: true, but in this case it is a weakness that is clearly intended in sudoers
[10:08] <seb128> minghua: if they choose to do that instead of working the distro they have to assume the distro changes
[10:08] <Keybuk> pitti: it's not clearly intended, because sudoers is not world-readable
[10:08] <Keybuk> if you were supposed to be able to find out "for free" who can do what, sudoers would be open to all
[10:08] <pitti> infinity: I'm open for better ideas
[10:08] <seb128> minghua: yeah, just making clear that they have to take responsabilities for what they do
[10:09] <pitti> Keybuk: you won't get a list of commands each user can execute
[10:09] <minghua> seb128: okay, thanks for the explanation
[10:09] <pitti> Keybuk: you can just brute force
[10:09] <Keybuk> pitti: but you may as well
[10:09] <Keybuk> you could just take the password off "sudo -l" for the same effect
[10:09] <infinity> pitti : Sure, but in most cases, you're interested in a pretty specific set of commands (like "su -")
[10:09] <pitti> Keybuk: no, that's not the same
[10:09] <Keybuk> pitti: it is
[10:09] <seb128> minghua: anyway no lib should breaks its ABI without changing the soname, but that's an upstream issue, we don't want to change the soname over Debian/Upstream
[10:09] <Kamion> Mithrandir: is hplip going to be a quick thing, or should I start the process of adding it to desktop?
[10:09] <infinity> pitti : I'm not looking for the user who's allowed to restart apache, but do nothing else. :)
[10:09] <Keybuk> you're not supposed to be able to find out what users can and can't do without trying
[10:10] <seb128> minghua: we would make ubuntu binary uncompatible with those
[10:10] <pitti> Keybuk: sudo -l without password would give you the allowed commands right away
[10:10] <Keybuk> that's like being able to find out whether a username exists on a server using ssh
[10:10] <pitti> Keybuk: whereas with -t you have to find them out
[10:10] <minghua> seb128: yes I understand the "keep sync with upstream/debian" thinking here
[10:10] <Keybuk> instead ssh does the right thing, and pretends the user exists whether it does or doesn't
[10:10] <Keybuk> pitti: for cmd in /usr/bin/*; do sudo -t $cmd && echo $cmd; done
[10:10] <Keybuk> easy
[10:10] <pitti> Keybuk: no
[10:10] <pitti> Keybuk: sudo can be restricted to certain parameters
[10:11] <infinity> pitti : I understand what you're arguing, but if you want root on a machine, you're going to test for a tiny subset of commands at first, and probably find someone who can run one of them.
[10:11] <Keybuk> sure, but in our default configuration, it's not
[10:11] <pitti> infinity: true
[10:11] <infinity> pitti : Which isn't much less information than what you get from -l
[10:11] <minghua> seb128: but a shlib version bump won't cause too much incompatibility, will it?
[10:11] <pitti> infinity: but all we talk about is information disclosure
[10:11] <minghua> seb128: and if debian bumps as well, we can always catch up
[10:11] <pitti> but since we *want* to have a small disclosure in order to get the spec, we have to sacrifice a bit
[10:12] <infinity> pitti : "userbob can run 'su' as root" is pretty good information.  Knowing anything beyond that is pointless. :)
[10:12] <pitti> alternatively I could add logging to sudo -t
[10:12] <Keybuk> I think the spec is wrong if it requires forgoing the entire point of having the security in the first place
[10:12] <pitti> Keybuk: if I add logging to sudo -t, how much would that change?
[10:12] <pitti> Keybuk: IMHO nothing at all
[10:13] <pitti> if an intruder can get root, he can disable/remove the logging himself
[10:13] <infinity> For the average system, it changes nothing.  For the paranoid log hunters, it changes a lot.
[10:13] <Keybuk> if an intruder can get root, you have a bigger problem
[10:13] <infinity> pitti : Remote syslogging, etc.
[10:13] <infinity> pitti : Not everyone logs sudo locally.
[10:13] <pitti> anyway, I can add logging if you want
[10:13] <Keybuk> the point is that it allows me to find out whether an intruder is *trying* to get root, and take appropriate action on the compromised account
[10:13] <pitti> but it would generate a lot of clutter
[10:13] <seb128> minghua: no, shlibs bump would hurt
[10:14] <seb128> s/would/wouldn't/
[10:14] <Keybuk> I'd rather have the chatter than not be able to find out that an account on my server had been compromised and the intruder was trying to use sudo to get root and testing various parts of the system
[10:14] <pitti> infinity: that doesn't really convince me TBH
[10:14] <seb128> minghua: but we should get that done on the Debian side
[10:14] <infinity> And yes, the logs will be nearly useless for "checking to see if I'm being pen-tested" on a graphical system that uses sudo -t all the time. :/
[10:14] <pitti> infinity: if somebody is really that paranoid and reads sudo logs, he will give sudo privs very carefully, otherwise it is just pointless in the first place
[10:15] <minghua> seb128: sure.  I'll probably ping Debian maintainer, then
[10:15] <pitti> Keybuk: k, no problem
[10:15] <Kamion> mm, I'm coming round to Keybuk's POV here
[10:15] <infinity> pitti : True, but this feature is a big gotcha to anyone who's used to sudo's previous behaviour and doesn't know it's been introduced.
[10:15] <Keybuk> even if I didn't think there was any way the intruder could get root, I'd want to disable the account anyway
[10:15] <minghua> seb128: thanks for your time.
[10:15] <seb128> minghua: thanks
[10:15] <Keybuk> not to mention inform the real owner that it's time for them to revoke their gpg/ssh keys, etc.
[10:16] <Keybuk> if you make sudo hide intrusions, you've broken it
[10:16] <seb128> minghua: you're welcome
[10:16] <pitti> Keybuk: why hide intrusions?
[10:16] <infinity> pitti : And, while the logging may be next to useless on a GUI system (with how we're planning to use it), adding this extra sudo option to a server box without logging it would make me very nervous.
[10:16] <Keybuk> pitti: the attacker would use "sudo -t ..." on things rather than "sudo thing" and show up in the log
[10:17] <Keybuk> you'd be letting them test the system and get away with it] 
[10:17] <pitti> Keybuk: but at that time the intrusion already took place?
[10:17] <pitti> anyway, I don't mind adding the logging
[10:17] <Keybuk> pitti: exactly
[10:17] <Keybuk> so I, as a sysadmin, need to disable accounts and stuff
[10:17] <infinity> pitti : Intrusion t othe user account took place, not necessarily root priv elevation.  (knowing how to get into someone's account doesn't necessarily mean you know their password)
[10:17] <Keybuk> but I can't
[10:17] <Keybuk> because the evil pitti decided that sysadmins no longer need to know about suspicious user behaviour
[10:18] <infinity> pitti : So, those hints are very useful for disabling accounts double-time, and then starting an audit.
[10:18] <Keybuk> so that compromised user doesn't show up as doing anything naughty
[10:18] <Keybuk> a user trying to sudo things who isn't allowed _is_ suspicious behaviour
[10:18] <Keybuk> in fact, every time I've seen it, it's been a compromised account
[10:18] <infinity> (or a typo)
[10:18] <Keybuk> (or me typo'ing and showing up in my own logs)
[10:19] <pitti> Keybuk: maybe, but what other chance do we have to find out whether or not an user can execute stuff in the admin menu?
[10:19] <pitti> Keybuk: this is a general goal conflict
[10:19] <Keybuk> pitti: why not just look at the user's groups and hardcode the knowledge of which one "by default" gives admin privileges
[10:19] <pitti> Keybuk: that's not enough
[10:19] <Keybuk> sure it is
[10:19] <pitti> Keybuk: warty did not have the admin group
[10:19] <seb128> Keybuk: we already do that
[10:19] <Keybuk> add it
[10:20] <pitti> Keybuk: and admins can configure sudo differently to not use admin
[10:20] <Keybuk> *shrug* users can do all sorts of silly things to their system, doesn't mean we should support them
[10:20] <pitti> testing for admin group would only cover the default case of Ubuntu
[10:20] <Keybuk> fundamentally breaking the security between root and user is not the solution
[10:20] <pitti> Keybuk: carefully restricting sudo perms is not silly
[10:20] <Keybuk> we only support the default case of Ubuntu
[10:20] <mvo> Keybuk: it will hurt people that run a system that was upgraded since warty, we hadn't had the group back then
[10:21] <infinity> Eventually, we have to give up on warty upgrades.
[10:21] <infinity> It was called warty for a reason.
[10:21] <Keybuk> pitti: it's certainly not sillier than giving attackers a free way of finding out what they can do on a system
[10:21] <pitti> Keybuk: so you mean we should only give people the rough distintion between 'can do everything' and 'nothing'?
[10:21] <pitti> Keybuk: as I said, I can add logging to sudo -t, no prob
[10:21] <Keybuk> I'd rather that than break sudo
[10:21] <mvo> Keybuk: mind if I reassign #19728 to you? it's basicly "please implement dpkg triggers"
[10:22] <mvo> infinity: point taken
[10:22] <Keybuk> mvo: *shrug* I don't do dpkg stuff in Ubuntu -- iwj seems to own that here
[10:22] <infinity> pitti : Logging of sudo -t would make me happy, but this is only because I don't give a hoot about security on most desktop systems.  I doubt everyone will feel the same way.
[10:22] <mvo> Diziet: mind if I reassign #19728 to you? it's basicly "please implement dpkg triggers"
[10:22] <mvo> Keybuk: thanks
[10:23] <pitti> infinity: if you use sudo under X on a desktop, then you already sacrifice more securiy than you could ever lose without sudo logging
[10:23] <infinity> pitti : On a desktop system, where we slam out a billion sudo -t requests all the time, it becomes less effective. :/
[10:23] <infinity> pitti : Fair point.
[10:23] <pitti> infinity: so frankly, I don't care about the desktop case
[10:23] <pitti> but I see your point in using sudo on servers
[10:24] <Keybuk> I couldn't care less whether it logs or not on the desktop
[10:24] <infinity> pitti : For the server case, I'm happy with it logging, it effectively makes sudo -t a more userfriendly way of doing "sudo foo || echo 'damn, it broke'"
[10:24] <Keybuk> it's the server I care about, where sudo is pretty much the standard tool for getting root
[10:24] <pitti> infinity, Keybuk, Kamion: ok, so we agree to add logging to -t and keep the current spec?
[10:24] <infinity> Well, that's three whole people who agree.  Quick, make it log, and upload it!
[10:24] <Keybuk> and I don't see an easy way of breaking sudo on the desktop while leaving it intact on the server
[10:25] <Kamion> as far as the spec goes, I'm happy with either adding logging to -t or (holding my nose) hardcoding the group knowledge
[10:25] <Kamion> sorry, dowledge
[10:25] <Keybuk> why holding your nose?  you're back from Quebec now
[10:25] <infinity> Keybuk : Logging with -t seems to be the compromise you'd want, there.  (nothing changed on the server side, hideously broken on the desktop)
[10:25] <Kamion> if we do the latter we should document why so that somebody doesn't come along later and replicate the same mistake
[10:26] <Keybuk> infinity: yeah, if it logs more than one "test" per login -- there's a gnome-panel bug to fix
[10:26] <infinity> Hardcoding group knowlege is terribly inelegant, I'm fine with "-t", as long as it logs the same way as "sudo foo"
[10:26] <pitti> Keybuk: one test per desktop file
[10:26] <Kamion> Keybuk: there are tests for a couple of different things, so it'll be more like three or four than one
[10:26] <Keybuk> pitti: yeah, that's what I figure it sane
[10:26] <pitti> Keybuk: since somebody might be entitled to run network-admin, but not users-admin
[10:26] <Mithrandir> Kamion: hplip> I think we're going to keep the merge, as Debian has merged and there's just python-qt3 which needs to be put into main.
[10:26] <Kamion> pitti: we should make the panel test once for each general category, for efficiency reasons if nothing else
[10:27] <Keybuk> not one test per desktop file per menu open
[10:27] <pitti> Keybuk: no, of course not per menu open
[10:27] <Kamion> Mithrandir: which means libqt in desktop
[10:27] <Keybuk> 'cause if the panel is re-testing everything every time a menu is opened, a gnome-panel bug of old has reared it's head again :p
[10:27] <Mithrandir> Kamion: we don't want that?
[10:27] <seb128> Mithrandir: what is this ugly hplip stuff?
[10:27] <Kamion> Mithrandir: we've successfully resisted it since warty
[10:27] <infinity> Mithrandir : Prefereably not.
[10:28] <Mithrandir> Kamion: ok, I can just skip building the control panel and stuff?
[10:28] <Mithrandir> seb128: HP inkjet support
[10:28] <Keybuk> you can build it and stick it in a separate package not-in-desktop?
[10:28] <Kamion> Mithrandir: doko said that that was the only interface to that functionality at present
[10:28] <seb128> Mithrandir: I've a menu item for it which start a really ugly dialog saying that I have no HP printer configured
[10:28] <seb128> and just exit
[10:28] <Mithrandir> heh, how.. useful.
[10:28] <infinity> Quite.
[10:29] <infinity> Please, just split the package.
[10:29] <seb128> where I have an HP printer configured ... (Deskjet 930C)
[10:29] <Kamion> we could also downgrade python-qt to a Recommends or Suggests
[10:29] <Kamion> recalling the Debian tech-ctte decision on cardinfo
[10:29] <Nafallo> cli is of as much use as the qt-crap from what I've seen.
[10:29] <infinity> (and remove the .desktop file)
[10:29] <Mithrandir> Kamion: it's still the issue of it installing a desktop file, which it doesn't in Debian, but that's easily fixed.
[10:29] <Kamion> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=119517
[10:30] <infinity> Kamion : Ahh, memories.
[10:30] <doko> Mithrandir, Kamion: that would be possible as well, the core does not depend on qt, and if you don't delete the generated .py files, you don't need the python-qttools as well
[10:30] <Kamion> (page down to the end, it's enormous)
[10:31] <Mithrandir> Kamion: oh, the pcmcia-cs tech-ctte stuff.
[10:31] <Mithrandir> Kamion: yeah, sure, we can demote it and not install the .desktop file?
[10:31] <Kamion> doko: which of the hp-* binaries in /usr/bin/ need python-qt?
[10:31] <Kamion> just hp-toolbox?
[10:31] <seb128> Mithrandir: yes, please drop the menu entry
[10:32] <Kamion> doko: will compileall.py blow up in the postinst if we don't have python-qt?
[10:32] <doko> Kamion: hp-unload and hp-toolbox
[10:32] <Mithrandir> seb128: done.
[10:33] <doko> Kamion: it should not
[10:33] <Kamion> right, settled then
[10:33] <Kamion> Mithrandir: doit :)
[10:33] <seb128> Mithrandir: thanks
[10:34] <Kamion> we might also want to make those tools print a helpful message if python-qt isn't installed
[10:34] <Kamion> they already have an 'if not utils.checkPyQtImport():' that we could trivially piggy-back off
[10:35] <doko> Kamion: I'm assigning a bug report to me about these things, won't do them now
[10:36] <Kamion> doko: it's today-urgent, so if you don't have time, let Mithrandir do it
[10:37] <Mithrandir> I'm doing it _now_
[10:37] <Mithrandir> as in, the changelog is written, I just need to build and test, really.
[10:38] <doko> Kamion: yes, besides the helpful messages in each and every tool
[10:38] <Kamion> Mithrandir: thanks, I'll handle the seed/*-meta changes
[10:39] <Kamion> doko: two tools, per your earlier comment
[10:39] <pitti> infinity: easy - the change involved reverting three patch hunks, easy :)
[10:39] <pitti> hm, yay word duplication
[10:39] <Kamion> and it's a one-liner in each case
[10:40] <ddaa> hey pitti
[10:40] <ddaa> I heard you are the printing guy around.
[10:40] <pitti> wb JaneW 
[10:41] <JaneW> pitti thanks
[10:41] <JaneW> seems like hylafax was causing my problem...
[10:41] <JaneW> I uninstalled and things seem back to normal now :)
[10:41] <ddaa> pitti: just wanted you to know that I have compiled and installed gutenprint-4.99-cvs-whatever from debian testing on breezy, and, well, it appears to just work.
[10:41] <ddaa> Except for the annoyingly long and ugly printer names.
[10:42] <pitti> ddaa: oh, gutenprint is the successor to foomatic, right?
[10:42] <ddaa> successor of gimpprint
[10:42] <pitti> ddaa: I happened to do some cupsys changes, but I'm not really an expert in drivers
[10:42] <ddaa> I'm not too clear how all those bits relate, though :)
[10:43] <ddaa> pitti: well, I though you would be the best person to put that datum into.
[10:43] <pitti> ddaa: so you suggest to replace gimp-print by gutenprint?
[10:43] <ddaa> Now I can get my Epson Stylus CX3650 to work right. (before that, it would not ever use cyan, at all).
[10:44] <ddaa> pitti: well, if you can stick that into dapper, improved printer support is kind of a sensical business feature :)
[10:44] <Kamion> I understood gutenprint was on the merge queue already
[10:44] <ddaa> Then all is fine.
[10:44] <pitti> thanks ddaa!
[10:45] <ddaa> Might be nice to have a backport though.
[10:45] <Kamion> rearranged package names are typically awkward to backport
[10:45] <Kamion> but to some extent that's up to the backports guys, anyhow
[10:45] <ddaa> Kamion: the debian packaging keeps the old name.
[10:46] <ddaa> the only glitch I had was a stray gimpprint-something-data package left around broken after dpkg -i.
[10:46] <Kamion> it ships a lot of *gutenprint* binary packages as well
[10:46] <Mithrandir> Kamion: uploaded.
[10:47] <Kamion> Mithrandir: thank you
[10:47] <Treenaks> didn't they change names?
[10:48] <ddaa> Mithrandir: right, the source package produces a bunch of gutenprint packages and a couple of transitional gimpprint packages.
[10:49] <viviersf> why did you guys deside to make usplash
[10:49] <viviersf> and not to use bootsplash
[10:49] <viviersf> just out of my own curiocity ?
[10:49] <Treenaks> viviersf: because bootsplash is a kernel patch; usplash is all user-level code
[10:50] <viviersf> and that helps why ?
[10:50] <Kamion> viviersf: bootsplash was way too intrusive; for example when we tried it out in August 2004 it broke our installer
[10:50] <Treenaks> viviersf: kernel patches are scary, and likely to break when new kernels arrive
[10:50] <Kamion> in ways extremely non-trivial to work around
[10:51] <Kamion> usplash meant that we could enable it much more selectively, and hack it more easily
[10:52] <Kamion> ddaa: I'm not sure they're entirely transitional - they seem to have real content - but I haven't looked at it in detail and don't intend to do so today. :-)
[10:52] <pitti> mvo: <pinging back after the meeting> 
[10:52] <ddaa> NP, worksforme, just wanted to share experience
[10:52] <Kamion> sure, thanks
[10:53] <pitti> mvo: I don't know the langselector code, but do you think that half a day is enough to get the additional installation of translation packages?
[10:54] <Kamion> seb128: does gnome-panel just need a retry on powerpc/ia64, do you think?
[10:54] <Kamion> checking for CLOCK... configure: error: Package requirements (gtk+-2.0 >= 2.7.1 libgnomeui-2.0 >= 2.5.4 libecal-1.2 >= 0.0.97 libedataserverui-1.2 >= 1.2.0) were not met.
[10:54] <Kamion> ^-- powerpc
[10:54] <pitti> infinity: urgh, now I get an email about each failed sudo -t attempt
[10:55] <seb128> Kamion: let me have a look
[10:55] <Kamion> seb128: OTOH build-deps seem sufficient ...
[10:55] <Kamion> thanks
[10:56] <pitti> JaneW: ok, all my specs but one (which depends on mvo) have time estimates now
[10:56] <JaneW> pitti" awesome thanks, you are a star!
[10:56] <Kamion> infinity: can you give-back curl/powerpc? the build seems stalled
[10:57] <JaneW> pitti: is it dependant on one of mvo's goals or just on mvo in general?
[10:59] <pitti> JaneW: I hope that he can do the language selector changes since its his code
[11:00] <seb128> Kamion: nothing obvious, please give it a retry. If it doesn't work I'll debug (do we have a ppc chroot somewhere?)
[11:01] <Kamion> seb128: davis
[11:01] <Kamion> seb128: retrying, thanks
[11:02] <seb128> np
[11:03] <mvo> pitti: I'll do the changes, no problem. I just need to have a look at the spec again about the scope 
[11:03] <mvo> ^---- JaneW 
[11:03] <pitti> mvo: thank you very much 
[11:04] <JaneW> mvo / pitti: ok thanks
[11:04] <pitti> Kamion: the part of installer which displays the 'download additional language support' needs a string change to point out that this also includes translations for various packages (OO.o, Firefox, and Thunderbird in particluar); shall I file this as a bug?
[11:05] <slomo_> elmo: please sync gtkhtml from debian/unstable... ubuntu changes can be dropped
[11:05] <Kamion> pitti: yes, archive-copier; but I don't like being that specific about distribution details, just file a bug saying it needs improvement to handle that case better
[11:06] <pitti> Kamion: ok, thanks
[11:06] <zyga> morning
[11:12] <Kamion> seb128: could you rebuild epiphany-extensions against libosp4c2, please? (it's currently libosp4)
[11:12] <Kamion> I'll do openjade and openjade1.3
[11:13] <seb128> Kamion: sure
[11:13] <Kamion> thanks
[11:14] <seb128> np
[11:14] <Mithrandir> Kamion: can you grab something else?  I'm looking at it already.
[11:14] <viviersf> Kamion, the installer
[11:14] <viviersf> which part detects windows xp 
[11:14] <Mithrandir> Kamion: seems just to be a rebuild required, though.
[11:14] <viviersf> for mutli boot ?
[11:16] <Kamion> Mithrandir: ok, that and openjade1.3 then; for openjade I suggest you revert to the Debian version
[11:16] <Kamion> Mithrandir: (the libosp C++ transition seems to have been a bit botched in breezy)
[11:16] <Kamion> viviersf: os-prober, with help from the bootloader installer packages
[11:20] <viviersf> thx Kamion 
[11:21] <Kamion> and if somebody could take wv2 (just needs a rebuild against new libgsf, I think?), I'd be grateful
[11:21] <viviersf> btw Kamion thx for the help with generic module loading, it helped allot
[11:21] <Kamion> cool, np
[11:24] <seb128> Kamion: will do wv2
[11:24] <Kamion> ta
[11:26] <seb128> Kamion: wv2 should be synced from Debian
[11:26] <seb128> elmo: please sync wv2
[11:28] <viviersf> hmmm Kamion no package contains : os-prober
[11:28] <Kamion> viviersf: apt-get source os-prober
[11:29] <Kamion> viviersf: do not expect pieces of the installer to be available as .debs
[11:29] <viviersf> nope
[11:30] <viviersf> just forgot to click on the : source packages 
[11:30] <viviersf> tick box :)
[11:31] <viviersf> old habbit of mine
[11:31] <viviersf> when i look for source
[11:31] <viviersf> i download via web
[11:33] <seb128> I'm away for less than 1 hour, bbl
[11:39] <Kamion> pitti: not to are-we-there-yet you or anything, but ca-certificates: are we there yet? :) I've done a first pass over the uninstallables and I think it's the only one that's still a major problem for CD builds
[11:39] <mvo> emacs complains about "Undefinied color" in dapper. does anyone knows a fix?
[11:40] <Mithrandir> Kamion: hmm, openjade1.3 seems fine to me?
[11:40] <Mithrandir> mvo: make it depend on xrgb, possibly.
[11:41] <Kamion> Mithrandir: it depends on libosp4?
[11:41] <mvo> Mithrandir: thanks, but that's installed
[11:41] <Kamion> Mithrandir: oh, powerpc is just out-of-date
[11:41] <Kamion> Mithrandir: in fact everything is out-of-date
[11:42] <Mithrandir> Kamion: ah, ok, and libosp4 still exists.
[11:42] <Mithrandir> (hence not uninstallable)
[11:42] <pitti> Kamion: 'k, rescheduling :)
[11:42] <Kamion> Mithrandir: I've kicked rebuilds
[11:43] <Kamion> infinity: never mind, I've kicked curl, looked stale
[11:43] <Mithrandir> Kamion: so I shouldn't touch openjade1.3 at all?
[11:43] <Kamion> Mithrandir: right, should be fine after a rebuild
[11:43] <Kamion> Mithrandir: I only noticed it because it had a knock-on effect on sgml2x
[11:44] <Mithrandir> Kamion: ok
[11:49] <pitti> Kamion: ok, the package seems highly useful and does not contain any binaries (arch:all)
[11:49] <pitti> Kamion: it creates a whole lot of symlinks in /etc/ssl/certs which might be regarded as clutter, though
[11:49] <Kamion> well, it clearly has an effect on packages' security policy
[11:49] <Kamion> hence asking you :)
[11:50] <Kamion> I'm not bothered about the symlinks per se
[11:50] <pitti> Kamion: it means that packages looking for cert validation will regard certs signed by these CAs as trusted, probably
[11:50] <Kamion> hm, it asks its "new certificates" question at critical priority
[11:50] <pitti> this might not always be intended, though
[11:50] <Kamion> oh, maybe not
[11:50] <pitti> Kamion: I got no questions
[11:51] <Kamion> sorry, was wrong
[11:51] <Kamion> by default it trusts all new certificates
[11:51] <pitti> Kamion: I'd rather disable these symlinks, they make me a bit nervous
[11:51] <pitti> but maybe that's just my wrong gut feeling
[11:51] <pitti> providing these certs to mozilla seems ok
[11:52] <Mithrandir> I'm investigating libapt-front (and tagcoll)
[11:52] <Kamion> so you'd like to change the default for trust_new_crts to "no"?
[11:52] <pitti> but at least I use /etc/ssl/certs for my own certs
[11:52] <pitti> Kamion: I just looked at the pkg for two minutes, I guess I need some more time
[11:52] <Kamion> I think /etc/ssl/certs is the only mechanism it has for providing certificates to applications
[11:52] <Kamion> as the system-wide certificates directory
[11:53] <pitti> it installs certs into the mozilla dir as well
[11:53] <Kamion> I don't see that in the postinst?
[11:54] <pitti> Kamion: but since the package will be installed by default, we should be a bit more careful
[11:54] <pitti> Kamion: oh, might be my fault - I misread /usr/share/ca-certificates/mozilla/ as /usr/share/mozilla/...
[11:54] <Kamion> right, I don't think mozilla looks there
[11:55] <pitti> hmm - so a cert that is signed by one of these CAs will be trusted if the CA is in /etc/ssl/certs probably
[11:55] <Kamion> believe so
[11:55] <Kamion> as I say we can trivially disable that by changing the default to "no", but it will be awkward to transition from that if we change our minds later
[11:56] <Kamion> we could say "yes, but we'll audit the list of certificates before dapper to ensure they're sane"
[11:56] <pitti> Kamion: hm, having these certs from a trusted Ubuntu package might be useful, but I don't know how many people trust Ubuntu packages as well as the certs themselves
[11:57] <Kamion> they're trusting the browser, which we provide
[11:57] <Diziet> mvo: Just seen your activity on 19728 (`defer font cache ...').
[11:57] <pitti> Kamion: or rather, they probably trust our libssl package
[11:57] <Kamion> pitti: right
[11:58] <Kamion> if they build it themselves, they can point it at a different certificates directory (/etc/ssl/certs isn't the upstream default, IIRC)
[11:58] <Diziet> mvo: I agree that triggers (I used to call them hooks) would help with this.
[11:59] <pitti> hm, since very few people will do the maths by hand, it seems that trusting the certs and trusting the libssl package are the same, so we might as well just go your way
[12:00] <pitti> Kamion: ok, so we should check the certs after UVF and sync freezes, I guess
[12:00] <Kamion> pitti: I'm not sure I have "my way" as such, but ok :)
[12:01] <mvo> Diziet: what do you think, is it something hard to add (given that it's not done yet, it seems to be :)
[12:01] <pitti> Kamion: <Kamion> we could say "yes, but we'll audit the list of certificates before dapper to ensure they're sane"
[12:01] <pitti> Kamion: this was what I meant
[12:02] <Kamion> pitti: ok. I've made a note in wiki/UpstreamVersionFreeze
[12:02] <Kamion> pitti: ok to promote, then?
[12:02] <pitti> Kamion: yes, fine for me
[12:02] <Kamion> done
[12:03] <Kamion> (thereby proving that the quickest way to get something into Ubuntu main is to make something crucial depend on it in Debian in a way that's awkward to remove ...)
[12:03] <Diziet> mvo: So yes, I would like to do it.  OTOH I'm not sure what the priority of it ought to be.  I've got a few high priority feature goals on my plate, obviously.  I should probably see how I get on with those first.  Unless you think we can persuade mdz/sabdfl that this is important to sort out.
[12:06] <mvo> Diziet: it would be interessting to measure how much time we could save on a regular install/dist-upgrade by postponing the "ldconfig/fontcache/scrollkeeper" stuff to the end
[12:06] <pitti> jordi: ping
[12:07] <Kamion> yes, for scrollkeeper (it diverts scrollkeeper-update and runs it later)
[12:07] <Diziet> mvo: That's an easy thing to measure: just stub it out for the installation and then run it at the end by hand.
[12:07] <Riddell> seb128: how do you let all malone bugs through to desktop-bugs without having to approve each From address?
[12:07] <zyga> mvo: that's a good idea
[12:07] <Diziet> kamion: Eeeewww.
[12:07] <Kamion> is ldconfig safe to run at the end?
[12:07] <Kamion> Diziet: yep, it's ugly - saves a lot of time though
[12:07] <Diziet> kamion: I'm not sure.  I remember thinking about that the other day.
[12:07] <zyga> also if anyone is looking at the installer
[12:07] <zyga> if you choose non-english locale perl complains alot
[12:07] <Kamion> scrollkeeper-update is O(n^2) to run as-you-go, because it doesn't cache things
[12:07] <Diziet> Well, yes, it would.  I'm not saying it shouldn't have been done.  Just grimacing :-).
[12:08] <zyga> (about missing locale, since it's generated later)
[12:08] <Kamion> zyga: as in, on initial install?
[12:08] <zyga> Kamion: yes
[12:08] <zyga> it's nothing dangerous but it litters the screen alot
[12:09] <zyga> I thing it's safe to default to C until the locale is actually generated 
[12:09] <Kamion> AFAIK we generate the locale before anything interesting is done in /target
[12:09] <zyga> hmm
[12:09] <Kamion> if that's not the case then it's a bug
[12:09] <Kamion> at what point exactly does perl complain, and where are you seeing this?
[12:10] <Kamion> and what version of Ubuntu are you installing?
[12:10] <zyga> Kaminon: I'll install breezy on a spare box today and confirm this, okay?
[12:10] <Kamion> sure
[12:10] <zyga> breezy
[12:10] <zyga> I'm sure it was before the reboot
[12:10] <Diziet> Anyway, I was going to go out this morning to buy a bigger buffer cache.
[12:10] <zyga> in fact, I'll just fetch a spare drive and try it at once
[12:10] <Kamion> zyga: so you saw it in /var/log/syslog or /var/log/messages?
[12:11] <zyga> Kamion: on the third or fourth vt
[12:11] <Kamion> right, same thing
[12:11] <zyga> Kamion: I'll have the answer in a few minutes
[12:11] <Kamion> mvo: I'll probably do the same thing in the installer for fc-cache at some point, too; apparently it has a similar problem
[12:13] <mvo> Kamion: fair enough. having it solved in general would still be cool
[12:13] <Kamion> oh, yeah, absolutely
[12:13] <mvo> :)
[12:13] <zyga> mvo: is there any trgger functionality similar to what rpm has in dpkg?
[12:14] <zyga> so that package A can be notified when package B is installed?
[12:14] <Kamion> naturally the fewer weirdo hacks the installer has to do, the better
[12:14] <zyga> (s/installed/whatever/)
[12:14] <mvo> zyga: not that I know of, but Diziet is probably better to talk to
[12:14] <Kamion> zyga: no, that's the point of this discussion (approximately)
[12:14] <zyga> no no I'm asking because of another thing
[12:15] <zyga> (my locale stuff could be triggered when someone installs/removes a language pack
[12:15] <zyga> it would be trivial to integrate it with existing system this way)
[12:16] <mvo> zyga: there is also a proposal about "classes" in dpkg, that may be more appropriate here
[12:16] <Kamion> language pack maintainer scripts call scripts on install/remove which you could divert and hook into
[12:17] <Diziet> buffer cache> Damn, no, I'm not, because they're not in stock.
[12:17] <zyga> Kamion: actually that's easier :-)
[12:17] <Kamion> it might not be quite as elegant but it's certainly doable without dpkg changes right now
[12:17] <zyga> thanks for the suggestion
[12:17] <pitti> zyga: we will soon modify the locales package to provide more generic hooks
[12:17] <pitti> zyga: right now you have to modify glibc to modify the scripts
[12:17] <zyga> pitti: what?!
[12:17] <Kamion> pitti: no, you can divert the scripts and put other ones in their place
[12:17] <Diziet> zyga: http://www.dpkg.org/Triggers, `Alternative Design' (ie, the one Wiggy and I came up with.)
[12:17] <pitti> Kamion: ah, divert. ok, sorry
[12:17] <zyga> pitti: I thought kamion was talking about postinst postrm or something similar
[12:18] <Kamion> I was
[12:19] <zyga> triggers are badly needed IMHO
[12:19] <Kamion> they've been badly needed for about eight years ;-)
[12:20] <pitti> zyga: you mean hooks?
[12:20] <Kamion> (but people have survived)
[12:20] <zyga> pitti: hook is not a trigger IMHO
[12:20] <zyga> (but in this case it's proably the same topic)
[12:20] <pitti> zyga: right
[12:21] <pitti> zyga: but triggers might eventually be implemented, hooks won't according to Keybuk 
[12:21] <pitti> zyga: ah, k, finished reading backlog now
[12:22] <Diziet> The thing that is described on that wiki page as `triggers' is what I always used to call `hooks'.  What did Keybuk mean by `hooks' ?
[12:22] <Kamion> pitti: could you loosen mozilla-locale-fr's Depends a bit? it looks like they just need to be weakened by dropping the -1, to me
[12:22] <Kamion> unless there's something specific in the packaging that they depend upon
[12:22] <pitti> Diziet: I mean something like /etc/dpkg/postinstall.d
[12:22] <pitti> Diziet: so that you can do actions after installing/removing certain/all packages
[12:22] <Diziet> Oh, that's very lame and doesn't make any sense.
[12:22] <pitti> Kamion: sure
[12:23] <pitti> Diziet: but would be highly useful for some special purposes
[12:23] <zyga> pitti: it could have some uses
[12:23] <pitti> Diziet: apt has hooks, but that's not generic enough since peopl might use dpkg directly
[12:23] <Diziet> Ohhh!  The light dawns.  The apt people did some silly thing so now people want to shove it down the stack.
[12:24] <Diziet> What the wiki calls triggers are the answer to this question, anyway.
[12:24] <pitti> Diziet: how are hooks silly?
[12:24] <Kamion> you have to invoke those extra processes every time no matter what
[12:24] <Kamion> triggers allow being more selective
[12:24] <pitti> Kamion: they have different use cases
[12:25] <Kamion> they have a subset of use cases
[12:25] <Diziet> What Kamion said, and also they can't be done right because the design is incoherent.  In particular the error handling is going to be broken no matter what.
[12:25] <pitti> Kamion: so, a trigger is for things like calling ldconfig, a hook is for cases like 'update desktop translations of these packages from langpack data'
[12:26] <Diziet> The latter can be done with triggers too.
[12:26] <pitti> Diziet: but that requires changing all postinsts
[12:26] <Diziet> No.
[12:26] <zyga> I like the state idea
[12:26] <Diziet> See `Alternative Design', which is what ought to be implemented.
[12:27] <Diziet> Well, the design should be finished first :-).
[12:27] <zyga> installing a package may leave it in the state that says 'needs foo' 'needs bar'
[12:27] <Kamion> argh, curl fails to build on powerpc
[12:27] <zyga> after the instalation you could finish all missing states but I wonder what should happen (or if it's allowed) for states to be dependant on one another
[12:27] <Diziet> Much as this is an interesting conversation, I should go and wade around in firefox some more.  Without my bigger buffer cache, boohoo.
[12:28] <pitti> Diziet: ah, interesting
[12:30] <Mithrandir> I've done tex4ht
[12:30] <pitti> Mithrandir: oh, did you change the kpathsea build dep?
[12:30] <Mithrandir> pitti: yes
[12:30] <pitti> Mithrandir: I was going to do that in 5 minutes, cool
[12:30] <Mithrandir> pitti: it built fine, at least.
[12:31] <Mithrandir> ogra: you have editproducts, right?
[12:31] <pitti> Kamion: m-locale-fr done
[12:31] <zyga> Kamion: installing breezy now
[12:32] <pitti> seb128: ok, so should I hold back the debhelper merge? it is FTBFS right now since it waits for an universe package
[12:32] <pitti> seb128: but you said that it will break many packages due to gconf changes?
[12:32] <pitti> seb128: what's necessary to fix that?
[12:34] <dholbach> pitti: he's away atm
[12:36] <Kamion> pitti: AFAIK we need newer gconf (or some other bit of GNOME) first
[12:37] <Kamion> Mithrandir: 10:20  * Kamion claims tex4ht
[12:37] <Kamion> Mithrandir: (and already uploaded
[12:37] <Kamion> )
[12:37] <zyga> pitti
[12:37] <zyga> pitti: what do you think about patching gconf to use gettext to lookup localized strings?
[12:37] <Kamion> pitti: m-l-fr> thanks
[12:38] <pitti> zyga: hm, /me is not really a gnome expert
[12:38] <zyga> pitti: i18n wise it would be good but I'm not sure about usefulnes of such act
[12:39] <Mithrandir> Kamion: oh well.
[12:39] <Mithrandir> Kamion: didn't you do sgml2x?
[12:40] <zyga> looking at the installer, do you think that adding noatime to all /target locations would break anything?
[12:40] <Kamion> Mithrandir: no, it didn't need changes, it was just openjade*
[12:40] <Mithrandir> Kamion: oh, ok.
[12:41] <Kamion> zyga: I'd rather not, access times are not useless
[12:41] <Kamion> for example popularity-contest cares
[12:42] <zyga> Kamion: just for the installer
[12:42] <janimo> seb128, what exactly are the upcoming gconf changes?thx
[12:42] <seb128> Riddell: we don't send bugs to a list I think, but motu guys do
[12:42] <seb128> janimo: what Debian did
[12:43] <Mithrandir> Kamion: for my cdebconf external widget build stuff, should I spend a little time cleaning it up and upload to dapper?
[12:43] <Kamion> zyga: I don't see a win there sufficient to justify the code
[12:43] <seb128> janimo: splitting the package to get ride of the circular depends, using a new tool to register schemas, moved defaults to /var, use one concatened file
[12:43] <zyga> Kamion: the code is minimal, but noatime could give a significant win in install time IMHO
[12:43] <Kamion> Mithrandir: sure. want me to take care of getting it upstream once it works?
[12:44] <Kamion> zyga: you're welcome to try it out and produce numbers
[12:44] <zyga> Kamion: :>
[12:44] <pitti> Kamion: I'll fix hevea
[12:44] <zyga> Kamion: too bad I didn't time the install 
[12:44] <janimo> ok thanks. IIRC gconf depended on other gnome libs too in breezy, that no longer seems to be true
[12:44] <Mithrandir> Kamion: sure, if you'd like.
[12:44] <Kamion> zyga: the bulk of the installer's work on the target filesystem is after reboot, and we can't special-case that
[12:44] <zyga> hmm
[12:45] <pitti> infinity: is there a way to ensure that debhelper 5.x is not built until we fix gconf?
[12:45] <pitti> infinity: it's currently in dep-wait (or should be at least)
[12:45] <janimo> seb128, any chances gdm upstream be interested in ubuntu debian/pacthes ?
[12:46] <janimo> the power mgmt one specifically
[12:46] <seb128> pitti: the change is
[12:46] <seb128>    * dh_gconf: delegate schema registration the gconf-schemas script,
[12:46] <seb128>      which moves schemas to /var/lib/gconf, and require gconf2 2.10.1-2,
[12:46] <seb128>      where it can be found. Closes: #327209
[12:46] <seb128> 
[12:46] <Kamion> /usr/bin/ld: dynamic variable `_SDA_BASE_@@gssapi_krb5_2_MIT' is zero size
[12:46] <seb128> but we don't have a gconf-schemas script
[12:46] <Kamion> ^-- what's breaking the curl/powerpc build, ugh
[12:47] <seb128> pitti: and the Depends is made for Debian, it Depends on something we already ship without the fix (we have 2.12 they have 2.10, so they bumped to 2.10-something which is already satisfed for us)
[12:47] <zyga> Kamion: how about a trigger ;-)
[12:48] <seb128> janimo: yeah, if they are done correctly
[12:48] <dholbach> janimo: you could point them to the patch in a bug report or better on their list?
[12:48] <janimo> I mean the ones there are already in our debian/patches
[12:49] <Kamion> ah, libkrb53 issue fixed in Debian, will sort that out ...
[12:49] <seb128> janimo: there is a lot of patches here, you can't make a rule for different points
[12:49] <seb128> janimo: some maybe, some not
[12:49] <janimo> ok I mean, have you tried pushing them upstream so far?
[12:50] <pitti>   hevea: Depends: ocaml-base-nox-3.08.3 which is a virtual package.
[12:50] <seb128> janimo: which one?
[12:50] <pitti> in source package: Depends: gs, netpbm(>=2:9.10-1), tetex-bin, ocaml-base-nox-3.09.0
[12:50] <seb128> janimo: again different patches, different situations
[12:50] <pitti> ah, never midn
[12:51] <pitti> infinity: please give back hevea
[12:51] <pitti> Kamion: ^ that should make it installable again
[12:51] <janimo> none iin particular, I was interestred whether there is an ongoing pushing up or the ones we altready have are not upstream material
[12:51] <seb128> pitti: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327209 is the dh_gconf patch we want to revert for the moment
[12:51] <janimo> so I was just curious in general
[12:51] <zyga> Kamion: ping
[12:51] <zyga> Kamion: I've found the bug 
[12:52] <seb128> janimo: again, some are upstream material, some are not
[12:52] <zyga> Kamion: before reboot, preconfiguring packages gives lots of: perl: warning: Setting locale failed.
[12:52] <zyga> LANGUAGE= (unset)
[12:52] <zyga> LC_ALL = (unset)
[12:52] <zyga> LANG= "C.UTF-8"
[12:52] <seb128> janimo: https://wiki.ubuntu.com/DesktopTeam/TODO ... I've listed the hibernate to work with upstream here
[12:53] <zyga> Kamion: locale-gen has kicked in some time after
[12:53] <seb128> janimo: the secure action menu needs a bunch of work and I'm not sure upstream would be interested
[12:53] <Kamion> zyga: locale-gen is meant to be called from a base-installer hook though
[12:53] <seb128> janimo: we have changes from Debian which I don't get why we do this (like not using .profile)
[12:53] <Kamion> zyga: which packages are being preconfigured?
[12:53] <zyga> Kamion: installation-report
[12:54] <Kamion> zyga: ah, probably apt-installed packages are installed before the locales are generated
[12:54] <pitti> infinity, seb128: nevermind, the debhelper dep-wait is already cleared, it fails for a different reason now
[12:54] <Kamion> zyga: minor bug, I won't worry about it too much, but thanks anyway
[12:54] <zyga> Kamion: I'm not sure I understand but I'm glad to help :-)
[12:55] <seb128> pitti: either revert the patch I pointed or wait monday when I'll transition gconf
[12:55] <Kamion> zyga: it's just a slight mistake in the order that things happen in base-installer
[12:55] <Kamion> should be harmless
[12:55] <pitti> seb128: if reverting the patch is fine for you, I'd rather do it now
[12:55] <zyga> I'm still not thru reboot yet
[12:55] <seb128> pitti: go for it
[12:58] <Kamion> pitti: I think infinity might have crashed; I've given-back hevea
[12:58] <pitti> Kamion: ok, thanks
[12:58] <Kamion> (was dep-wait on a virtual package so I can see why it didn't work automatically)
[12:59] <zyga> just a thought...
[12:59] <zyga> if the user has a smp box the installer could add the default -smp kernel 
[12:59] <Kamion> zyga: it does if the kernel is on the CD
[12:59] <Kamion> zyga: it isn't on the CD because we don't have space
[12:59] <zyga> Kamion: ah, I see
[01:00] <Kamion> zyga: this has been discussed a number of times, and we took the explicit decision to go with the current arrangement. However, with our 2.6.15 kernels, the default i386 kernel is SMP-capable.
[01:00] <zyga> 2.6.15?
[01:00] <Kamion> zyga: you can already netboot; http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/current/images/netboot/
[01:00] <zyga> isn't 14 the latest
[01:00] <Kamion> zyga: no
[01:00] <Kamion> it's 2.6.15-rc1 but anyway
[01:01] <Nafallo> 2.6.15-rc1
[01:01] <hunger> Will those kernel debs hit main anytime soon?
[01:01] <zyga> Kamion: someone should add that image to the list available on ubuntu.com
[01:02] <Kamion> zyga: I'm happy with the current arrangement
[01:03] <zyga> Kamion: why, netinst makes lots of sense and it's hard to discover on the website
[01:03] <Kamion> hunger: they're already in main; they'll become the default after Flight CD 1
[01:03] <Kamion> zyga: the installation manual links to them, and I don't want to go through the faff of re-publishing them on cdimage
[01:04] <Kamion> BTW this is netboot not netinst; "netinst" has a specific meaning in Debian which isn't this
[01:04] <zyga> Kamion: I mean, get mini cd, fetch rest from the net
[01:04] <zyga> that's netinst, right?
[01:05] <Kamion> no, Debian netinst CDs include the base system on the CD
[01:05] <hunger> Kamion: Cool! When will the flight CDs get out?
[01:05] <Kamion> hunger: when they're ready
[01:05] <Kamion> hunger: the less people hassle me today, the sooner it'll be
[01:05] <hunger> Kamion: OK, I'll shut up.
[01:05] <Kamion> thank you :)
[01:06] <ogra> Mithrandir, sorry, was afk... nope, i only have editusers
[01:06] <Mithrandir> ogra: ook
[01:06] <ogra> Mithrandir, i think mvo has editproducts
[01:06] <Mithrandir> mvo: do you?
[01:07] <mvo> Mithrandir: yes
[01:07] <mvo> Mithrandir: what do you need?
[01:08] <Mithrandir> mvo: can you make infinity the default assignee for mozilla-thunderbird bugs?
[01:08] <mvo> Mithrandir: yes
[01:09] <Mithrandir> mvo: thanks
[01:09] <pitti> mvo: why did you add 'file' to debhelper's build-depends? it needs to be -indep anyway, but I don't know the reason
[01:09] <Kamion> pitti: that's obsolete, I got joeyh to fix the underlying reason
[01:10] <Kamion> namely that it was running dh_something in debian/rules just to test whether it worked
[01:10] <pitti> ah, thanks
[01:10] <mvo> Mithrandir: it looks like he is already default assignee?
[01:10] <Kamion> dh_shlibdeps I think
[01:10] <Mithrandir> mvo: oh, ok.  Good, then
[01:11] <Kamion> oh, oops. erm, don't bother with the current dapper install CDs, folks
[01:11] <Kamion> they're missing grub because I forgot to 'baz update'
[01:12] <Mithrandir> "ouch"
[01:12] <Treenaks> "oops"
[01:23] <Mithrandir> infinity: any chance you could look at why tagcoll doesn't seem to build?
[01:24] <Mithrandir> it was accepted an hour ago, but doesn't seem to have built yet
[01:24] <Treenaks> m68k? :P
[01:24] <Kamion> misc/tagcoll_1.5-1ubuntu1: Dep-Wait by buildd+terranova [optional:out-of-date] 
[01:24] <Kamion>   Dependencies: latex
[01:24] <Kamion> Mithrandir: I take it I should give that back?
[01:25] <Mithrandir> Kamion: yes please.
[01:25] <ogra> pitti, ping
[01:25] <Kamion> Mithrandir: done
[01:25] <Mithrandir> Kamion: aren't dep-waits supposed to clear automatically?
[01:25] <Kamion> Mithrandir: not if they're on nonexistent packages
[01:25] <Mithrandir> ah
[01:26] <Kamion> i.e. the package never becomes available so they never clear; bear in mind dep-waits are sometimes set on packages not in the building package's explicit dep-wait list
[01:26] <pitti_> Hi ogra 
[01:26] <Kamion> (e.g. toolchain, indirect build-deps, etc.)
[01:26] <Kamion> seb128: the gnome-panel rebuild broke in the same way
[01:27] <Mithrandir> are anybody working on readline4?
[01:27] <Kamion> Mithrandir: those two packages are NBS and will be removed once nothing (build-)deps on them
[01:27] <seb128> Kamion: k, I'll debug that
[01:27] <Mithrandir> Kamion: ah, ok.
[01:27] <fabbione> NBS?
[01:27] <Kamion> not built from source
[01:27] <fabbione> ahh
[01:28] <Kamion> Mithrandir: but no harm going round figuring out what needs to be updated
[01:28] <Chipzz> hmmm
[01:28] <Chipzz> this is bad:
[01:28] <seb128> infinity, elmo: could you install the build-depends for gnome-panel on davis dapper chroot?
[01:28] <Chipzz> adduser: Couldn't parse `/etc/adduser.conf':29.
[01:28] <Chipzz> adduser: Couldn't parse `/etc/adduser.conf':30.
[01:28] <Chipzz> adduser: Couldn't parse `/etc/adduser.conf':31.
[01:28] <Chipzz> adduser: Couldn't parse `/etc/adduser.conf':32.
[01:28] <Chipzz> ...
[01:28] <Chipzz> and a lot more of these
[01:29] <Mithrandir> Kamion: ok, I'll do that, then.
[01:30] <fabbione> seb128: afaik infinity doesn't have chroot powers.. Znarl and elmo do, but the best way is to file an rt request
[01:32] <Mithrandir> Kamion: we want to chuck libreadline4 out completely, right?
[01:32] <pitti> Mithrandir: right
[01:33] <pitti> Mithrandir: most packages will do with a rebuild against 5 (this was true for all packages that I did)
[01:33] <pitti> Mithrandir: however, some might need changes
[01:33] <Mithrandir> pitti: ok, which have you done?
[01:33] <seb128> fabbione: how do rt requests work?
[01:33] <pitti> Mithrandir: postgresql-X.Y, curl, a few others I forgot about
[01:33] <Mithrandir> pitti: ok
[01:33] <Mithrandir> I'm grabbing bc, ftp so far.
[01:34] <fabbione> seb128: just send a mail to rt@admin.canonical.com with what you need done. that's it
[01:34] <seb128> fabbione: thanks
[01:35] <Kamion> Mithrandir: that one isn't urgent so feel free to skip potentially risky ones
[01:35] <Mithrandir> Kamion: ok.  Doesn't seem to be any very risky ones, possibly with the exception of parted and gdb.
[01:36] <pitti> Mithrandir: only 14 packages in main that need 4, that seems manageable
[01:36] <desrt> fabbione; nobody reads that address :)
[01:36] <desrt> fabbione; except for a very polite python script :)
[01:36] <Kamion> Package libebook-1.2 was not found in the pkg-config search path.
[01:36] <Kamion> seb128: ^-- root problem
[01:36] <fabbione> desrt: you wish :)
[01:37] <pitti> Mithrandir: we should watch out for Debian merges
[01:37] <pitti> Mithrandir: e. g. mdbtools was converted to 5 in debian
[01:37] <pitti> Mithrandir: do you want a list of all packages that use 4?
[01:37] <Mithrandir> pitti: "apt-cache rdepends libreadline4" is a good approximation, isn't it?
[01:38] <seb128> Kamion: hum ... 
[01:38] <seb128> grep "libebook" configure*
[01:38] <seb128> $
[01:38] <pitti> Mithrandir: sure, if you can restrict it to main
[01:38] <Kamion> Package 'libebook-1.2', required by 'libedataserverui', not found
[01:38] <Mithrandir> pitti: pbuilder login gives me that.
[01:38] <Kamion> perhaps the relevant -dev should depend on libebook1.2-dev
[01:38] <pitti> Mithrandir: ok, fine for me :)
[01:39] <seb128> Kamion: $ apt-cache show libedataserverui1.2-dev | grep Depends
[01:39] <seb128> Depends: libedataserverui1.2-6 (= 1.5.2-0ubuntu1), libgnome2-dev, libedataserver1.2-dev (= 1.5.2-0ubuntu1), libaudiofile-dev, libbonobo2-dev, libcamel1.2-dev, libebook1.2-dev, libesd0-dev, libgconf2-dev, libgcrypt11-dev, libglib2.0-dev, libgnomevfs2-dev, libgnutls11-dev, libgpg-error-dev, liborbit2-dev, libpopt-dev, libtasn1-2-dev, libxml2-dev
[01:39] <seb128> it does
[01:39] <Kamion> Depends: libedataserverui1.2-6 (= 1.5.1-0ubuntu2), libgnome2-dev, libedataserver1.2-dev (= 1.5.1-0ubuntu2)
[01:39] <Kamion> ^-- on powerpc
[01:39] <seb128> utch
[01:39] <seb128> what version is that?
[01:39] <Kamion> 1.5.1-0ubuntu2
[01:39] <seb128> 1.5.2-0ubuntu1 ?
[01:39] <seb128> ah
[01:39] <seb128> it's outdated
[01:40] <Kamion> good catch, I'll give that back
[01:40] <seb128> [   ]  evolution-data-server_1.5.2-0ubuntu1_20051115-1709-powerpc-given-back.gz 
[01:40] <seb128> k
[01:40] <Kamion> it wasn't, though
[01:40] <seb128> hey, that's weird
[01:40] <Kamion> I don't know exactly what given-back there corresponds to but it seems to require manual action
[01:41] <seb128> can you give it a retry?
[01:41] <Kamion> alrady done
[01:41] <Kamion> +e
[01:41] <seb128> cool
[01:50] <Nafallo> Kamion: could you give-back tipptrainer on powerpc please?
[01:50] <Nafallo> Kamion: and ia64.
[01:51] <Kamion> Riddell: please rebuild koffice against the new imagemagick (libmagick++9-dev)
[01:52] <pitti> seb128: ok, new debhelper uploaded with the gconf patch reverted
[01:52] <seb128> pitti: thanks
[01:52] <pitti> seb128: I tested it with eog, seems to work fine now
[01:52] <seb128> cool
[01:52] <pitti> seb128: please just ping me when gconf is ready
[01:52] <Kamion> Nafallo: done on ia64, but powerpc needs whatever library is responsible for this symbol to be rebuilt first:
[01:52] <pitti> then we can re-applu
[01:52] <Kamion> /usr/bin/ld: dynamic variable `_SDA_BASE_@@WXU_2.6' is zero size
[01:52] <Kamion> (should just need a no-changes rebuild with new binutils, like I just did for krb5)
[01:53] <Mithrandir> Kamion: maybe wx 2.6?
[01:53] <pitti> Mithrandir: oh, mdbtools can be synced, this gets rid of another libreadline4
[01:53] <Kamion> Mithrandir: right
[01:54] <Mithrandir> pitti: don't tell me, tell elmo/Kamion. :-)
[01:54] <Kamion> (probably)
[01:54] <Kamion> check with objdump -T <various libraries> first
[01:54] <Kamion> Mithrandir: s,/Kamion,,
[01:54] <elmo>   mdbtools | 0.5.99.0.6pre1.0.20050409-1.2 |        dapper | source, amd64, i386, ia64, powerpc
[01:54] <elmo> so s/elmo// too :P
[01:54] <Mithrandir> heh
[01:54] <Mithrandir> so it just needs a rebuild.
[01:54] <Mithrandir> actually, it doesn't.
[01:54] <slomo_> elmo: please sync gtkhtml from debian/unstable... ubuntu changes can be dropped as always ;)
[01:54] <Mithrandir> pitti: it's already done
[01:55] <seb128> elmo: wait for gtkhtml
[01:55] <seb128> slomo_: which one is that? the GNOME 1 ?
[01:55] <slomo_> seb128: yes... i won't touch the core gnome2 stuff without asking you ;)
[01:56] <Nafallo> Kamion: ah, oki. that's the way it works :-).
[01:56] <Nafallo> Kamion: thanx
[01:56] <seb128> elmo: k, gtkhtml fine with me :)
[01:56] <elmo> slomo/seb128: done
[01:57] <slomo_> elmo: thanks :)
[01:57] <Mithrandir> seb128: can you or dholbach do gnome-pilot against newer libreadline, please?
[01:57] <dholbach> Mithrandir: i can do that
[01:57] <Mithrandir> dholbach: thanks
[01:57] <slomo_> BenC: will the ppc kernel build failure also be fixed with new binutils?
[01:58] <BenC> I hope so
[01:59] <seb128> elmo: have you done wv2?
[01:59] <seb128> dholbach: go for it
[01:59] <pitti> elmo: can you please sync texinfo?
[02:00] <pitti> Hi jbailey 
[02:00] <elmo> BenC: huh?
[02:00] <jbailey> Heya Martin (and everyone)
[02:01] <elmo> BenC: got a pointer to the problem/patch?
[02:01] <elmo> seb128: no, missed it sorry, done
[02:01] <elmo> pitti: done
[02:01] <pitti> thanks
[02:01] <seb128> elmo: np, thanks
[02:01] <BenC> elmo: problem with ppc64 is a relocation error during vmlinux linking
[02:01] <BenC> buildlogs shows it
[02:01] <BenC> I can disable CONFIG_HMT to get around it for now
[02:02] <pitti> Mithrandir: I'll tackle readline for gdb unless you want to
[02:02] <Mithrandir> pitti: way ahead of you, already uploaded.
[02:02] <elmo> BenC: and is it definitely fixed in newer CVS or do you just hope it is? :)
[02:02] <pitti> k :)
[02:02] <elmo> (asking for the changelog)
[02:02] <BenC> elmo: I just hope :)
[02:03] <elmo> ok
[02:03] <Mithrandir> pitti: start at the other end of the list with quagga, parted, mysql-client and lua50?
[02:03] <slomo_> bbl
[02:04] <viviersf> ffs
[02:04] <seb128> pitti: BTW gconf is not broken, stop saying "fixed gconf", it's just not transitionned yet to a new format :p
[02:04] <viviersf> does any1 know why im having troubles installing grub
[02:04] <pitti> Mithrandir: hm, for dapper we should probably drop mysql 4.0 and go to 4.1
[02:04] <viviersf> from live cd etc ?
[02:04] <Mithrandir> pitti: agreed, and I think infinity would be happy about that too.
[02:04] <pitti> Mithrandir: given that it is already in main...
[02:04] <Kamion> viviersf: what version?
[02:04] <Mithrandir> pitti: especially given that mysql-server (4.0) is broken on ppc
[02:04] <viviersf> version of ?
[02:05] <viviersf> ubuntu ?
[02:05] <Kamion> viviersf: the live CD
[02:05] <viviersf> lol
[02:05] <viviersf> impilinux
[02:05] <viviersf> based on breezy
[02:05] <viviersf> i tried : 
[02:05] <viviersf> grub 
[02:05] <Kamion> well, look in /cdrom/pool/main/g/grub/ to see if it's there
[02:05] <pitti> Mithrandir: k, I fix -4.1 then and check what is necessary to drop 4.0
[02:05] <Kamion> er, no, cancel that
[02:05] <Kamion> check 'dpkg -l grub'
[02:05] <viviersf> heh
[02:06] <pitti> brb
[02:07] <dholbach> i prepare some food... be back later
[02:08] <viviersf> yes Kamion its on
[02:09] <viviersf> i do this :
[02:09] <viviersf> grub
[02:09] <viviersf> root (hd0,0)
[02:09] <viviersf> setup (hd0)
[02:09] <viviersf> quit
[02:09] <viviersf> i get no errors
[02:09] <viviersf> but the thing just dont boot
[02:10] <viviersf> grub-install /dev/hda doesnt work
[02:10] <viviersf> so i dont know what to do
[02:11] <Kamion> viviersf: I'm afraid I'm excruciatingly busy today; if somebody else could help you that would be good
[02:11] <Kamion> you will need to give more details though, "doesn't work" is never very helpful
[02:12] <viviersf> it does not say anything when it tries to boot
[02:12] <viviersf> its just stops before grub loads
[02:13] <viviersf> ajmitch, saw it :/
[02:13] <ogra> whom do i have to poke for initramfs now, was that Keybuk or infinity ?
[02:14] <Kamion> ogra: normally infinity
[02:14] <ogra> oki, hanks
[02:14] <ogra> +t
[02:14] <jbailey> ogra: If you have occasional questions, I'm still following development on it, just not doing it.
[02:14] <jbailey> ogra: (If the timezones work out better that way)
[02:14] <viviersf> ah yes jbailey 
[02:14] <viviersf> dont you know anything bout grub /
[02:14] <viviersf> ?
[02:15] <ogra> jbailey, i just want to get rid of that "sleep 3" in the nfsmount script :)
[02:15] <ogra> its still there and slows down booting thin clients :)
[02:16] <Mithrandir> elmo: please sync pilot-link, ok to override Ubuntu changes.
[02:16] <elmo> err
[02:16] <elmo> pilot-link_0.11.8-10ubuntu4_source.changes
[02:16] <elmo> REJECT
[02:16] <elmo> Mithrandir: so, talk to whoever that is?
[02:16] <Mithrandir> elmo: that was uploaded by me.
[02:16] <Mithrandir> elmo: I didn't look if we needed to merge.
[02:17] <Mithrandir> (sorry)
[02:18] <Kamion> the reject was just for distribution: unstable anyway ...
[02:18] <jbailey> ogra: Sounds lovely.  Wasn't it there so that the network had time to sync up?
[02:18] <Mithrandir> I take that as a sign I should take a break. :-)
[02:18] <elmo> yeah, I know, but it freaks me out when someone says "please sync" at the same time as someone is uploading it
[02:18] <jbailey> ogra: Otherwise a switch may not have actually completed spanning tree and the like.
[02:18] <ogra> jbailey, nope, only for debugging the issue ... 
[02:19] <elmo> done anyway
[02:19] <Mithrandir> elmo: sorry, I should have mentioned it.  Mea culpa et errare humanum est.  And thanks.
[02:19] <ogra> jbailey, its from the time where mdz thought it was a network issue ... 
[02:19] <ogra> it can go safely
[02:19] <jbailey> Ah, okay.
[02:20] <jbailey> infinity is doing the uploads these days, best to email him.
[02:20] <ogra> which we solved by setting the klibc value for nfs mounts right ...
[02:20] <ogra> yup
[02:20] <ogra> i'm not in a hurry ...
[02:20] <jbailey> Clearly you are if 3 seconds is too long to wait... ;)
[02:21] <ogra> heh
[02:21] <ogra> nope, my users are :)
[02:21] <ogra> which falls in your realm now ;)
[02:24] <viviersf> omw
[02:24] <viviersf> im gonna use lilo
[02:24] <viviersf> watch me :/
[02:25] <viviersf> or is there issues with lilo ?
[02:27] <\sh> wtf 
[02:27] <\sh> Get:21 http://archive.ubuntu.com dapper/main qt3-apps-dev 3:3.3.5-1ubuntu1 [2402kB] 
[02:27] <\sh> Get:22 http://archive.ubuntu.com dapper/main sip4 4.3.1-1ubuntu1 [184kB] 
[02:27] <\sh> Get:23 http://archive.ubuntu.com dapper/universe gcc-snapshot 20051112-1 [56.6MB] 
[02:27] <\sh> gcc-snapshot?
[02:27] <viviersf> lo,l
[02:27] <Treenaks> sip? gcc-snapshot phones home?
[02:27] <Treenaks> in the literal sense?
[02:27] <pitti> elmo: please sync mysql-dfsg-4.1
[02:27] <\sh> Treenaks: python-qt3 merge that is
[02:28] <Riddell> sip is qt python binding helper, not phones
[02:28] <\sh> but for what reason I need gcc-snapshot...lets see who pulls it in
[02:28] <Riddell> Kamion: will do koffice along with libstdc++ merge
[02:28] <\sh> grmpf
[02:29] <Treenaks> Riddell: oh, it's not the voip thing?
[02:29] <\sh> Treenaks: no
[02:29] <\sh> Traxer|off: sip4 is just a type of swig for qt stuff
[02:30] <\sh> Treenaks: i mean...not Traxer|off 
[02:30] <Kamion> Riddell: thanks
[02:30] <\sh> and this is somehow horrible
[02:30] <\sh> c++abi2-dev
[02:31] <Mithrandir> I'm grabbing libtunepimp
[02:32] <\sh> doko: when is the new libstdc++ transition happening?
[02:32] <seb128> Kamion: e-d-s build failed, something triger -ldb without having the correct Depends, trying to figure what now
[02:33] <dholbach> \sh: after the first cd is out
[02:34] <doko> \sh: after flight-1
[02:37] <\sh> doko: k..so I should not take any calls from work over the weekend :)
[02:40] <sivang> \sh: you should never take calls from work on the weekend, unless it's FOSS related :)
[02:40] <Kamion> seb128: want any help? it's the last blocker I think
[02:41] <\sh> sivang: well...I'm just a callboy for this company...I'll earn per call between 60 and 80  (only for the call) and after that, they pay all the working time during night or weekends...
[02:41] <seb128> Kamion: I'll let you know, I get a pbuilder with the Build-Depends atm, so I can grep the .la and figure if there is something wrong with them
[02:42] <sivang> \sh: ah then that's pretty cool actually, no?
[02:42] <sivang> \sh: actually, we shoudl probably take this to PM 
[02:42] <\sh> sivang: it's preety annoying...especially then, when I try to sleep...and dreaming about hula girls ;)
[02:42] <Kamion> seb128: ugh, evolution-data-server builds its own internal copy of libdb?
[02:42] <\sh> i'll compile python-qt3 now...time for a smoke
[02:43] <seb128> Kamion: yeah
[02:43] <Kamion> gross
[02:43] <Mithrandir> Kamion: it sucks, yes.  Very much, so.
[02:43] <seb128> I already had this discussion with upstream and pitti
[02:43] <sivang> \sh: lol
[02:43] <Mithrandir> seb128: and me. :-P
[02:43] <seb128> and infinity :p
[02:44] <Kamion> hah
[02:44] <seb128> upstream argue that's the only sane way to make sure it doesn't break if you share your data between different distros
[02:44] <seb128> ie: they are not going to change that
[02:44] <Mithrandir> seb128: the only sane way to make sure it doesn't break between distros is to use something else than libdb :-)
[02:45] <seb128> that too :)
[02:45] <Kamion> seb128: doesn't mean we have to build the built-in one ;)
[02:45] <Mithrandir> we should just patch out the libdb in e-d-s and patch in my tdb backend. ;-)
[02:46] <seb128> Kamion: Debian does use the system libdb, but we had some issue with that when we tried
[02:46] <seb128> didn't want to break it before a stable, we are probably to change that soon since we are early for dapper
[02:53] <seb128> Kamion: the bug comes from kerberos4kth-dev
[02:53] <seb128> /usr/lib/libkafs4.la:dependency_libs=' /usr/lib/libroken.la -ldb /usr/lib/libkrb.la -lcrypt -lcom_err -lcrypto -lresolv'
[02:53] <seb128> /usr/lib/libotp.la:dependency_libs=' -lcrypto /usr/lib/libroken.la -lcrypt -ldb -lresolv'
[02:53] <seb128> /usr/lib/libroken.la:dependency_libs=' -ldb -lcrypt -lresolv'
[02:53] <mvo> elmo: please sync tagcoll from debian (override ok)
[02:56] <jordi> pitti: you might want to consider taking alsa from experimental in dapper
[02:57] <HiddenWolf> jordi, isn't that crimsun's
[02:57] <jordi> HiddenWolf: no idea. it was pitti before :)
[03:00] <elmo> pitti: done
[03:01] <seb128> Kamion: I upload a krb4 with the fix
[03:04] <Kamion> thanks
[03:05] <Diziet> Aargh, now I have to run this script again because I forgot a pair of "".  I really should know better.
[03:06] <Mithrandir> mvo: uhm?
[03:07] <Mithrandir> mvo: the version in Debian doesn't build for us.
[03:08] <Kamion> seb128: (it didn't build from source as it was anyway)
[03:10] <mvo> Mithrandir: there is a new upload that fixes the build problem (#19770)
[03:10] <Mithrandir> mvo: oh, ok.
[03:10] <mvo> Mithrandir: or am I overlooking something here?
[03:10] <Mithrandir> mvo: if there is, then it should be fine.  I just fixed it a few hours ago.
[03:11] <seb128> Kamion: what didn't build from source?
[03:11] <Kamion> seb128: krb4
[03:12] <Kamion> the previous version in dapper, I mean
[03:12] <seb128> oh, k
[03:15] <pitti> jordi: right, that's what I wanted you to ping about
[03:15] <pitti> jordi: did you already use it for some time? is the rc safe?
[03:16] <torkel> isn't it time to start thinking of dropping kerberos4kth? See Debian #315059
[03:16] <pitti> Kamion: I was away for lunch, and dapper_probs.html seems out of date - what's still missing?
[03:25] <Kamion> torkel: on this I think we can happily follow Debian
[03:26] <Kamion> pitti: it was updated pretty much at the point you said that
[03:26] <Kamion> pitti: I think all the remaining pieces are now just waiting for builds
[03:26] <pitti> neat, thanks
[03:26] <Kamion> krb4 -> evolution-data-server -> gnome-panel is about it; the rest is not CD-critical
[03:27] <Mithrandir> elmo: please sync libmusicbrainz-2.1
[03:27] <Mithrandir> (overriding ubuntu changes is ok)
[03:27] <torkel> Kamion: yeah. Hopefully the new heimdal will move to unstable soon and they will drop krb4
[03:28] <Mithrandir> why do we even build with krb4 support?
[03:28] <seb128> torkel: we had the question some time ago to use krb or heimdal, we picked krb ... is that wrong?
[03:29] <pitti> seb128: any chance to use krb5? krb4 is on the list of packages we'd like to kill
[03:29] <seb128> pitti: we use both
[03:30] <seb128> not sure if that's useful, I don't know that enough
[03:30] <torkel> seb128: krb and kerberos4kth are not the same thing
[03:30] <seb128> I've just turned all the option proposed by upstream
[03:30] <seb128>         Kerberos 4/5:     yes/yes (MIT)
[03:30] <torkel> it was kerberos4kth I was speaking about
[03:31] <seb128> torkel: pitti was speaking about krb4
[03:38] <thierry_> I'm doing a bash script, where I edit some files with gedit, I'd like the script to wait that I finished my modifcations before it continues.... how could I do that?
[03:41] <seb128> thierry_: action1 && action2
[03:41] <thierry_> k
[03:42] <torkel> seb128: which of mit krb and heimdal to use is probably just a matter of taste.
[03:42] <seb128> thierry_: action1; action2 too ... depending if you want to continue or not depending of the return of action1
[03:42] <seb128> torkel: we picked the first one so :)
[03:43] <torkel> seb128: :-)
[03:43] <thierry_> seb128 : but the problem is that when gedit open, the terminal think the command is finishied
[03:43] <thierry_> finished*
[03:43] <seb128> thierry_: no
[03:43] <seb128> thierry_: enter "gedit && ls" on a command line
[03:44] <thierry_> gedit just opened and ls displayed before I close gedit
[03:44] <seb128> thierry_: do you already have a gedit running?
[03:44] <thierry_> ho yes... wait
[03:44] <seb128> it reuses the running one in this case and return directly
[03:44] <thierry_> seb128 : cool working! thanks
[03:44] <seb128> np
[03:49] <thierry_> seb128 : just one little last thing : a command give me two lines of output, how can I give a variable to each of them?
[03:50] <thierry_> do I absolutely need arrays?
[03:50] <seb128> what language?
[03:50] <thierry_> bash
[03:50] <seb128> dunno
[03:50] <thierry_> k thanks anyway
[03:51] <sistpoty> thierry_: maybe s.th. like x=$(cmd); x1=$(echo ${x} | head 1); x2=$(echo ${x} | tail 1)
[03:52] <Kamion> you want more quoting there really, i.e. "$..."
[03:52] <Kamion> always put double quotes around $... in shell unless you know why you shouldn't
[03:53] <sistpoty> that's why i wrote s.th. _like_ ;)
[03:53] <Kamion> I'm just trying to encourage good shell before people get into bad habits.
[03:53] <sistpoty> Kamion++ ;)
[03:54] <thierry_> so this should be this : x="$(ls | find $package*.dsc)"; x1="$(echo ${x} | head 1)"; x2="$(echo ${x} | tail 1)" ?
[03:55] <Mithrandir> ls | find?
[03:55] <Mithrandir> that doesn't make very much sense. :-)
[03:55] <thierry_> ho yeah doesn't need ls... sorry
[03:56] <sbalneav> Morning all
[03:57] <sistpoty> thierry_: maybe you'd also quote ${x} in echo... but just try it in bash (I haven't ;)
[04:01] <Kamion> yes, and no point in the {}
[04:02] <Kamion> if you don't quote "$x" then echo and the shell may interpret metacharacters in the value of $x, will collapse whitespace, etc.
[04:02] <thierry_> kamion : yeah that's what I was thinking
[04:02] <Kamion> <cjwatson@cairhien ~>$ foo='a  b  c'
[04:02] <Kamion> <cjwatson@cairhien ~>$ echo $foo
[04:02] <Kamion> a b c
[04:04] <seb128> elmo: I've uploaded alacarte which is a renaming of smeg, can you remove smeg when you accept alacarte?
[04:04] <Kamion> ok, I'm going to have to go in fifteen minutes; I have a prior engagement this afternoon. Looks like I won't be around to start a CD build for some hours
[04:04] <Kamion> please keep the archive working while I'm gone :)
[04:04] <seb128> Kamion: smeg package has been renamed to alacarte, is that ok if I update the seed according to that?
[04:04] <Kamion> seb128: post-flight-1 please
[04:05] <seb128> k
[04:05] <Kamion> but yes, after that
[04:05] <seb128> elmo: don't drop smeg yet so please :)
[04:07] <torkel> fabbione: ping?
[04:08] <Kamion> seb128: krb4 FTBFS in the same way I noticed the old version doing on powerpc
[04:08] <Kamion> /usr/include/openssl/ossl_typ.h:144: error: syntax error before numeric constant
[04:08] <Kamion> make[4] : *** [ftpcmd.o]  Error 1
[04:09] <seb128> Kamion: will look on it
[04:09] <seb128> Kamion: for now I can workaround it with an e-d-s explicit Build-Depends if you want
[04:10] <seb128> let's try to fix it first
[04:12] <Kamion> it's not going to be done before I leave in any case
[04:12] <Kamion> please ping buildd admins to retry evolution-data-server and then gnome-panel if that proves to be necessary
[04:13] <seb128> k
[04:13] <chmj> elmo: bgoffice sync please, ubuntu override ok
[04:14] <thierry_> how can I see by a command if a ubuntu package is unstable or not
[04:14] <Kamion> "unstable"?
[04:15] <Kamion> anyway, #ubuntu please
[04:16] <thierry_> Kamion : yeah in the changelog there's breezy breezy-updates or unstable as distribution
[04:16] <ogra> thierry_, unstable means its synced 1:1 from debian
[04:17] <thierry_> ogra : so when we do updates to this we put it to dapper or unstable?
[04:17] <ogra> thierry_, if you upload to the ubuntu archive it must be dapper ... if it gets synced from debian itstays as is
[04:18] <thierry_> ogra : well I want to apply a patch for dapper, so any unstable package should be dapper?
[04:19] <ogra> any package you touch and upload must be dapper ... 
[04:19] <thierry_> ogra : and sending a patch to malone is like uploading?
[04:20] <ogra> nope
[04:20] <ogra> a maintainer has to review it, add it and upload it
[04:20] <ogra> in the end there is uploading involved in this process indeed
[04:21] <ogra> but if you say malone, this onversation should probably be in #ubuntu-motu
[04:21] <thierry_> so when sending a patch to malone, I put the distribution as dapper right?
[04:21] <thierry_> ogra : k sorry
[04:21] <ogra> yes
[04:24] <ogra> seb128, does the sabayon version you just uploaded already include pessulus ?
[04:25] <seb128> yeah
[04:25] <ogra> cool :-D
[04:25] <seb128> previous one already did
[04:26] <thierry_> how can I set a environment variable like DEBFULLNAME ?
[04:26] <ogra> with export
[04:26] <thierry_> like export DEBFULLNAME="my name" ?
[04:26] <ogra> yup
[04:27] <azeem> thierry_: you can set that in ~/.devscripts as well I think
[04:27] <azeem> or something like that
[04:27] <zakame> or in your ~/.bashrc
[04:28] <fabbione> torkel: pong?
[04:29] <Nafallo> DEBEMAIL is even better :-)
[04:29] <torkel> fabbione: have you seen: http://www.clusterfs.com/pr/2005-11-16.html
[04:29] <fabbione> no
[04:29] <fabbione> not yet at least
[04:30] <fabbione> torkel: it's unlikely we will add lustre, but i will take a look to it
[04:31] <zul_^> arent you suppose to be in school fabbione
[04:31] <fabbione> i am supposed to be going there
[04:31] <fabbione> waiting my wife to bring back the car
[04:31] <fabbione> she is late.. as usual
[04:32] <torkel> fabbione: there is at least a chance now :-)
[04:32] <zul_^> ah..<bite my tongue>
[04:32] <zakame> hihi
[04:36] <torkel> fabbione: there are patches for newer kernels in their bugzilla
[04:37] <fabbione> torkel: the one in the pkg are for 2.6.6
[04:37] <fabbione> no way it's even gonna make it
[04:37] <torkel> fabbione: there are patches for at least 2.6.13 in the bugzilla
[04:38] <fabbione> still too old and start adding an FS out of unreviewed bugzilla patches is no no no
[04:38] <torkel> fabbione: https://bugzilla.lustre.org/show_bug.cgi?id=9421
[04:39] <fabbione> torkel: if you want you are welcome to prepare a patch on top of our kernel
[04:40] <fabbione> i am not going to allocate time on it
[04:46] <sistpoty> fabbione: an off-topic question: is there a debian-way of building a kernel-module (like install kernel-headers, use includes from xyz... I'm not thinking of a packaged module to be built with kernel-package here)
[04:47] <zakame> sistpoty: make-kpkg modules-image iirc
[04:47] <JaneW> Diziet: ping
[04:47] <zakame> where modules to be built are in MODULE_LOC
[04:48] <sistpoty> zakame: nope... it's a module from the faumachine-project, they are working on. so it's not packaged or s.th.. they just want to set up compilation in the debian way (preferably not having a kernel-source around)
[04:49] <fabbione> sistpoty: you can use module-assistant
[04:49] <zakame> sistpoty: module-assistant
[04:49] <sistpoty> fabbione, zakame: ok, thx... I will take a look at this (and how m-a actually compiles it)
[04:49] <fabbione> sistpoty: you will still need to B-D on the correct linux-headers
[04:50] <fabbione> sistpoty: i did something like that in the redhad-cluster-suite
[04:50] <fabbione> sistpoty: where i ship the -source for the cluster modules
[04:50] <fabbione> if you follow the same packaging/logic it should work
[04:51] <sistpoty> fabbione: thx... i will take a look at this. but now it's not yet done enough for packaging ;)
[04:54] <pitti> elmo: please sync libnss-db
[04:54] <seb128> grumpf
[04:54] <seb128> if somebody has an idea on how to fix the krb4 ftbfs with openssl 0.9.8 he's welcome to do it
[04:54] <seb128> that's a blocker for flight-1 :/
[04:55] <seb128>                  from ftpcmd.y:45:
[04:55] <seb128> /usr/include/openssl/ossl_typ.h:144: error: syntax error before numeric constant
[04:55] <seb128> make: *** [ftpcmd.o]  Error 1
[04:56] <BenC> what's that line look like?
[04:56] <fabbione> who did upload krb4 last?
[04:56] <seb128> typedef struct conf_st CONF;
[04:56] <fabbione> seb128: it looks like you win :D
[04:57] <seb128> fabbione: what is the price? :)
[04:57] <BenC> what is CONF defined as?
[04:57] <fabbione> seb128: that you get to fix it? ;)
[04:57] <bmonty_laptop> elmo: did you have a chance to look at the sync request emails I sent you?
[04:57] <BenC> sorry, I don't have the headers available
[04:57] <fabbione> anyway i am off for real now
[04:57] <fabbione> later
[04:57] <zul_^> liar
[04:58] <BenC> seb128: give me a minute, and I'll look at that error
[04:58] <seb128> ossl_typ.h:typedef struct conf_st CONF;
[04:58] <seb128> BenC: thanks
[04:59] <seb128> hum, hum
[04:59] <thierry_> how could I take "bittornado-0.3.11" and put only "bittornado" in a variable (in bash)
[05:00] <seb128> thierry_: please use an another chan for generic bash questions
[05:00] <thierry_> seb128 : wich one?
[05:00] <BenC> foo=$(echo $foo | sed 's/-.*//')
[05:00] <zakame> thierry_: #bash ?
[05:00] <BenC> or do that :)
[05:00] <thierry_> zakame : thanks didn't know it existed
[05:00] <zakame> thierry_: hehe, np :)
[05:01] <BenC> seb128: my best guess is that krb4 is defining CONF to something else, and it is breaking because of that
[05:02] <BenC> seb128: if you add -save-temps to CFLAGS it should keep the .i file from preprocessing and you can look at that to see if it's correct
[05:02] <\sh> foo=$(echo $foo|awk -F"-" '{ print $1 }'
[05:02] <\sh> foo=$(echo $foo|awk -F"-" '{ print $1 }')
[05:02] <\sh> there are always two ways...the sed way or the awk way ,-)
[05:03] <seb128> BenC: let me try that
[05:04] <BenC> seb128: if the build is somewhere I can get to, I can look a little deeper and probably provide a fix
[05:05] <seb128> BenC: ftpcmd.i from krb4 has one CONF from a enum and one from a struct, should not be an issue
[05:05] <BenC> sure it is
[05:05] <seb128> BenC: apt-get source -b krb4 and you have it
[05:05] <seb128> if you run current dapper
[05:06] <seb128> I can put the build on a ubuntu box if you want
[05:06] <BenC> the .i file would be helpful, then I can just look at the sourc
[05:06] <seb128> k
[05:07] <neuralis> \sh: or |cut -d- -f1, which is shorter ;)
[05:07] <mdz> morning
[05:07] <\sh> neuralis: ok...many ways are leading us to one solution :)
[05:07] <BenC> morning mdz
[05:08] <seb128> hi mdz
[05:08] <mvo> hey mdz 
[05:09] <sivang> morning mdz 
[05:09] <zakame> hi mdz 
[05:09] <mdz> JaneW: around?
[05:10] <JaneW> mdz: yes
[05:12] <mvo> seb128, BenC: I think I have the reason
[05:12] <BenC> mvo: well the reason is that CONF is a enum, which is processed as a numeric index, which breaks the typedef, the fix isn't that apparent
[05:13] <seb128> BenC: ftpd/ftpcmd.i on my chinstrap userdir
[05:14] <seb128> BenC: hum, right
[05:14] <mvo> BenC: right. looks like it should be save to just give the enum a more descriptive name?
[05:15] <BenC> mvo: not sure, I can't tell if it will break the command protocol
[05:15] <BenC> I think if you rename it, it should be ok
[05:15] <BenC> since it uses a string with the enum name for parsing
[05:15] <mvo> BenC: it looks to me like it's save to rename the constant as long as the token remains the same
[05:16] <BenC> yeah
[05:16] <BenC> seb128: try renaming CONF in ftpcmd.y to FTPD_CONF (just the places where it uses the enum, not the string and such)
[05:17] <dholbach> we've been slashdotted: http://linux.slashdot.org/article.pl?sid=05/11/17/1418206&from=rss :)
[05:17] <seb128> BenC: will try that, thanks
[05:19] <BenC> seb128: no problem
[05:19] <siretart> hi
[05:20] <siretart> mdz or anyone else: do you know if someone is doing any efford in getting opera (yeah, the commercial closed sourced stuff) in multiverse?
[05:20] <siretart> someone from plf is asking if we are going to have it in ubuntu or whether they should package it..
[05:21] <Kmirno> Hi
[05:21] <siretart> Kmirno: I just asked
[05:21] <mdz> siretart: is it redistributable?
[05:21] <siretart> mdz: thats the problem: we did not find any statment about redistribution terms on the opera website :/
[05:24] <ptlo> siretart, there's a page about mirroring (there are some requirements for someone to host a mirror for opera) at http://www.opera.com/download/mirrors/specs/ , maybe that can hint at their standpoint
[05:25] <Nafallo> mail them? can't be that hard? :-)
[05:26] <ptlo> specifically,: "Registered mirrors agree to carry all browser files that Opera produces.", "Note: If your site prefers to carry only specific platforms or languages, you are free to host whichever files you choose. However, your links to these files will not be posted at Opera"
[05:26] <siretart> yeah, perhaps we should just ask them if we would be allowed to redistributed packaged version of their binaries
[05:26] <siretart> Kmirno: would you ask them via email and CC me?
[05:27] <Kmirno> siretart: what mail ?
[05:27] <Mithrandir> siretart: they provide .debs which are reasonably sane.
[05:28] <[splinux] > hi all
[05:29] <siretart> Kmirno: asking them if we are allowed to redistribute packaged binaries of their software.
[05:32] <Mirno> I need your mail if you want to be CCed Simira 
[05:32] <Mirno> oops
[05:32] <Mirno> siretart: 
[05:32] <Mirno> oh I already have it
[05:32] <Mirno> nether mind
[05:32] <Mirno> ever*
[05:32] <Mirno> never*
[05:32] <Mirno> arrg
[05:34] <Kmirno> siretart: I found No emaiul adress for opera
[05:35] <siretart> Mirno: my email is 'siretart@ubuntu.com'
[05:35] <Kmirno> siretart: they have a contact form here http://www.opera.com/contact/
[05:35] <Kmirno> siretart: but no email
[05:35] <lamont-away>  /usr/include/openssl/ossl_typ.h:144: error: syntax error before numeric constant
[05:35] <lamont-away> krb4 unhappiness
[05:36] <siretart> Kmirno: better than nothing
[05:36] <Kmirno> siretart: ha
[05:36] <ogra> lamont-away, see backlog ;)
[05:37] <lamont-away> ogra: heh - ok
[05:37] <Kmirno> siretart: they have some stuff for redistribution, you register and you get the terms
[05:37] <lamont-away> ogra: that's wrt krb4, or something else?
[05:37] <Kmirno> siretart: http://composer.opera.com/composer3/register.dml
[05:37] <\sh> seb128: gnometris is set to sgid ... which doesn't work :)
[05:37] <lamont-away> (not that I really particularly care about krb4, mind you...)
[05:38] <ogra> lamont-away, thats about krb4
[05:38] <seb128> \sh: http://bugzilla.ubuntu.com/show_bug.cgi?id=19668
[05:38] <seb128> \sh: dholbach did this update :p
[05:39] <pitti> elmo: please sync nas
[05:39] <mdz> Mithrandir: how do we look for installable CDs/livefs?
[05:42] <siretart> huhu mvo 
[05:42] <_rob^> mvo: installing either gksu or its deps fixed me up for gdebi. Also python-vte is in universe right now...
[05:43] <mvo> _rob^: thanks! (python-vte is something I would love to see in main)
[05:43] <mvo> _rob^: so gdebi does work for you? 
[05:43] <_rob^> mvo: yep I updated from an old version to last nights
[05:43] <\sh> seb128: looks like there is an issue with cdbs then, or dh_fixperms doesn't work correctly
[05:44] <_rob^> and i'm installing nvu right now
[05:44] <_rob^> is it processing deps twice?
[05:44] <_rob^> once to ask for confirmation and again when installing?
[05:44] <lamont-away>   ubuntu-desktop: Depends: hplip-base but it is not going to be installed
[05:44] <lamont-away>                   Depends: python2.4-librdf but it is not going to be installed
[05:44] <lamont-away>                   Depends: python2.4-pycurl but it is not going to be installed
[05:44] <lamont-away> that was the last scheduled run failure
[05:44] <mvo> _rob^: yes, when you use it as a user it can't install, you have to switch to root for that
[05:44] <lamont-away> add gnome-applets and gnome-panel in a couple places
[05:45] <_rob^> is there a way to cut that down?
[05:45] <mvo> _rob^: I can't think of one right now
[05:46] <seb128> \sh: they need to be sgid game to write the scores to /var/games
[05:46] <_rob^> it seems like finding out your package is broken after authing is not a big deal if it doesn't install anything
[05:46] <_rob^> I guess it really is worse for a modem user though
[05:47] <wasabi_> mvo: don't suppose any thought has been put into making gdebi accept that .apt file idea I had? :)
[05:47] <mvo> _rob^: well, that is certainly doable. and it should be ok for modem users because it will not download anything 
[05:47] <mvo> wasabi_: *cough* no. but it would not be hard to add (especially nowday when we have sources.list.d)
[05:48] <wasabi_> Ahh you didn't know we had that.
[05:48] <wasabi_> Err
[05:48] <mvo> _rob^: that is, it won't download when it detect that it can't satisfy dependencies
[05:48] <wasabi_> I didn't know we had that
[05:48] <lamont-away> mvo: there's support for sources.list.d???? since when?
[05:48] <mvo> wasabi_: it's very recent
[05:48] <_rob^> mvo: it would be good if there were a way to precalculate while a user was reading the package description
[05:48] <wasabi_> That kicks ass.
[05:48] <lamont-away> mvo: debian and ubuntu?
[05:48] <mvo> lamont-away: the last apt upload
[05:48] <mvo> lamont-away: in debian with the next apt upload :)
[05:48] <mvo> lamont-away: you like it?
[05:48] <mvo> lamont-away: or are you about to kick me for it?
[05:49] <mvo> _rob^: that's another nice idea, just do the cache reasding in the background
[05:49] <lamont-away> mvo: I don't dislike it, there are times that it would make life easier.
[05:49] <lamont-away> unless, that is, you _want_ me to kick you .....
[05:49] <mdke> dholbach, will you be around in the docteam meeting tomorrow at 14 utc? the "single source" thing is on the agenda
[05:49] <wasabi_> mvo: some other crazy idea just hit me. Not sure if I like this crazy idea... but it hit me none-the-less.
[05:49] <lamont-away> but I didn't think you were into that sort of thing.
[05:49] <dholbach> mdke: yeah
[05:50] <mvo> lamont-away: I take (gentle) beatings only from females ;)
[05:50] <lamont-away> 'zactly
[05:50] <wasabi_> mvo: instead of .apt files, now, with gdebi, a ISV can distribute a .deb. That .deb can install the gpg key and a sources.list.
[05:50] <wasabi_> That sounds a little hacky, but I don't know.
[05:50] <wasabi_> It might be moving the logic into just the right place.
[05:50] <lamont-away> wasabi: if the deb installs a gpg key before it's validated, then we may as well just remove signed archives from existance
[05:50] <lamont-away> since that would defeat the whole purpose.
[05:51] <wasabi_> ?
[05:51] <pitti> Kamion: I think a lot of the current breakage is due to libmysqlclient14 uninstallability; I guess mysql-common is still in NEW, right?
[05:51] <pitti> elmo: ^
[05:51] <wasabi_> It wouldn't install a key until the user accepted to install the .deb itself.
[05:51] <lamont-away> wasabi: the idea is to validate the .deb against a known-trusted key _before_ you install some random deb.
[05:51] <mvo> wasabi_: the problem remains that it must trigger a apt-get update 
[05:51] <_rob^> mvo: OS X does somethign really nasty in that regards but I don't knwo what
[05:51] <wasabi_> And the sources.list wouldn't be present unless a debconf question asked the user if they want to track updates.
[05:51] <_rob^> mvo: it says that it must run a program to determine if you can install the software and you auth to run that
[05:52] <wasabi_> Where can I find gdebi anyways?
[05:52] <lamont-away> wasabi_: and how does the user know that the deb he's installing is in fact the deb that the purported author originally shipped, and not the one that I replaced the key in at the same time that I trojaned the binaries?
[05:52] <ogra> wasabi_, ubuntu-devel ML
[05:52] <mvo> wasabi_: source or deb? source is bzr, deb is at http://people.ubuntu.com/~mvo/gdebi
[05:52] <wasabi_> lamont-away: same way we know the Ubuntu CD we download is in fact the real one.
[05:52] <mvo> lamont-away: we need signed debs!
[05:52] <wasabi_> There has to be an initial moment of trust, where you trust a vendor.
[05:52] <lamont-away> wasabi_: because we have a trusted key that signed an md5sum file somewhere?  OK.
[05:53] <wasabi_> And that trust can extend to the update process safely.
[05:53] <\sh> seb128: well...how do u train gtk to understand this_
[05:53] <wasabi_> lamont-away: trusted by who? :)
[05:53] <wasabi_> The fact is, if an ISV is distributing a program, I have to initially trust the ISV to deliver me his public key.
[05:53] <ogra> wasabi_, the strong gpg set ?
[05:55] <lamont-away> wasabi_: well, in this case, the ubuntu archive automatic signing key is signed by some 'james troup' guy, who is in the well connected set, and known to be employed by canonical to do archive maintenence...  so I trust that key...
[05:55] <wasabi_> okay? We're talking about people who have no relation to canonical.
[05:55] <wasabi_> Like, oh, VMware.
[05:55] <lamont-away> and the CD signing key is (or should be) signed by Kamion, same story
[05:56] <wasabi_> At some point I have to go to https://www.vmware.com and verify that the softwae I download really comes from some random company I want to believe.
[05:56] <lamont-away> vmware has people with keys in the global ring of trust who could sign such a key, etc.
[05:56] <mvo> I tend to think that that random installing of deb is rare, and if people do that, they should be aware that they should at least do it over ssl (and have a cert they trust)
[05:56] <lamont-away> mvo: right
[05:56] <wasabi_> If you ever touch commercial software, it's not rare.
[05:56] <mvo> but yeah, I agree with your concern
[05:56] <wasabi_> So it's a basic question.
[05:56] <wasabi_> Do we want to assist ISVs
[05:57] <lamont-away> mvo: but the notion that installing some deb will modifiy /etc/apt/trusted.gpg is just a tad bit scary
[05:57] <wasabi_> Or do we want to independently package everything.
[05:57] <wasabi_> I'd personally like to be able to buy VMware and "Click Here To Install"
[05:57] <ogra> wasabi_, whats the prob for an ISV to get a signed trustable key ? 
[05:57] <wasabi_> Instead of running some shell script magic.
[05:57] <lamont-away> mvo: not that there's anything preventing it from happening today, of course.
[05:57] <ogra> i dont see the issue
[05:57] <mvo> it will only do it via the apt-key command
[05:58] <mvo> lamont-away: I mean, I see you point, but it's not scarier than the "radnom-binary-install" package we have today (e.g. for realplayer)
[05:58] <lamont-away> mvo: if some random deb did 'cat >> /etc/apt/trusted.gpg', it'd work.  it'd violate policy to hell and gone, but it'd work...
[05:58] <lamont-away> mvo: true
[05:58] <wasabi_> Does Canonical want to be the gate keeper for ISVs keys?
[05:58] <wasabi_> That's anohter question.
[05:58] <wasabi_> MS made the choice to be so, for drivers.
[05:58] <mvo> I don't think we want to
[05:58] <ogra> wasabi_, thats what the keyservers ar or
[05:58] <wasabi_> it didn't work very well imo
[05:58] <ogra> *for
[05:59] <lamont-away> mvo: I guess my point is that since those keys are fully trusted regardless of the source and name of the package, I'd like to personally be involved in the decision to add said key to trusted.gpg
[06:00] <seb128> lamont-away: can you set an evolution-data-server build when krb4_1.2.2-11.3ubuntu2 is available?
[06:00] <mvo> lamont-away: yes, that's true. that's what wasabi_ was saying about the "do auto-track of updates from this vendor" question I guess. the problem is that once you allow the install of a deb, than it really dosn't matter anymore because that deb can do whatever it wants anyway
[06:00] <_rob^> wasabi: I would htink Ubuntu Foundation would be the org to looka fter that stuff
[06:01] <seb128> lamont-away: ppc build that's it
[06:01] <lamont-away> seb128: it'll ftbfs before that, yes?
[06:01] <lamont-away> mvo: yeah
[06:01] <seb128> lamont-away: it already ftbfsed
[06:01] <seb128> lamont-away: it needs a retry when krb4 is built
[06:02] <lamont-away> seb128: just ppc? or everywhere?
[06:02] <seb128> lamont-away: evolution-data-server? just ppc, it did build on other arches
[06:03] <lamont-away> seb128: OK.  I'll make sure I kick it once it gets back to me
[06:03] <mvo> wasabi_: let me know if you want to hack on gdebi, I'm happy to assist
[06:03] <seb128> lamont-away: thanks, that's the remainer blocker for flight-1
[06:03] <seb128> lamont-away: when e-d-s is built then gnome-panel need to be retried
[06:06] <sistpoty> elmo: please sync childsplay-plugins, ubuntu override ok
[06:11] <lamont-away> seb128: the 2 ppc buildd's are currently building: krb4 and ghc6
[06:12] <seb128> lamont-away: rock
[06:14] <wasabi_> Yeah, my original ThirdPartyApt idea had some way to only track updates from a certain vendor for certain packages, but mvo reminded me that all of these updates are installed as root anyways.
[06:14] <wasabi_> So it doesn't matter. If a vendor wants to screw with your system, he can, period.
[06:14] <lamont-away> seb128: krb4_1.2.2-11.3ubuntu1 is FTBFS
[06:14] <pitti> sjoerd: ping
[06:14] <seb128> lamont-away: yeah, that's why I said krb4_1.2.2-11.3ubuntu2 :p
[06:15] <lamont-away> heh - ok
[06:15] <wasabi_> Now, if we want to prevent that, we're looking at a major deviation.
[06:15] <lamont-away> the krb4 that was building was 3ubuntu1
[06:15] <seb128> oh, k
[06:15] <wasabi_> Like, to install third party .deb's into a seperate root.
[06:15] <wasabi_> Like the n770 does.
[06:15] <wasabi_> (which imo is pretty cool)
[06:16] <wasabi_> mvo: I'd like to. ;)
[06:18] <mvo> wasabi_: making it instller for the n770 a bit nicer is on my list for when I have some free days :)
[06:19] <wasabi_> I'm a bit curious about their approach to third aprty things...
[06:19] <wasabi_> /var/lib/install, and the install user.
[06:19] <wasabi_> Interesting idea.
[06:19] <mvo> it's pretty clever
[06:19] <mvo> even 3rd party apps can't root it
[06:19] <wasabi_> Yeah.
[06:19] <mvo> and the user never gets root
[06:20] <wasabi_> We could futz with a similar thing for gdebi... ;)
[06:20] <lamont-away> seb128: dep-waited (eds and gnome-panel)
[06:21] <seb128> lamont-away: thanks
[06:21] <mvo> wasabi_: it's tempting :) but relocating means thatthe source for the packages needs to be modified (because a lot of them expect e.g. /etc/ as their config path)
[06:21] <_rob^> mvo: mind if I dcc you a mockup of what gdebi might look like?
[06:21] <wasabi_> Yeah. We do have a clean base to start with right now though, we have no third party ISVs that provide .debs
[06:21] <wasabi_> Of any magnatude anyways.
[06:21] <mvo> _rob^: try, I'm not sure if I have working dcc
[06:21] <wasabi_> It would be interesting to if nothing else, add support for it.
[06:22] <robertj> whee
[06:23] <robertj> it's 1992 again!
[06:23] <mvo> wasabi_: yes, I put it on my todo
[06:23] <neuralis> mvo, doing it that way (separate location) also means you'd get people like me to shut up about security and be happy about shipping it with a default install.
[06:24] <mvo> robertj: looks nice, did you talked to mpt? he made similar suggestions
[06:24] <robertj> nope
[06:24] <mvo> neuralis: heh :)
[06:24] <wasabi_> Hmm. Could work out. I can see where some packages would require root access anyways.
[06:24] <wasabi_> VMware being the prime example.
[06:24] <wasabi_> As it needs kernel modules.
[06:25] <wasabi_> gdebi could install unsigned packages into a subdir, but signed ones into /
[06:25] <wasabi_> that'd be interesting.
[06:25] <robertj> mvo: I really like the package info but I kinda wish there was a standard applet for investigating that
[06:25] <robertj> mvo: so that you could get that same info post install as well
[06:25] <neuralis> wasabi, whose signatures does it trust?
[06:25] <wasabi_> Canonical.
[06:25] <wasabi_> Just brainstorming.
[06:26] <mvo> robertj: you mean it should look like the synaptic dialog? or what do you mean with post-install?
[06:26] <robertj> anyway off to lunch
[06:26] <robertj> mvo: let me look at synaptic for a second
[06:26] <wasabi_> mvo: where can I find gdebi?
[06:27] <mvo> wasabi_: source or deb?
[06:27] <wasabi_> Both. ;)
[06:27] <neuralis> wasabi, so that might not be a bad compromise. most stuff can live in a subdir; if it can't, one of the motus can perhaps inspect it and sign it, which would let it get installed in /.
[06:27] <robertj> wasabi http://people.ubuntu.com/~mvo/gdebi/
[06:27] <mvo> wasabi_: deb: http://people.ubuntu.com/~mvo/gdebi
[06:27] <mvo> robertj: thanks :)
[06:27] <mvo> wasabi_: src is a bzr archive at http://people.ubuntu.com/~mvo/bzr/gdebi--main
[06:28] <wasabi_> I need to learn it still.
[06:28] <robertj> mvo: wow I've never even seen the properties menu on the packages before, that's cool
[06:29] <robertj> I was thinking something more "applied" in nature for mid-level users
[06:29] <mvo> wasabi_: very, very easy: bzr {get,diff,commit,merge}
[06:29] <robertj> "It installs these menu entries, here are the docs, here is the licence" that sort of thing
[06:30] <mvo> robertj: right, some of this is tricky, but it looks like it's a good idea
[06:30] <robertj> but anyway, I think that is relatively minor
[06:30] <robertj> but more than anything, the #1 thing you can do is change the text as you go
[06:31] <robertj> just "Preparing to Install" "Installing - X%" "Application Installed" or something of that sort
[06:31] <mvo> yeah
[06:31] <robertj> No need for a terminal menu
[06:31] <robertj> err revealer
[06:31] <robertj> if someone needs a terminal revealed they will go run it in a terminal
[06:31] <wasabi_> Wonder if there's anyway for a package to install other packages in the postinst.
[06:31] <pef> hello !
[06:33] <mvo> robertj: I would love to kill the terminal, but some packages still use "read" in the postinst
[06:33] <mvo> very few fortunately, but they still exist :/
[06:34] <robertj> mvo: can you just hide it then?
[06:34] <ogra> mvo, its just a matter of running a sed script over the whole source archive ;)
[06:35] <mvo> or redirecting stdin to /dev/null!
[06:35] <ogra> robertj, read means it waits for user input
[06:36] <wasabi_> Hmmm. Hmmmm.
[06:36] <lamont-away> wasabi: 'man at' :-)
[06:36] <wasabi_> Ugh.
[06:36] <wasabi_> That doesn't work out anyways. Has to do the install with the same frontend that the original package was installed with
[06:38] <lamont-away> seb128: btw, gthumb is unhappy, too.
[06:38] <lamont-away> make[1] : Entering directory `/build/buildd/gthumb-2.6.8'
[06:38] <lamont-away> cd . && /bin/sh /build/buildd/gthumb-2.6.8/missing --run aclocal-1.7
[06:38] <lamont-away> aclocal: configure.in: 12: macro `AM_PROG_LIBTOOL' not found in library
[06:38] <seb128> lamont-away: yeah, I already told to dholbach who made the upload
[06:38] <lamont-away> ok
[06:38] <lamont-away> did you fix heimdal when you fixed krb4? (same error)
[06:38] <lamont-away> mvo: vscreen.cc:973: error: 'struct sigaction' has no member named 'sa_restorer'
[06:39] <lamont-away> please fix aptitude.
[06:39] <robertj> ogra: well I thought it just needed to read from a null sink or something that still required a terminal for some reason
[06:39] <lamont-away> (sa_restorer is optional - memset the struct to zero, then fill in the non-zero fields...)
[06:39] <robertj> ogra: but if your package is not using debconf then...too bad
[06:39] <mvo> lamont-away: hu? what arch?
[06:39] <lamont-away> mvo: ia64/hppa
[06:39] <lamont-away> halley is a good test machine, IIRC
[06:40] <mvo> lamont-away: thanks
[06:40] <ogra> robertj, you can put a pipe in place and send \n for the reads, but fixig the packages should be the way to go ...
[06:40] <lamont-away> if it builds on halley, it's golden
[06:41] <mvo> ogra: *argggg*
[06:41] <lamont-away> heh... elmo: dapper chroot on halley, if you would be so kind...
[06:41] <ogra> mvo, one \n every second ;)
[06:41] <lamont-away> ogra: that's _VILE_
[06:41] <robertj> ogra: indeed, but the easy way is "Don't expact grandma to use gdebi to install your broken packages"
[06:41] <lamont-away> robertj: but do expect her to use it for your non-borken ones.
[06:42] <ogra> yeah
[06:42] <robertj> lamont: yup, sound good
[06:43] <lamont-away> aspell --lang=fi create master ./fi < fi.wl
[06:43] <lamont-away> /bin/sh: aspell: command not found
[06:43] <wasabi_> mvo, gdebi doesn't run update-desktop-database I don't think
[06:43] <lamont-away> bad ispell-fi
[06:43] <ogra> mvo, no, serious, do you have a list with packages with broken postinst scripts ? 
[06:43] <ogra> mvo, could be a good motu project for post feature freeze :)
[06:46] <pitti> mdz, Kamion: is it a bad time to upload a new hal now? shall I wait until after flight-1?
[06:47] <lamont-away> pitti: I just sent you mail, fwiw
[06:47] <lamont-away> make[1] : Entering directory `/build/buildd/libio-socket-ssl-perl-0.97'
[06:47] <lamont-away> PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
[06:47] <lamont-away> t/01loadmodule.....ok
[06:47] <lamont-away> t/02settings.......Use of uninitialized value in getprotobynumber at /usr/share/perl/5.8/IO/Socket/INET.pm line 133.
[06:47] <lamont-away> Use of uninitialized value in socket at /usr/lib/perl/5.8/IO/Socket.pm line 80.
[06:47] <lamont-away> Use of uninitialized value in socket at /usr/lib/perl/5.8/IO/Socket.pm line 80.
[06:47] <lamont-away> (that's on i386)
[06:48] <pitti> lamont-away: *boggle* fetchmail built fine for me here...
[06:49] <lamont-away> pitti: maybe your dapper isn't the same as my dapper...
[06:49] <mvo> ogra: no, I don't have a list
[06:49] <pitti> lamont-away: hm, just unpacked the source again, it still builds
[06:49] <pitti> grrrr
[06:50] <jbailey> pitti: grrrr at me?
[06:50] <lamont-away> jbailey: nah - at fetchmail
[06:50] <lamont-away> iz ftbfs
[06:50] <pitti> jbailey: no :) at fetchmail, which is ftbfs on buildd and works on my box
[06:50] <jbailey> Ah, okay. =)
[06:51] <jbailey> Just making sure I hadn't annoyed the world for something unintentional.
[06:51] <jbailey> If I'm going to piss people off, I'd like to make it good. =)
[06:51] <lamont-away> jbailey: whereas intentionally annoying the world is SOP?
[06:52] <pitti> lamont-away: I really don't understand - the only patch is de.po.patch; there is no such thing like 01pop3sec
[06:52] <jbailey> lamont-away: My guidance councellor told me to have goals, my basketball coach told me consistancy was good.
[06:52] <pitti> lamont-away: sure that this is the right build log?
[06:52] <jbailey> lamont-away: Noone can say I didn't listen to my teachers.
[06:52] <mdz> pitti: what will hal break?
[06:52] <pitti> lamont-away: http://people.ubuntu.com/~lamont/buildLogs/f/fetchmail/6.2.5.4-1ubuntu1/ -> all successful
[06:52] <lamont-away> pitti: looking more
[06:53] <pitti> mdz: nothing, it works fine for both 2.6.15 and 2.6.12
[06:53] <lamont-away>       253 Log for failed build of fetchmail_6.2.5-18ubuntu1 (dist=dapper)
[06:53] <lamont-away>       253 Log for failed build of fetchmail_6.2.5-18ubuntu1 (dist=dapper)
[06:53] <pitti> lamont-away: that's Mithrandir's failed build
[06:53] <lamont-away> doh
[06:53] <pitti> lamont-away: I already uploaded 6.2.5.4
[06:53] <lamont-away> pitti: you can go back to sleep now...
[06:53] <lamont-away> sorry about that
[06:53] <pitti> lamont-away: you really scared me :)
[06:54] <lamont-away> dpkg-deb: failed to open package info file `debian/lib32z1/DEBIAN/control' for reading: No such file or directory
[06:54] <lamont-away> (ia64 is ftbfs)
[06:54] <pitti> mdz: I'm just asking because of CD packages stabilization for flight-1
[06:55] <lamont-away> seb128: uh.... -3ubuntu1 is still the current version of krb4.....   just thought  you'd like to know and all that.
[06:55] <lamont-away> ah, was just accepted, it appears.. nm
[07:03] <sjoerd> pitti: pong
[07:04] <pitti> Hi sjoerd 
[07:04] <pitti> sjoerd: I merged hal 0.5.5.1 and fixed the 'do not restart' bits
[07:05] <pitti> sjoerd: also, I fixed the dbus invocation (s/reload/force-reload/)
[07:05] <pitti> sjoerd: http://people.ubuntu.com/~pitti/patches/hal_0.5.5.1_ubuntu.diff is the diff in case you are interested :)
[07:05] <sjoerd> pitti: why force-reload ?
[07:06] <pitti> sjoerd: because it is a policy violation to use reload
[07:06] <pitti> sjoerd: and reload does not exist in at least Ubuntu's dbus
[07:06] <pitti> sjoerd: reload is optional, force-reload is mandatory
[07:06] <sjoerd> hrm, need to check policy in that case
[07:07] <sjoerd> well for dbus reload is reload your config file in debian now and force-reload is restart, which you don't want
[07:07] <pitti> sjoerd: anyway, merging was nice; ubuntu specific changes are minimal :)
[07:07] <sjoerd> pitti: cool, nice to hear
[07:07] <pitti> sjoerd: but if debian's dbus has a proper reload, then force-reload should do the same
[07:08] <sjoerd> pitti: right, need to change that then
[07:08] <pitti> sjoerd: also, the current experimental package does restart hal
[07:08] <pitti> sjoerd: due to some maintscripts bugs
[07:09] <sjoerd> couldn't remember anymore if we said just not to restart dbus, or also not restart hal
[07:09] <dilinger> jbailey: you missed a rousing cdbs3 discussion in #d-d, btw :p
[07:09] <jbailey> dilinger: Ah?  Got logs? =)
[07:09] <torkel> fabbione: we have to have lustre running so we have to patch the kernel anyway. Primarily it will be against the breezy kernel though
[07:09] <pitti> sjoerd: oh, in Ubuntu we restart neither
[07:10] <sjoerd> pitti: currently restarting hal on upgrade is still intentionally.. and i would prefer to keep it that way
[07:10] <pitti> sjoerd: ah, ok
[07:10] <pitti> sjoerd: then ignore these bits from the debdiff
[07:10] <sjoerd> k
[07:10] <pitti> sjoerd: since that breaks some apps, we don't restart hal in Ubuntu any more
[07:11] <dilinger> jbailey: http://mouth.voxel.net/~dilinger/cdbs3
[07:11] <sjoerd> i thought that it was the dbus restarting that breaks stuff
[07:11] <pitti> both
[07:11] <sjoerd> :(
[07:14] <Robot101> sjoerd: by default, libdbus abort()s your app if dbus disconnects it
[07:14] <dilinger> wow, CFS finally release lustre 1.2.x
[07:14] <sjoerd> Robot101: i known, stupid behaviour, you can turn it off though.. But anyway we don't restart dbus anymore on upgrades
[07:15] <dilinger> s/release/gpl'd/
[07:15] <Robot101> sjoerd: yeah, because most applications don't bother restoring their state to it when disconnected
[07:51] <crimsun> elmo: please sync wpasupplicant from sid
[07:55] <Kamion> pitti: please don't upload hal, unless you have already
[07:57] <Kamion> mdz: status: mysql breaking (investigating now), parted spewing annoying error on install which is technically cosmetic (also investigating but will take longer), rest *should* be ok although I have a test install running now to make sure there are no other gotchas
[07:58] <pitti> Kamion: not yet
[07:59] <pitti> Kamion: I think mysql-common is in NEW
[07:59] <Kamion> lamont-away: phew, I *did* remember to sign the cdimage signing key
[07:59] <Kamion> pitti: it's not
[07:59] <pitti> Kamion: or something
[07:59] <Kamion>  Binary only promotions to main
[07:59] <Kamion>  ------------------------------
[07:59] <pitti> Kamion: hmm; it should be built from the 4-1 package
[07:59] <Kamion>  o mysql-client-4.1 mysql-server-4.1                          {mysql-dfsg-4.1}
[07:59] <Kamion>    [Reverse-Depends: mysql-client, mysql-server] 
[07:59] <Kamion> that would do it
[07:59] <pitti> aah
[07:59] <Kamion> I've promoted those two
[07:59] <pitti> Kamion: but does that explain the uninstallability of libmysqlclient14?
[08:00] <pitti> Kamion: we have the source in main anyway and should drop 4.0 for dapper
[08:00] <Kamion> hm, no
[08:00] <pitti> Kamion: it depends on mysql-common, which is not available for 4.1.15
[08:00] <pitti> jsut for 4.0.20
[08:01] <pitti> I don't know why, the package built fine
[08:02] <Kamion> eep, archive-copier failed for WEIRD reasons
[08:03] <Kamion> and that would be because debootstrap has gone insane. mumble
[08:03] <pitti> Kamion: argh, eek - -common is built from mysql-dfsg-5.0
[08:04] <pitti> Kamion: it just contains /etc/mysql/my.cnf though, so we could fix that easily
[08:04] <Kamion> pitti: mysql-dfsg-5.0 isn't in the archive
[08:04] <pitti> question is jsut whether we want 4.1 or 5.0 in dapper (yay versionitis)
[08:06] <pitti> Kamion: ok, I'll fix that for now; I have -4.1 build a common package if that is fine for you
[08:06] <Kamion> in dapper it's built from mysql-dfsg, which is too old to satisfy libmysqlclient14's versioned dep
[08:06] <Kamion> pitti: sure, please also upload mysql-dfsg to stop it building -common
[08:06] <pitti> Kamion: we might just sync it, but I didn't check
[08:06] <pitti> Kamion: Debian has -5.0 in unstable now
[08:07] <pitti> Kamion: so Debian does not build -common from -4.1 and 4.0 any more
[08:07] <Kamion> right, let's leave that until *after* Flight 1, enough breakage for one afternoon ...
[08:09] <pitti> Kamion: ok, let's get 5.0 and ditch 4.1 and 4.0 later then; I'll fix 4.0 and 4.1 for now
[08:09] <pitti> bah
[08:14] <mdz> Kamion: what's mysql breaking?  server CD?
[08:14] <pitti> the world...
[08:14] <Kamion> /home/cjwatson/src/ubuntu/seeds/dapper/desktop: * python-mysqldb
[08:14] <pitti> mdz: libmysqlclient is uninstallable
[08:14] <pitti> -14
[08:14] <Kamion> yay python \o/
[08:15] <pitti> Kamion: oh, nothing more? heaps of packages depend on the lib, I expected more...
[08:15] <doko> Kamion: just remove python-mysqldb from the seeds for now?
[08:15] <Kamion> pitti: could be, haven't checked
[08:15] <Kamion> doko: it's about as fast to fix mysql, I think
[08:16] <Kamion> I'm not in the mood for workarounds just at the moment; we have time to do it right
[08:16] <mdz> pitti: ah
[08:17] <Kamion> doko: and indeed there's also python2.4-librdf
[08:24] <ajmitch> morning
[08:24] <Nafallo> morning ajmitch :-)
[08:24] <slomo> hi ajmitch :)
[08:24] <pitti> Kamion: ok, I hope I fixed it; package is building now
[08:29] <Kamion> anyone know how I identify whether a device is a CD-like drive or not?
[08:30] <pitti> yep
[08:30] <pitti> Kamion: there should be a 'media' attribute in sysfs
[08:31] <Kamion> can't see one
[08:31] <Kamion> 'find /sys/ -name media' returns nothing
[08:31] <pitti> Kamion: erm, sorry - /proc/ide/<blockdev>/media
[08:32] <Kamion> will it always be 'cdrom'?
[08:32] <pitti> Kamion: it is 'disk' for hard drives, 'cdrom' for cdroms
[08:32] <Kamion> it seems to be missing for this hard drive
[08:32] <pitti> hmm
[08:32] <Kamion> oh, duh, because it's SATA
[08:32] <Kamion> what about for SCSI CD drives?
[08:32] <pitti> Kamion: that's at least what udev relies on
[08:33] <pitti> Kamion: SCSI: sysfs helps there, CD-ROMs are block devices type '5'
[08:33] <Kamion> this is going to be a real mess to do from C
[08:34] <pitti> Kamion: no idea about USB ones - maybe they behave like SCSI
[08:34] <Kamion> /sys/block/*/device/type ?
[08:34] <pitti> Kamion: should be
[08:34] <pitti> Kamion: however, no SCSI cdrom here
[08:35] <Kamion> for a change I was actually sort of hoping for an ioctl :-)
[08:35] <pitti> Kamion: however, for my USB flash drive, /sys/block/sda/device/type == 0
[08:36] <pitti> Kamion: hmm, wait, we might try something else
[08:36] <Kamion> I suspect randomly issuing CDROM_DRIVE_STATUS to see what happens isn't a great idea?
[08:36] <pitti> Kamion: which CD-ROM types do you have?
[08:36] <Kamion> pitti: personally? just IDE
[08:36] <pitti> me too
[08:36] <pitti> hmm
[08:36] <pitti> Kamion: CDROM_GET_CAPABILITY could also work
[08:37] <Kamion> ooh, probably quicker
[08:37] <pitti> Kamion: http://people.ubuntu.com/~pitti/scripts/cdcaps.py
[08:38] <pitti> Kamion: that gives me an "invalid argument" for HDs and a proper capability value for CD-ROMs
[08:38] <pitti> Kamion: that needs cdrom group privilege, though, so not everybody can do it
[08:38] <Kamion> that's fine, in this context I'm root
[08:39] <Kamion> (this is in parted_devices in the installer)
[08:39] <pitti> ah
[08:41] <Nafallo> Kamion: wxwidgets rebuilt on powerpc, could you give back tipptrainer for me please? :-)
[08:42] <Kamion> Nafallo: not right now, ask lamont or infinity
[08:42] <Kamion> buried in code
[08:42] <Nafallo> oki, I understand.
[08:42] <Nafallo> lamont-away, infinity: wxwidgets rebuilt on powerpc, could one of you give back tipptrainer for me please? :-)
[08:43] <lamont-away> Nafallo: dopnme
[08:44] <Nafallo> lamont-away: meaning done? :-)
[08:45] <lamont-away> yeah - damn keyboard has extra keys on it. :-)
[08:46] <Nafallo> thanx :-)
[08:51] <pitti> Kamion: yay, mysql works. I upload it now
[08:52] <Kamion> pitti: thanks a million for the CD help, looking good
[08:53] <pitti> \o/
[08:53] <pitti> so mysql is the last issue?
[08:53] <Kamion> so far ...
[08:55] <Kamion> I'm leaving RSN though, promised to meet Kirsten at 8pm and I'm already going to be late
[09:04] <mae> how can i regenerate the hostkey for ssh
[09:04] <mae> sshd
[09:06] <ogra> mae, thats a #ubuntu question, man ssh-keyscan
[09:07] <Kamion> no, man ssh-keygen
[09:08] <ogra> Kamion, why not keyscan ? 
[09:08] <Kamion> because that scans keys, it doesn't generate them
[09:08] <Kamion> and it scans keys from other hosts, too
[09:08] <ogra> oh, i thought it also generates
[09:09] <Kamion> anyway, partman fixed, I'm off for a while, see you
[09:09] <ogra> sorry for the misinfo then
[09:12] <mdz> pitti: are we ready to attempt new CD builds?
[09:13] <pitti> mdz: mysql is uploaded, but yet built
[09:13] <mdz> pitti: ok, once it's installed I'll turn the crank
[09:38] <mdz> pitti: only powerpc in so far
[09:38] <pitti> mdz: almost there
[09:39] <pitti> mdz: amd64 is in accepted
[09:40] <pitti> mdz: i386 debs arriced :)
[09:41] <seb128> re
[09:41] <seb128> cool, e-d-s/evo/panel ppc are built now
[09:42] <seb128> lamont-away: thanks for dep-wait/retry
[09:43] <pitti> mdz: when are the cron.dailies again?
[09:47] <seb128> pitti: you have a dapper ppc?
[09:47] <pitti> seb128: not an up to date one
[09:47] <pitti> seb128: but I can upgrade it
[09:49] <mdz> pitti: :03 and :33
[09:51] <seb128> pitti: don't bother
[09:51] <seb128> pitti: jbailey got a "ERROR: Unbound variable: make-mutex" when running "/usr/games/sol --variation freecell", I was just curious to know if that happen for everybody on ppc
[09:53] <Nafallo> jbailey: :-)
[09:54] <pitti> jbailey: I *had* to play a round of planetpelgiun-racer today to test the new SDL merge :)
[09:54] <pitti> penguin, even
[09:54] <jbailey> pitti: Yeah, I miss the old days where the best network tester we had was doom. =)
[09:55] <lamont-away> seb128: np
[09:56] <pitti> fooishbar: Hi Daniel! Why another nick today?
[09:56] <jbailey> pitti: Stalker.
[09:56] <ajmitch> jbailey! :)
[09:56] <jbailey> ajmitch: Hey!  You back in .nz now?
[09:56] <ajmitch> yeah
[09:56] <ajmitch> got back yesterday
[09:56] <daniels> (whoops)
[09:57] <ajmitch> :)
[09:58] <Nafallo> daniels: morning :-)
[10:03] <pitti> mysql-client-4.1 | 4.1.15-1ubuntu1 |        dapper | amd64, i386, powerpc
[10:04] <pitti> mdz: GO, Matt! :)
[10:04] <mdz> going
[10:04] <Nafallo> :-)
[10:05] <mdz> er, cron.daily isn't finished yet
[10:05] <mdz> so this is unlikely to work
[10:06] <mdz> killing it
[10:12] <Nafallo> daniels: ping :-)
[10:12] <daniels> Nafallo: pong
[10:13] <Nafallo> will we have libxaw8-dev in the dappercycle?
[10:13] <daniels> nope, never
[10:13] <daniels> if I get my way
[10:14] <Nafallo> oki, I'll continue to add ubuntu1 on the stuff that dep-waits on it then :-)
[10:14] <daniels> there shouldn't be much at all?
[10:14] <Nafallo> three packages yet. don't know how many all of them are.
[10:14] <mdz> pitti: ok, really building now
[10:15] <ogra> yay
[10:15] <Nafallo> but I'll upload them when I have them all :-)
[10:15] <daniels> Nafallo: cool, thanks
[10:15] <Nafallo> np
[10:23] <dholbach> have a nice evening
[10:34] <mdz> lamont-away: me
[10:34] <mdz> lamont-away: how badly is it broken?
[10:34] <lamont-away> ppc still had uninstallables
[10:35] <lamont-away> amd64/i386 hit the jackass-timing-window
[10:35] <lamont-away> amd64 hit it first thing, i386 hit it at the very end
[10:35] <lamont-away> that is, a rebuild on i386 should work just fine
[10:35] <lamont-away>   ubuntu-desktop: Depends: python-mysqldb but it is not going to be installed
[10:35] <lamont-away>                   Depends: python2.4-librdf but it is not going to be installed
[10:35] <lamont-away> that was ppc
[10:35] <mdz> that should be fixed in the current archive
[10:36] <mdz> my livefs build script seems to have been broken by the recent changes
[10:36] <mdz> please kick off new builds
[10:36] <lamont-away> ppc is installable now.
[10:37] <lamont-away> mdz: running now - just building ubuntu, did you also want base/kubuntu now, or later?
[10:37] <mdz> lamont-away: immediately after would be grand
[10:37] <lamont-away> mdz: ok
[10:37] <mdz> lamont-away: now that we're mailing failures, can I get on that mailing list?
[10:39] <spity> hi
[10:41] <lamont-away> mdz: shortly
[10:45] <spity> i guess you've already read this http://lists.debian.org/debian-release/2005/11/msg00080.html - how will that affect ubuntu?
[10:45] <lamont-away> mdz: your @u.c address added to the target for any failed datacenter livecd build
[10:45] <ajmitch> spity: already discussed on ubuntu-devel
[10:46] <spity> whoops, i must have missed that, sorry
[10:46] <ajmitch> we have a nice list of packages to rebuild :)
[10:46] <lamont-away> Adding system user `cupsys'...
[10:46] <lamont-away> Adding new user `cupsys' (100) with group `lpadmin'.
[10:46] <lamont-away> chage: the shadow password file is not present
[10:46] <lamont-away> adduser: `/usr/bin/chage -M 99999 cupsys' returned error code 15.  Aborting.
[10:46] <lamont-away> dpkg: error processing cupsys-client (--configure):
[10:46] <lamont-away>  subprocess post-installation script returned error exit status 2
[10:46] <lamont-away> mdz: ^^
[10:47] <lamont-away> Setting up cupsys-client (1.1.23-10ubuntu4) ...
[10:47] <lamont-away> addgroup: Couldn't parse `/etc/adduser.conf':29.
[10:47] <lamont-away> that might be the root of that....
[10:48] <spity> ajmitch: do you remember name of that thread?
[10:48] <mdz> lamont-away: what happened to /etc/adduser.conf?
[10:50] <sistpoty> spity: maybe this one? "library renaming due to changed libstdc++ configuration" (11/14)
[10:50] <lamont-away> mdz: that's just it - it looks fine....
[10:51] <lamont-away> FIRST_SYSTEM_UID=100
[10:51] <lamont-away> that's line 29
[10:51] <lamont-away> for example
[10:52] <spity> sistpoty: oh, i'm blind :) thanks
[11:03] <lamont-away> neato.  hppa livecdfs built
[11:05] <mdz> lamont-away: but not the others?
[11:07] <lamont-away> mdz: adduser.conf is barfing on every line that has an underscore in the LHS token name
[11:07] <lamont-away> and only on those lines
[11:08] <mdz>         if ((($var, $val) = /^\s*(\S+)\s*=\s*(.*)/) != 2) {
[11:08] <mdz>             warnf(_("Couldn't parse %s:%s.\n"),$conf_file,$.);
[11:08] <mdz> looks pretty reasonable to me
[11:08] <mdz> is its locale fucked?
[11:09] <lamont-away> locale should be 'POSIX'
[11:10] <mdz> can't reproduce here
[11:10] <mdz> has to be something with the build environment
[11:11] <ogra> shadow was broken very recently, is this the fixed version ?
[11:13] <lamont-away> kicking another run that'll dump env at the start of the build
[11:15] <sajd> I got the same adduser.conf warnings during depper updates today, one warning for every non-comment line
[11:16] <mdz> oh, you're right, it's only a warning
[11:20] <mdz> lamont-away: ah, my adduser was out of date
[11:20] <mdz> can reproduce the warning now
[11:20] <lamont-away> Adding new user `cupsys' (100) with group `lpadmin'.
[11:20] <lamont-away> chage: the shadow password file is not present
[11:20] <lamont-away> adduser: `/usr/bin/chage -M 99999 cupsys' returned error code 15.  Aborting.
[11:21] <lamont-away> that'd be the fatality
[11:21] <mdz> lamont-away: it doesn't prevent adduser from doing the right thing, though
[11:21] <mdz> yeah
[11:21] <mdz> mizar:[~]  sudo chage -M 99999 cupsys
[11:21] <mdz> mizar:[~]  echo $?
[11:21] <mdz> 0
[11:22] <lamont-away> note the lack of /etc/shadow in the livecdfs
[11:22] <mdz> Version: 1:4.0.13-6ubuntu1
[11:22] <mdz> chage failing if /etc/shadow is missing seems like reasonable behaviour
[11:22] <lamont-away> so /etc/shadow is now required on all ubuntu systems?  wasn't in breezy
[11:23] <mdz> perhaps cupsys didn't call chage before
[11:23] <pitti> mdz: cupsys is still the same as breezy
[11:23] <mdz> dunno then
[11:23] <ogra> adduser, shadow and coreutils changed ...
[11:24] <mdz> lamont-away: can you test in a breezy chroot?
[11:24] <mdz> whether it's chage which changed 
[11:25] <lamont-away> mdz: I just updated my hppa chroot, and coreutils was the upgrade - rerunning the livecd build there to see if it now dies.
[11:27] <lamont-away> which is to say, testing a dapper livecd build in a breezy chroot is (a) non-trivial and (b) would require me to use a buildd as a devel machine (mucking about evily), which I've promised elmo I won't do.
[11:28] <jbailey> lamont-away: Wow.  How many toenails were removed before that promise came out? =)
[11:28] <mdz> lamont-away: just confirmed the same chage behaviour on breezy
[11:29] <mdz> "chage: the shadow password file is not present
[11:29] <mdz> " and exit status 3
[11:29] <lamont-away> jbailey: none - I promised myself that about the same time elmo asked for.
[11:29] <lamont-away> mdz: so wth???
[11:30] <mdz> lamont-away: you're sure shadow didn't exist before?
[11:30] <Nafallo> daniels: what's the replacement for xviewg-dev? :-)
[11:30] <mdz> lamont-away: oh
[11:30] <mdz> lamont-away: new adduser calls chage
[11:30] <lamont-away> ah, that'd do it
[11:31] <mdz> lamont-away: however
[11:31] <mdz> it's supposed to cope
[11:31] <mdz>   * versioned depends on passwd >> 1:4.0.12 because of the changed
[11:31] <mdz>     chage exit code (now, 15) in the "shadow passwod not enabled"
[11:31] <mdz>     case. Earlier versions return 3 or even a normal 1 in that case.
[11:31] <Nafallo> daniels: never mind.
[11:31] <mdz>     if (&systemcall('/usr/bin/chage', '-M', '99999', $new_name)) {
[11:31] <mdz>         if( ($?>>8) ne 15 ) {
[11:32] <mdz> lamont-away: can you check the exit code being given by chage in your chroot, and the version of passwd?
 adduser: `/usr/bin/chage -M 99999 cupsys' returned error code 15.  Aborting.
 that'd be the fatality
[11:32] <lamont-away> looks like '15'
[11:32] <mdz> lamont-away: I think that 'ne' should be a '!='
[11:32] <lamont-away> so string compares would be bad there, eh?
[11:33] <pitti> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339670
[11:38] <lamont-away> mdz: so we're waiting on a new adduser then>?
[11:38] <mdz> lamont-away: testing
[11:40] <lamont-away> mdz: I need to run off, so you'll need to kick the builds...
[11:40] <mdz> lamont-away: ok
[11:40] <lamont-away> terranova, royal, king: bin/BuildLiveCD ubuntu
[11:41] <lamont-away> or 'bin/BuildLiveCD ubuntu kubuntu base'
[11:41] <mdz> I'm having one of those moments where i've fixed the bug but this bit of code isn't actually running
[11:41] <lamont-away> and it'll build all 3, in that order.
[11:41] <lamont-away> hehe
[11:41] <mdz>         if( ($?>>8) != 15 ) {
[11:41] <mdz>             print "HELLO HELLO2\n";
[11:41] <mdz> doesn't print HELLO HELLO2
[11:42] <mdz> aha
[11:42] <mdz> sub systemcall {
[11:42] <mdz>     my $c = join(' ', @_);
[11:42] <mdz>     print ("$c\n") if $verbose==2;
[11:42] <mdz>     if (system(@_)) {
[11:42] <mdz>         die ("$0: `$c' returned error code " . ($?>>8) . ".  Aborting.\n")
[11:42] <mdz>           if ($?>>8);
[11:42] <mdz> yay for adduser
[11:43] <Diablo-D3> hey guys
[11:44] <Diablo-D3> any word on when vim will get fixed?
[11:44] <daniels> could you possibly be any less specific?
[11:44] <mdz> Diablo-D3: mu
[11:44] <lamont-away> Diablo-D3: this is the channel where you would propose your patch to fix it.
[11:44] <Diablo-D3> daniels: yup, but it might take a bit of effort.
[11:44] <gonso> hey all!  this the right place for laptop-related questions?  web site pointed to this channel.
[11:44] <lamont-away> #ubuntu is where you'd ask your question
[11:44] <Diablo-D3> gonso: try #ubuntu-laptop
[11:45] <Diablo-D3> lamont-away: I'd propose a patch, but I'm not sure whats going on
[11:45] <mdz> Diablo-D3: it's working fine here
[11:45] <Diablo-D3> all the files have been moved to /usr/share/vim/vim64 yet vim is still looking in /usr/share/vim/vim63
[11:47] <daniels> if you have a detailed bug report, please file one (and no, 'vim doesnt work' does not count) at https://bugzilla.ubuntu.com/enter_bug.cgi?product=Ubuntu
[11:47] <Diablo-D3> daniels: its already been filed afaik
[11:47] <Diablo-D3> but I cant find it
[11:47] <Diablo-D3> but I know I've seen it
[11:47] <Diablo-D3> daniels: that, and arent we supposed to use launchpad for everything now?
[11:47] <daniels> so search on vim.  spamming the development channel is not the answer.
[11:47] <daniels> not yet, no.
[11:48] <mdz> uploaded adduser 3.78ubuntu1
[11:48] <daniels> Diablo-D3: if you're not going to remain on-topic, please leave.
[11:49] <LaserJock> Kamion: ping?
[11:49] <sebest> hello, what is the status of dot ubuntu
[11:49] <mdz> daily CD build looks good from the outside
[11:49] <Diablo-D3> daniels: why must you always attempt to pick a fight? you know this is why quite a few people don't like you.
[11:49] <mdz> LaserJock: he's off for the night
[11:49] <mdz> Diablo-D3: please keep the noise in this channel to a minimum
[11:49] <LaserJock> mdz: darn, thanks though
[11:50] <Diablo-D3> mdz: this is what I'm asking daniels to do.
[11:50] <daniels> sebest: if there's any new movement, it will almost certainly be documented at the spec page.  if there's nothing there, then there's almost certainly been no movement on the spec.
[11:50] <sebest> daniels, thanx i asked because i thought the spec wasn't update since ubz
[11:51] <Kamion> mdz: you didn't start install CD builds before archive-copier and partman-base were built, did you?
[11:51] <mdz> Kamion: what versions do we need?
[11:52] <Kamion> hm, looks ok
[11:52] <Kamion> LaserJock: yes?
[11:52] <mdz> Kamion: aren't you supposed to be at the pub?
[11:52] <Kamion> mdz: I was
[11:53] <LaserJock> Kamion: I have found some source packages that don't have a "Section:" in them. They are in the debian-installer section on debian
[11:53] <elmo> ok, so if I do Build-Depends: foo, bar 
[11:53] <elmo>  blah
[11:53] <LaserJock> Kamion: crimun suggested that I talk to you about it
[11:53] <Kamion> LaserJock: nobody in their right mind cares about source packages without sections
[11:53] <elmo> ok, so if I do Build-Depends: foo [anarch] , bar (>= 1) | foo (>= 1), if apt and/or sbuild will DTRT?
[11:54] <mdz> elmo: meaning install bar even on anarch?
[11:54] <Diablo-D3> http://bugzilla.ubuntu.com/show_bug.cgi?id=19783
[11:54] <Diablo-D3> if anyone cares.
[11:54] <elmo> oh, sorry, foo c/r/provides bar
[11:54] <LaserJock> Kamion: so it's not a problem?
[11:54] <Kamion> LaserJock: no
[11:54] <elmo> mdz: meaning you must install foo on 'anarch', but bar or foo will do elsewhere
[11:55] <Kamion> unless you can explain something concrete it breaks rather than "I noticed an inconsistency"
[11:55] <mdz> elmo: yeah, should work 
[11:56] <Kamion> argh, grub still isn't on current CDs
[11:56] <mdz> hmm, awty doesn't cope with a lack of d-i daily builds
[11:57] <mdz> ;-)
[11:57] <Kamion> good call
[11:57] <ogra> heh
[11:58] <sistpoty> so i can't ask about my dapper's bird flu here?
[11:58] <Diablo-D3> -_-
[11:58] <Diablo-D3> sistpoty: thats not even funny to joke about
[11:58] <sistpoty> sorry
[11:58] <Diablo-D3> we all know there are no viruses for linux.
[11:59] <mdz> sistpoty,Diablo-D3: please, we're trying to get some work done in here
[11:59] <sistpoty> again: sorry
[12:00] <Kamion> (install CD rebuild running)
[12:00] <mdz> Kamion: seems much faster now
[12:00] <Kamion> 15 minutes instead of an hour or so, yeah
[12:01] <daniels> mdz: can you remember if stripping trailing spaces from a #define is considered bad form? it is, yeah?