[00:41] <Jimi__Hendrix> Chipzz define bootstrapping...and i have till march to do this...so ive got plenty of time...
[01:36] <slangasek> lamont: hmm, why did bind9's binary packages all get fatter in jaunty?
[01:36] <slangasek> or should I be directing that question at kees/doko?
[01:42] <lamont> slangasek: define "fatter"
[01:43] <slangasek> lamont: bind9-host is 30% bigger in jaunty than intrepid, with no difference in file contents
[01:43] <slangasek> s/file/package/
[01:44] <lamont>   * dig: add -DDIG_SIGCHASE to compile options.  LP: #257682
[01:44] <lamont>   * enable largefile support.  Closes: #497040
[01:44] <lamont> otherwise, nfc
[01:44] <slangasek> the package is only 61K in total so it's not a major issue by itself, but I'm trying to figure out if it's a local change or a sign of changes that are giving us fatter binaries in general
[01:44] <slangasek> ok, thanks; time to test builds in a chroot
[01:44] <lamont> I haven't really looked
[02:01] <Chipzz> bug 257682
[02:02] <lamont> Chipzz: yep.  that's the bug alright
[02:04] <Chipzz> lamont: wanted to take a look at it myself :P
[02:04] <lamont> heh
[02:05] <Chipzz> I was just wondering, ubotu should probably generate those links automatically when someone says "LP: #xxxxx"
[02:07] <Chipzz> heh
[02:07] <Chipzz> bug 497040
[02:07] <Chipzz> weird
[02:25] <slangasek> lamont: curiously, if I do a local rebuild, bind9-host comes out even larger...
[02:25] <slangasek> with dpkg-buildpackage -B
[02:25] <lamont> interesting
[02:26] <slangasek> oh, langpack stripping maybe?
[02:26] <lamont> yeah - possibly
[02:26] <slangasek> hmm, no
[02:26] <lamont> Chipzz: debian bug 497040
[02:27] <slangasek> lamont: right, don't use 'du' to compare file sizes across systems with different block sizes :)
[02:39] <Chipzz> lamont: ah heh. fail on my part :P
[02:39] <lamont> slangasek: heh
[03:04] <slangasek> lamont: right, so rebuilding the intrepid package with the jaunty toolchain also gives a smaller package, so I guess one of the changed build options means a significant code size increase
[03:05] <lamont> slangasek: git clone git://git.debian.org/~lamont/bind9.git
[03:05] <slangasek> hmm?
[04:02] <lamont> slangasek: that has the entire history if you wanna bisect the changes... :)
[04:02] <lamont> though there aren't really that many of htem
[04:02]  * lamont sleeps
[04:21] <bryce> slangasek: btw for alpha-2 could you include in the release notes a known-issue with i8xx chips (bug #304871)
[04:22] <bryce> slangasek: we might be able to get a fix in for alpha-2, but I think i8xx gfx users should hold off on upgrading a bit until it's sorted out
[04:53] <slangasek> bryce: ok, noted
[04:53] <slangasek> lamont: apparently it's the DIG_SIGCHASE change that does it
[04:54] <slangasek> ArneGoetje: FYI, the change in ttf-arphic-uming to select dpkg compression based on dist name doesn't work
[04:55] <LaserJock> anybody know offhand a page that clearly says what Ubuntu's security support policies are?
[04:56] <slangasek> ArneGoetje: I'm not sure the buildds use ubuntu-minimal, which would mean lsb-release is only installed if you build-depend on it
[05:02] <ArneGoetje> slangasek: so, your suggestion would be to build-depend on lsb-release?
[05:03] <slangasek> ArneGoetje: yeah (just uploaded with that change)
[05:03] <ArneGoetje> slangasek: ok, thanks
[05:03] <slangasek> ArneGoetje: and I see we've deliberately dropped the lzma option for ttf-kochi, but ttf-kochi is still on the CDs - what binary packages should replace ttf-kochi-{gothic,mincho}?
[05:04] <ArneGoetje> slangasek: ttf-sazanami-{gothic,mincho}
[05:06] <slangasek> ah, already changed in the seed and just needs an upload :)
[07:18] <dholbach> good morning
[08:14] <Tonio_> hi
[08:15] <tkamppeter> pitti, hi
[08:55] <pitti> Good morning
[08:55] <pitti> tkamppeter: hey
[08:56] <lool> Hey pitti
[08:56] <lool> pitti: had a good trip?
[08:56] <pitti> everyone landed safely again? /me had a very broken trip
[08:56] <lool> what happened?
[08:56] <pitti> lool: most improbable EVER
[08:57] <pitti> lool: in our plane in SF, the door didn't close, which meant 4 hours delay; after 2 hours we left the plane again
[08:57] <pitti> and guess whom we ran into
[08:57] <pitti> mvo, ogra, and the other dudes which took the other plane 40 mins earlier
[08:57] <pitti> whose plane broke as well, in a much more scary manner
[08:58] <pitti> and then in Frankfurt I had to stand in line for 2.5 hours to get my ticket rebooked
[08:58] <tkamppeter> pitti, I have an SRU for bug 306125 and bug 288570. Can you improve the Intrepid tasks of these bugs?
[08:58] <lool> pitti: Sounds fun   :-/
[08:59] <pitti> eww, wiki.u.c. down?
[08:59] <lool> pitti: Doesn't respond for me either
[09:00] <pitti> I get a 503 Service Unavailable
[09:00] <lool> I get a timeout; are you using a proxy?
[09:00] <Koon> I got a few 500 this morning.
[09:00] <Koon> and now it's a timeout.
[09:02] <Koon> Now I got 503
[09:02] <pitti> tkamppeter: done
[09:03] <tkamppeter> pitti, thanks, will upload the new gs to -proposed. Please pass it through.
[09:07] <tkamppeter> pitti, new gs is uploaded. Can you pass it through, thanks.
[09:07] <pitti> will process the queue later
[09:24] <Chipzz> where can I ask for some help with a udev problem? I know, #ubuntu for support, but I'm highly unlikely to get meaningfull help there on that subject :P
[09:24] <StevenK> pitti: Are you planning to do the libspe2 merge on main-manual?
[09:40] <pitti> oh, I didn't even look at that; I touched libspe2?
[09:49] <StevenK> pitti: According to MoM, you did
[10:26] <tkamppeter> pitti, CUPS is still hanging in the -proposed queue (on bug 271350) and I have already two new bugs to SRU. How should we proceed?
[10:26] <tkamppeter> In the bug one person reported that the patch works for him in Jaunty and I have the patched version on a normal PC and no regressions.
[10:27] <pitti> tkamppeter: it's there for 19 days already; it should really get tested
[10:27] <pitti> some feedback about "still works for me"
[10:30] <tkamppeter> pitti, what do you mean with 'some feedback about "still works for me"'?
[10:30] <pitti> tkamppeter: I won't move it to -updates without anyone saying "that version still works for me"
[10:32]  * pitti upgrades his wife's computer to that version
[10:32] <tkamppeter> pitti, so I add the fixes for the two other bugs, creating a 2ubuntu5 and if the testers of the two other bugs are completely content, we put up 2ubuntu5.
[10:53] <pitti> tkamppeter: yes
[10:53] <pitti> tkamppeter: but before I'd like to move 4 to -updates
[11:00] <tkamppeter> pitti, the bugs which I want to fix with 2ubuntu5 are bug 286048, bug 300312, bug 244840, and bug 47649.
[11:00] <tkamppeter> pitti, it would be great if the reporters of these bugs could start to test now.
[11:01] <pitti> tkamppeter: I might also have a fix for bug 237256 in time
[11:01] <tkamppeter> pitti, great. How do you fix that one.
[11:03] <tkamppeter> pitti, can you approve the Intrepid tasks of the bugs I mentioned above?
[11:04] <pitti> tkamppeter: replied to 237256
[11:05] <pitti> tkamppeter: done
[11:06] <tkamppeter> pitti, you simply added "/usr/Brother/** Ux" to the AppArmor file?
[11:08] <tkamppeter> pitti, thanks for approving the Intrepid tasks.
[11:09] <pitti> Keybuk, kees: on whose plate is the d-bus (security/new version) update?
[11:10] <Keybuk> mine
[11:10] <Keybuk> it's not urgent, as far as we can tell there's no escalation you can get from it
[11:10] <Keybuk> and the fix is as bad as the cure
[11:11] <tkamppeter> pitti, I think, if we put 2ubuntu5 into -proposed now, we once get a lot of other fixes tested and second, we get the patch of bug 271350 regression-tested by the reporters of the other bugs. WDYT?
[11:11] <pitti> tkamppeter: *shrug* WFM
[11:15] <tkamppeter> pitti, WFM? "Works for me"? "Wait for me"?
[11:15] <pitti> tkamppeter: "works for me"
[11:17] <DktrKranz> doko: when you have some spare time, mind looking/commenting at bug 254790? Thanks.
[11:23] <tkamppeter> pitti, so can you give me your fix for Brother then and I will upload 2ubuntu5?
[11:34] <soren> Keybuk: I'm playing a bit around with some shared storage and I was wondering if you've given any thought to the problems that will inevitable arise when e.g. a virtual machine puts a raid superblock onto its block devices and these are e.g. shared over iscsi and appear on multiple hosts.
[11:52] <Keybuk> soren: what kind of problems are you expecting?
[11:53] <soren> Keybuk: Each host will notice the raid superblock and configure the raid set... Right?
[11:54] <Kano> hi, what allows u to mount hd partitions without fstab entry?
[11:54] <soren> Keybuk: Same problem with lvm. The lvm udev rules call "lvmchange -ay" (without naming the volume group). I'm not sure if that actually does anything or just marks it as active in the kernel.
[11:55] <Keybuk> pitti: am tracking the d-bus issue on bug #30632
[11:55] <Keybuk> err
[11:55] <Keybuk> pitti: am tracking the d-bus issue on bug #306362
[11:56] <Keybuk> the issue is that just about every existing dbus policy file is wrong in some way
[11:56] <Keybuk> so if we upload the "fixed" version of d-bus, every service will break
[11:56] <Keybuk> and worse, services will break because *other* policy files are broken
[11:57] <Keybuk> e.g. say that /etc/dbus-1/service.d/foo.conf has
[11:57] <Keybuk>   <policy context="default">
[11:57] <Keybuk>     <deny receive_interface="com.ubuntu.Frob"/>
[11:57] <Keybuk>   </policy>
[11:57] <Keybuk> that means
[11:57] <Keybuk> "by default, deny ANY SERVICE from receiving messages for the com.ubuntu.Frob interface
[11:58] <Keybuk>  AND, since we have denied interfaces, deny ANY SERVICE from receiving messages _with_no_interface_set_"
[11:58] <Keybuk> (sending messages without the interface set is default for things like Python)
[11:58] <Keybuk> assumedly what they really meant was
[11:58] <Keybuk>     <deny receive_destination="com.ubuntu.Frob"/>
[11:58] <Keybuk> or
[11:58] <Keybuk>     <deny receive_destination="com.ubuntu.Frob" receive_interface="com.ubuntu.Frob"/>
[11:59] <Keybuk> though if you have the former, you don't need the latter
[12:00] <Keybuk> also almost nobody allows people to receive their signals ;)
[12:08] <soren> Keybuk: My only idea to prevent the raid (and similar) problems is to keep a list of uuid's that udev should just ignore and then figure out a way to export such a list from libvirt, but perhaps you have a more clever approach up your sleave?
[12:12] <Keybuk> pitti: oh, and note that the D-Bus upstream stance is now to revert all the security fixes and go back to open with logging ;)
[12:12] <Keybuk> soren: why should udev ignore them?
[12:13] <Keybuk> you still want them in the udevdb and still want them in /dev surely?
[12:13] <soren> Keybuk: Not really.
[12:13] <Keybuk> why not?>
[12:13] <Keybuk> I don't understand why you'd want a connected device which udev doesn't know about?
[12:13] <soren> Keybuk: Well, I suppose it depends on what you refer to by "them". :)
[12:13] <Keybuk> if it's in /sys, there's no reason it shouldn't be in /dev
[12:14] <soren> I want to have access to the raw block devices, but not configure the raid sets or lvm vg's that might be on there.
[12:14] <Keybuk> you generally want a match between /sys/dev/block <=> /dev/block and /sys/dev/char <=> /dev/char
[12:14] <Keybuk> ah, I see what you mean
[12:15] <Keybuk> you want the top-level block device to appear, but don't want to run mdadm and/or lvm on it?
[12:15] <soren> Right.
[12:15] <Keybuk> what heuristic would you follow to decide that?
[12:15] <soren> My specificu use case is virtual machines, so exporting some sort of list from libvirt would be a good start.
[12:17] <Kano> soren: can you tell me how the mounting works without fstab entry for hd partitions?
[12:18] <Keybuk> soren: if we have a blacklist, I'd use it to skip the entire "persistent" bit of the udev rules
[12:18] <soren> libvirt has a storage handling api. I'm expecting that people will use that to set up iscsi to get access to the shares.
[12:18] <Keybuk> e.g. /dev/disk/by-*, mdadm, lvm, etc.
[12:18] <Keybuk> even better if we could generate that blacklist in the form of udev rules in the first place
[12:18] <Keybuk> 59-blacklist.rules
[12:18] <soren> Keybuk: Ah, good idea
[12:18] <Keybuk> BLAH==BLAH, GOTO="symlinks_end"
[12:18] <Keybuk> 79-symlinks-end.rules
[12:19] <Keybuk> LABEL="symlinks_end"
[12:19] <soren> Keybuk: The target of GOTO doesn't need to be in the same file?
[12:19] <Keybuk> type thing
[12:19] <soren> That's convenient.
[12:19] <Keybuk> no, you can jump files with it
[12:19] <Keybuk> hell, you may want to just do
[12:19] <Keybuk> BLAH==BLAH, OPTIONS+="last_rule"
[12:19] <Keybuk> to prevent any further processing, including hal
[12:19] <Keybuk> in fact, I think last_rule is probably correct
[12:19] <Keybuk> otherwise you may still get hal automounting
[12:20] <soren> Yeah, that would suck.
[12:20] <soren> Hm... It won't suffice for lvm, though.
[12:21] <soren> 85-lvm calls "lvchange -a y" (with out the vg name), so next time it's triggered, any volume groups will be discovered and activated.
[12:21] <Keybuk> ah, true
[12:21] <Keybuk> I'm still waiting for incremental LVM
[12:21] <Nafallo> incremental?
[12:21] <Nafallo> how would that work?
[12:21] <Keybuk> Nafallo: instead of telling lvm "scan for new block devices and do what you want", you'd instead tell lvm "there's a new /dev/sda4 - do you want that?"
[12:21] <emgent> \sh: ping
[12:22] <Nafallo> Keybuk: ah. in that sense. that makes sense :-)
[12:22] <Keybuk> and lvm would only activate when it has all the pieces it needs
[12:23] <soren> Keybuk: Scanning alone should be fine, I suppose. As long as it doesn't get activated, we should be golden, right?
[12:23] <Nafallo> hmm. I have my lvms on raid ;-)
[12:23] <Nafallo> but I guess we can do the same for mdraid? :-)
[12:23] <Keybuk> right, "I have /dev/dm-0, do you want it?"
[12:24] <Keybuk> soren: we activate everything
[12:24] <soren> Keybuk: I realise.
[12:24] <soren> Hmm...
[12:25] <soren> I mean: If we can somehow change the lvm rules to make sure we don't activate certain vg's, we should be fine, even we can't prevent the block devices from being scanned.
[12:25] <soren> s/even/even though/
[12:25] <Keybuk> we don't have any ability to prevent activation
[12:25] <Keybuk> unless lvm has a conf file for taht
[12:26] <soren> vgchange -ay takes an argument.
[12:26] <Keybuk> of the specific device you want to activate, right?
[12:26] <Keybuk> not a list of ones you do *not*
[12:27] <soren> volume group.
[12:27] <soren> Right.
[12:27] <soren> Erm...
[12:27] <Keybuk> so that would break things ;)
[12:27] <soren> Ok, I see where you're going.
[12:27] <Keybuk> right now, lvm only works *because* we always activate
[12:28] <soren> Ok, what we need to do is to make vgscan ignore the relevant block devices altogether.
[12:29] <Keybuk> agree
[12:30] <soren> Cool. I'll look into that.
[12:30] <Keybuk> upstream is already working on something like that
[12:31] <Keybuk> (agk)
[12:33] <soren> Keybuk: Cool. I'll see if I can strike up a conversation with him.
[12:33] <soren> Keybuk: Thanks for your input!
[12:34] <Keybuk> I wouldn't expect it in this release
[12:35] <soren> My primary concern is really raid. I can imagine massive breakage from that. I don't see lvm as quite as high risk.
[12:35] <soren> ...but should definitely be fixed.
[12:35] <Keybuk> there is mdadm incremental support upstream
[12:35] <Keybuk> but we don't use it yet
[12:35] <Keybuk> so with mdadm, we scan and activate all devices on each new block device
[12:35] <soren> *blink*
[12:35] <soren> Really?
[12:36] <soren> I thought we did that incrementally.
[12:36] <Keybuk> nope
[12:36]  * soren needs to run out for an hour or so..
[12:36] <Keybuk> it's on my TODO list
[12:36] <Keybuk> but there's a lot of things on my TODO list ;)
[12:36] <Keybuk> if you want to take a stab, go for it
[12:37] <Keybuk> basically instead of calling mdadm within watershed, we would call mdadm --incremental for each block device
[12:37] <Keybuk> AIUI
[12:37] <Keybuk> needs lots of code reading and testing to make sure it'll do the right thing
[12:40] <lamont> slangasek: interesting... still, having SIGCHASE is a good thing
[13:35] <Keybuk> random thought of the day
[13:35] <Keybuk> on server, instead of having six gettys on different tty1s...
[13:35] <Keybuk> ...why don't we have just one tty/getty and run screen by default
[13:36] <cjwatson> I have actually had a real use (fairly frequently) for being able to get to different ttys without going through userspace, on a server hammered by load
[13:36] <cjwatson> my mail server doesn't have a lot of memory and occasionally SA kills it ...
[13:37] <Keybuk> ttys are in userspace though?
[13:37] <Keybuk> you still have to go through login. pam, shell, etc.
[13:37] <Keybuk> which is harder work than opening a new screen pty and running the shell in it
[13:37] <cjwatson> not if you've anticipated this possibility and already have something logged in with a tail of syslog
[13:38] <cjwatson> then it's just kernelspace
[13:38] <Keybuk> you'd have a screen logged in with a tail of syslog?
[13:38] <cjwatson> screen would have to get scheduled in order to switch to it
[13:38] <cjwatson> I wish this were a hypothetical problem for me :(
[13:38] <Keybuk> hmm. that's a reasonable point
[13:39] <cjwatson> (tail has to get scheduled too, but that's fairly likely to happen at *some* point between the box tanking and me noticing - often this turns out to be the crappy wireless driver for that box exploding)
[13:40] <Keybuk> tail's parent (the shell) has to be scheduled as well
[13:40] <cjwatson> for tail -f?
[13:40] <cjwatson> surely not
[13:40] <slangasek> directhex: tomboy appears to be the only app pulling a lot of mono 1.0 stuff into the CDs at present; is that something that's due to be "corrected"?
[13:40] <Keybuk> cjwatson: sure
[13:40] <Keybuk> if you kill your running tail
[13:40] <Keybuk> tail has to be scheduled to receive SIGTERM and do something about it
[13:41] <Keybuk> then the shell has to be scheduled to receive SIGCHLD and call wait()
[13:41] <cjwatson> oh, no, I just meant leaving tail -f running forever
[13:41] <Keybuk> and assumedly scheduled enough to show the next prompt and allow you to run something else (nice generally :p)
[13:41] <Keybuk> ah, you only wanted to read the tail?
[13:41] <Keybuk> I thought you meant having a handy logged-in-as-root shell somewhere that you happened to run tail in normally
[13:41] <Keybuk> ie. you switched, killed tail, then used that shell to rescue the box
[13:42] <Keybuk> though that also brings up an interesting point
[13:42] <cjwatson> I want to find out whether the answer is "leave it a few minutes and it'll sort itself out" or "need to battle with a root shell to fix stuff" or "need to reboot box"
[13:42] <cjwatson> or whatever
[13:42] <Keybuk> syslog is useful on servers, why *not* have it sent to a spare tty automatically?
[13:42] <cjwatson> it's a fairly significant time-saver
[13:42] <Keybuk> d-i style
[13:42] <cjwatson> I've always thought that was a good idea; I run it on tty<high>
[13:42] <Spads> I used to use tty24
[13:43] <Pici> Some might see it as a security breach to have a syslog taik setup automatically to a spare tty.
[13:43] <cjwatson> some might be wrong. if you have physical access then you have root
[13:44] <cjwatson> obviously if the machine is specially locked-down then you'd want to disable it
[13:44] <cjwatson> but that's not the common case and already requires other work
[13:44] <Spads> http://www.jerkcity.com/emu//jerkcity1110.html
[13:44] <Spads> (SFW)
[13:45] <Pici> heh
[13:47] <directhex> slangasek, yes, definitely. it's just a long slog, unfortunately
[13:47] <directhex> slangasek, http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO shows current progress
[13:48] <slangasek> directhex: thanks, I'll read up; it would be nice to get rid of the 1.0 stuff over the next couple of days, since that one change should be enough to get our CDs back down to size
[13:48] <directhex> slangasek, couple of days, i don't think will happen. sorry. we're working as best we can, both at the debian & ubuntu ends
[13:48] <slangasek> (or at least, to within spitting distance)
[13:49] <directhex> the *real* baddie is libgtk2.0-cil - but if we update that too early, it will break all untransitioned apps
[13:49] <slangasek> directhex: hmm.  I don't see an explanation on this page of what needs to be done to get tomboy from 1.0 -> 2.0?
[13:49] <directhex> slangasek, http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition
[13:50] <tjaalton> slangasek: hey, as you've probably noticed, I've uploaded xserver 1.6beta3 to jaunty. now the problem is that some old & exotic input drivers fail to build. mind if I drop them from -input-all for alpha2 so that it'd remain installable?
[13:50] <directhex> slangasek, basically the libs used by it need to be 2.0, as well as tomboy itself
[13:51] <slangasek> tjaalton: quantify "old and exotic" for me, please? :)
[13:51] <tjaalton> slangasek: -summa for instance, no real changes to the code since 2005
[13:52] <slangasek> directhex: so tomboy can't switch until gtk-sharp2 and gnome-sharp2 (and perhaps others) are transitioned?
[13:52] <tjaalton> ie. hardware that no-one using jaunty will miss ;)
[13:52] <directhex> slangasek, essentially, yes.
[13:53] <slangasek> tjaalton: hrm, that one's already in universe though, so presumably isn't a dep of -all?
[13:54] <slangasek> tjaalton: -input-all only depends on 6 input drivers, none of which look like they'd be a good idea to drop yet
[13:54] <slangasek> (IMHO)
[13:54] <tjaalton> slangasek: oh, haha
[13:54] <tjaalton> silly me then
[13:54] <directhex> slangasek, Laney & james_w`  have been working hard in helping those of us in pkg-mono get as much done as quickly as possible
[13:54] <tjaalton> carry on..
[13:57] <directhex> slangasek, most of the remaining apps are waiting for sync, with a couple of exceptions (RainCT needs to poke gbrainy, monodevelop hasn't been done yet, nant & ndoc are exceptionally difficult to do, ikvm is the most evil package in all of creation)
[13:57] <slangasek> have sync requests been filed?
[13:57] <slangasek> if so, I'll switch gears right now and take care of those
[13:57] <pitti> tkamppeter: Brother fix> I asked the submitter for testing it
[13:58] <directhex> on most of them. i need to wait for mirror push on a couple of them, as requestsync is bitching that they aren't in the archive
[13:58] <directhex> slangasek, the ones i filed have been ack'd. i don't know what delay there is after someone says "ACK" though
[13:58] <slangasek> "until an archive admin does them"
[13:59] <pitti> Keybuk: lol, so in the end we don't need to do a security update at all? :-)
[14:02] <cjwatson> could somebody review base-installer, partman-target, and user-setup for hardy-proposed? I'd like to get a roll-up ubiquity upload in for 8.04.2, and it ought to include those pending installer changes I think
[14:03] <directhex> slangasek, let me see whether there are any main libs it's safe to transition early (i.e. packages with no untransitioned rdeps)
[14:05] <fbond> Hi.  How can I tell which packages get security updates for the full five years in an LTS release?
[14:06] <directhex> slangasek, if you see slomo before i do, can you poke him and ask him which of his mono packages he's happy to pass to team maintenance? he's a bit of a bottleneck on some things right now
[14:06] <slangasek> directhex: ok.  also, can you point me at specific bug numbers for your outstanding sync requests?  nothing on my pending list looks mono-ish
[14:06] <directhex> fbond, do you have a gui on your system?
[14:07] <fbond> directhex: Sort of.  It's a pretty custom image with a light GUI that is deployed on digital signs.
[14:08] <fbond> directhex: That's why I asked the question the way I did.
[14:08] <fbond> directhex: Is there some kind of policy on this?  I keep getting heuristics from people.
[14:08] <directhex> fbond, "stuff in main"
[14:09] <fbond> directhex: Okay, thanks.
[14:09] <cjwatson> no, that isn't accurate unfortunately
[14:09] <cjwatson> "stuff that's server-ish"
[14:09] <directhex> it's not?
[14:09] <fbond> cjwatson: I figured as much...
[14:10] <cjwatson> I owe Nick Barcet some work to process the work he's been doing on defining this more tightly
[14:10] <fbond> cjwatson: Okay, sounds like I can only really count 3 years for my app.
[14:10] <fbond> Thanks.
[14:12] <slangasek> directhex: oh, perhaps the ones with '[mono2.0transition]' in the title ;)
[14:12] <directhex> slangasek, bug 308179, bug 307580, bug 307593, bug 307973, bug 307970
[14:12] <slangasek> directhex: got it - those will all be done shortly, then
[14:13] <directhex> and one more... 308180
[14:13] <slangasek> cjwatson: will have a look at those installer packages at the end of this sync run
[14:13] <directhex> FYI, the deps on ubuntu-dev-tools should be stricter. i get nasty errors running jaunty requestsync on hardy
[14:14] <directhex> i hope this newer python-launchpad-bugs fixes it
[14:15] <slangasek> directhex: gnome-rdp in ubuntu has a 0ubuntu5 version number but the bug doesn't discuss whether there are Ubuntu-local changes that we'll be stomping on with a sync?
[14:15] <slangasek> (bug #307593)
[14:16] <directhex> slangasek, according to the changelog, it should be synced now
[14:16] <slangasek> ok
[14:16] <directhex> "after Hardy this should be simply
[14:16] <directhex>       synced.
[14:16] <directhex>  -- Sebastian Dröge <slomo@debian.org>"
[14:17] <directhex> slangasek, and given the debian packager is 1) one of the main pkg-mono people 2) upstream, i'm inclined to think it's worth syncing from now on
[14:17] <cjwatson> slangasek: ta
[14:18] <cjwatson> slangasek: any objection to me bumping base-files to 8.04.2 in preparation?
[14:18] <slangasek> cjwatson: feel free
[14:19] <cjwatson> (it's a build-dep of debian-installer, you see)
[14:19] <directhex> aha, alpha 2. THAT's where this talk of cd space came from
[14:39] <slangasek> directhex: ok, syncs done except for gfax (since as dholbach notes, the tgzs don't match and a fake sync is needed)
[14:39] <slangasek> directhex: how far ahead does that move us? :)
[14:40] <directhex> slangasek, did you catch [14:13] <directhex> and one more... 308180 ?
[14:40] <slangasek> yes
[14:40]  * directhex updates wiki
[14:41] <cjwatson> https://bugs.launchpad.net/ubuntu-cdimage/+bug/140458/comments/33 any objection to me just doing that?
[14:41] <cjwatson> slangasek: I assume I should edit the files in MirrorMetalink/templates/ ?
[14:41] <apw> superm1, hey when you were seeing the ACPI: EC: stuff which kernel was that with, it is looking here like it is probabally resolved on the kernels i am running
[14:43] <directhex> slangasek, with all of the above packages done, then only the ones i named remain. i'll need to assess the impact of starting on libs "early", which i'll do once LP has a green light against all the previous syncs
[14:43] <slangasek> cjwatson: no objection / yes
[14:43] <slangasek> directhex: sorry, which are the ones you named? I seem to have lost track
 slangasek, most of the remaining apps are waiting for sync, with a couple of exceptions (RainCT needs to poke gbrainy, monodevelop hasn't been done yet, nant & ndoc are exceptionally difficult to do, ikvm is the most evil package in all of creation)
[14:44] <slangasek> ok
[14:45] <directhex> i don't know how much we care about breaking ikvm, i think gbrainy should survive libs being done..... i don't know about nant & ndoc's impact if the libs are done early
[14:47] <directhex> hm, i think i forgot one
[14:50] <Laney> tangerine?
[14:50] <Laney> oh, you win \o/
[14:50] <directhex> Laney, good guess! bug 308189
[14:50] <cjwatson> doko: are you planning a hardy upload for bug 288279? (8.04.2 is coming up soonish)
[14:50] <directhex> slangasek, sorry for missing that one
[14:51] <slangasek> directhex: no worries, syncing now
[14:53] <directhex> http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO looks a lot greener than it did an hour ago
[14:53] <slangasek> and gbrainy is not yet ready to sync?
[14:53] <slangasek> or is it?
[14:54] <directhex> nope. rainct wanted to ask upstream for a new version w/ minor fixes
[14:54] <directhex> you'll have to ask him - it's not a team-maintained package so we can't upload it willy nilly
[14:55] <slangasek> ok
[14:56] <directhex> slangasek, what does a fakesync involve, WRT gfax?
[14:56] <slangasek> directhex: manually applying the Debian diff to the Ubuntu tarball, signing and uploading
[14:57] <directhex> PITA
[14:58] <slangasek> yes, blame whoever diverged the tarball :)
[14:58] <cjwatson> this is why I was banging on about making sure the core stack tarballs are the same :)
[14:59] <directhex> cjwatson, they are! or i think they are
[14:59] <directhex> too lazy to md5sum them by hand, but we certainly coordinated that
[14:59] <cjwatson> wasn't saying they weren't
[14:59] <cjwatson> just saying that this is the problem I was trying to make sure we didn't encounter there as well
[14:59] <directhex> right
[15:00] <directhex> well, any volunteers to do the gfax fakesync? can you think of anyone, Laney?
[15:00] <directhex> ;)
[15:00] <slangasek> I can take care of it
[15:02]  * directhex checks whether any untransitioned apps will die from transitionedlibitis
[15:03] <Keybuk> pitti: we need to do something, but that something involves an audit of every single d-bus using package
[15:04] <directhex> gfax is the only 1.0 app remaining
[15:04] <directhex> well. the only one using libs outside the core mono stack, anyway
[15:07] <slangasek> directhex: ok, what next then? :)
[15:08] <directhex> slangasek, well, for minimizing delays? 0ubuntu1 the entire third third of the todo wiki
[15:08] <superm1> apw, i can give it a test if you've got a link to what you're running
[15:09] <slangasek> directhex: oh; that doesn't sound fun. :)
[15:09] <slangasek> directhex: how much of that needs to be done before tomboy benefits? most/all?
[15:09] <directhex> slangasek, what about f-spot?
[15:10] <apw> superm1, sure, i guess i should upload exactly what i have installed
[15:10] <slangasek> directhex: I don't know - how much does converting f-spot buy us in terms of CD space?
[15:10] <apw> tho. are you using 32 bit, i gues syou are
[15:10] <directhex> slangasek, tomboy, looks like gtk-sharp2, gnome-sharp2, mono-addins, ndesk-dbus, ndesk-dbus-glib
[15:10] <directhex> but that's scaning by eye
[15:10] <superm1> apw, yeah
[15:11] <apw> ok ... then any of the -11 kernels is basically the same, ie. contains the acpi fix that seems to fix me
[15:11] <directhex> f-spot needs libflickrnet and gnome-desktop-sharp2 in addition
[15:11] <directhex> i think that's it
[15:11] <apw> superm1, the ones here are worth testing: http://people.ubuntu.com/~apw/webcams1/
[15:12] <superm1> apw, okay i'll take a look in a little bit
[15:12] <apw> superm1, thanks for that
[15:23] <pitti> tkamppeter: do you think https://blueprints.edge.launchpad.net/ubuntu/+spec/printer-sharing is still relevant? it's one click in s-c-p now
[15:28] <slangasek> directhex: which order should those lib packages be done in? in the order you listed them?
[15:29] <directhex> slangasek, doesn't matter. as long as gfax is done, then there's no danger caused by the order, as the executable which gets executed determines which runtime mono tries to use (i.e. even if one of its deps becomes 2.0 whilst it still remains 1.0 itself, a lib will be 2.0ified at runtime if the app using it is 2.0)
[15:30] <tkamppeter> pitti, for Linux networks it is all perfect and easy. If you set up a print queue and it works locally, after activating sharing in s-c-p, the printer works as well on remote CUPS clients.
[15:30] <pitti> tkamppeter: right, as I thought; I updated the blueprint accordingly
[15:32] <tkamppeter> pitti, only thing which could be improved is sharing a printer to Windows clients. To make it really easy one would need the CUPS driver for Windows, which is not free and there is also not much development done on it.
[15:32] <slangasek> directhex: I'm quite certain I don't understand that, but ok :-)
[15:32] <directhex> you earnt a LOL, that's all that matters
[15:45] <Keybuk> yup, nvidia-glx-180 breaks everything
[16:11] <superm1> Keybuk, curiosity: what's the context of that?  i've just switched to it and not seen any oddities yet...
[16:12] <Keybuk> lots of repainting issues
[16:12] <directhex> ooh, a 180 driver? with vdpau goodness?
[16:12] <Keybuk> esp. with gnome-terminal, where it simply won't be repainted at times
[16:12] <Keybuk> and suspend/resume utter fail
[16:13] <superm1> ah probably only when compizified with the repainting issues.
[16:13] <superm1> yup they sure are there when i turn it on
[16:17] <ion_> (offtopic "http://johan.kiviniemi.name/blag/ubuntu-checklist/")
[16:17] <superm1> apw, well it's starting in polling mode a lot sooner this time, but still seeing that GPE storm
[16:18] <superm1> apw, and still "missing confirmation, switch off interrupt mode"
[16:19] <apw> superm1, can you email me the whole dmesg please
[16:19] <superm1> apw, sure
[16:19] <apw> thanks a lot ...
[16:24] <apw> superm1, can you also suspend and resume the machine, i found that had an effect on the poll/interrupt mode
[16:25] <superm1> apw, i did so at the end of it
[16:25] <superm1> it's in the same dmesg already
[16:25] <apw> handy
[16:47] <slangasek> directhex: so none of the gtk-sharp2 binary packages require a renme for the mono 2.0 transition?
[16:48] <directhex> slangasek, nope. nothing needs to go to NEW
[16:48] <slangasek> ok
[16:51] <slangasek> directhex: gtk-sharp2 uploaded, then; do the other libs all need to be uploaded at roughly the same time?
[16:51] <directhex> slangasek, there's really no time limit for it. at your leisure
[16:51] <directhex> now if you'll excuse me, i have a bus to catch
[16:52]  * slangasek waves
[16:52] <directhex> erm, a car to drive home. /me needs more sleep
[17:39] <Fenix|work> Greetings... Would someone be so kind as to tell me how to make a static library version of bash so I can chroot on a 64 bit system?
[17:41] <DRebellion> Fenix|work, I'm not sure about the static bash compilation, but you may be interested in debootstrap to create a minimal chroot.
[17:41] <Fenix|work> I'll take it
[17:41] <cjwatson> Fenix|work: sudo apt-get install bash-static
[17:41] <Fenix|work> also, while I'm here... how do I fix a f-up that my jr. did to my box... chmod -R 644 * from /
[17:42] <Fenix|work> cjwatson, bash-static is not abailable, but is referred to by another package.  This may mean that the package is missing, has been obsoleted, or is only available from another source
[17:44] <cjwatson> Fenix|work: it's available (in universe) in every release since at least dapper
[17:44] <Fenix|work> cjwatson, for amd64?
[17:45] <Fenix|work> just uncommented out some of the lines
[17:45] <Fenix|work> (from /etc/apt/sources.list)
[17:49] <Fenix|work> cjwatson, is the binary called bash, or something else?
[17:53] <cjwatson> Fenix|work: yes, for amd64.
[17:53] <Fenix|work> cjwatson, I installed it, but still no joy... once I'm in the chroot... everything is Permission denied.... even ls
[17:53] <cjwatson> Fenix|work: /bin/bash-static (use packages.ubuntu.com)
[17:54] <Fenix|work> bash-static: /bin/ls: permission denied
[17:54] <cjwatson> sure, bash-static doesn't magically make other executables work
[17:54] <cjwatson> why not fix stuff up from outside the chroot? chmod will work perfectly well from outside
[17:55] <Fenix|work> cjwatson, the permissions are mostly fixed... unless I've messed up the permissions on the libraries
[17:56] <cjwatson> once you have enough fixed to run basic commands, get a list of all the packages you have installed and feed it to 'apt-get --reinstall install'
[17:57] <Fenix|work> cjwatson, would you be kind enough to help me get the main files/directories straightened out permissions wise?
[18:00] <cjwatson> 'chmod +x /path/to/chroot/bin/*' and the same for /sbin /usr/bin /usr/sbin ought to take care of most of it. Don't actually try to boot into the system or grant remote access to it until you've reinstalled all the packages, though, as set-id bits and any limited permissions will be wrong
[18:00] <cjwatson> this really isn't a development topic ...
[18:01] <Fenix|work> what about libaries?  I've set them to 644
[18:02] <cjwatson> libraries don't generally need to be executable, so that's fine
[18:03] <Fenix|work> ok... chmod a+x'd all those directories and still get bash-static: /bin/ls: Permission denied when I chroot in
[18:03] <Fenix|work> I also have bound /dev /proc and /sys to my mounted volume
[18:09] <cjwatson> make sure that directories are executable, otherwise the runtime linker will get EACCES when looking for libraries
[18:09] <cjwatson> e.g. /lib and /usr/lib but also everything else. creative use of find and xargs will be useful
[18:09] <cjwatson> I have to go and cannot help you further. Please continue on #ubuntu
[18:10] <Fenix|work> one thing I've noticed when doing ldd on /mnt/bin/ls ... linux-vdso.so.1 isn't pointing to anything ... all the other libs point to files and their permissions are ok.
[18:11] <Fenix|work> linux-vdso.so.1 =>  (0x00007fffa9dff000)
[18:11] <cjwatson> that's normal. it's a virtual library provided by the kernel.
[18:12] <Fenix|work> they don't match
[18:13] <Fenix|work> linux-vdso.so.1 =>  (0x00007fff959ff000) ... is the one on the livecd
[18:13] <Fenix|work> could this be my dilema?
[18:15] <directhex> it's a virtual lib, pointing to a memory address specific to the running kernel
[18:15] <directhex> so it's normal enough
[18:16] <cjwatson> you still need to check the permissions on *directories* as well as files. If a directory is not executable then it isn't possible to use files in it
[18:16] <cjwatson> do that before inventing problems for yourself :)
[18:18] <Fenix|work> cjwatson, I've essentially done the following... find /mnt/ -type d -exec chmod 755 {} \; ... then furthermore did find /mnt/lib -type f -exec chmod 644 {} \; && find /mnt/usr/lib -type f -exec chmod 644 {} \;
[18:19] <Fenix|work> as well as changing chmod a+x /mnt/bin /mnt/sbin /mnt/usr/bin /mnt/usr/sbin
[18:21] <Fenix|work> so if I've missed something... I'd like to know
[18:22] <Fenix|work> ( as an aside, I've also fixed the permissions in /etc as well )
[18:32] <Fenix|work> cjwatson, problem solved... a couple of libraries need x permissions
[18:33] <imachine> Hi, I've had issues with building nvidia drivers on updated 8.04 (updated it to 8.10 yesterday).
[18:33] <imachine> I'm trying to pin-point the problem, perhaphs together we can sort it out?
[18:33] <imachine> dkms fails spewing out nvidia build cannot determine kernel version.
[18:34] <imachine> I've searched on generic linux forums, and it seems that it's caused by the lack of asm-i386 dir (or symlink) in the 'include' dir in the kernel headers, or sources, dir.
[18:43] <directhex> building nvidia drivers? ubuntu has packaged nvidia drivers
[18:43] <directhex> and breaking your own system is not a #ubuntu-devel topic
[18:44] <directhex> only breaking everyone's systems via package production
[18:46] <imachine> directhex, it was broken by someone else
[18:46] <imachine> directhex, since I'm using the standard packages ;-)
[18:46] <imachine> and dkms fails ;)
[18:47] <imachine> I joined -devel since I thought it'd be a better place to sort the error out.
[18:47] <imachine> this is the envy output http://pastebin.com/m6320267
[18:47] <imachine>  http://pastebin.com/m1fb153eb and heere's the make.log
[18:48] <imachine> so if anyone has any ideas... be my guest, I want this sorted, for me, and for anyone in the future ;]
[18:49] <directhex> tseliot is elsewhere right now. he's the guy to talk to about envy
[18:50] <imachine> yeah so I heard
[18:50] <imachine> it's not really an envy issue tho
[19:01] <imachine> directhex, http://bbs.archlinux.org/viewtopic.php?pid=328232#p328232 seems this mentioned some sort of fix
[19:02] <imachine> so it looks like ubuntu version of drivers are not compatible with the new 8.10 kernel...
[19:02] <imachine> for some reason..
[19:02] <imachine> ;]
[19:11] <ScottK-laptop> imachine: Those posts were about 2.6.24 (which is the kernel we have in Hardy, not Intrepid).  If it's something to do with envy, ask tseliot when you see him around.
[19:16] <Fenix|work> cjwatson, when doing apt-get --reinstall install ... should I consider placing ubuntu-minimal in the list?
[19:17] <Fenix|work> (or maybe even ubuntu-standard)
[19:24] <asac> pitti: there? #291417 ... shall i verify that trivial fix so we can get that out of -proposed?
[19:26] <pitti> asac: please
[19:29] <imachine> ScottK-laptop, it's not really. I had no prblems on hardy. on intrepid (after upgrading from hardy) they appeared. I will indeed talk to tseliot :)
[19:29] <imachine> cheers
[19:30] <YokoZar> hmm there appears to be a pitti and a martin-pitt on launchpad
[19:30] <pitti> !
[19:30] <pitti> c'est ne pas moi
[19:31] <YokoZar> eh?
[19:31] <pitti> I don't know "Marty Pitt"
[19:32] <YokoZar> I'm trying to subscribe you to a bug (inspired by your UDS presentation) and I'm not sure which name to use ;) ...then I found your wiki page is empty
[19:32] <pitti> martin-pitt has 0 karma, pitti has a proper LP homepage and lots of karma :)
[19:33] <asac> pitti: done
[19:34] <YokoZar> I suspect martin-pitt was autocreated long long long ago
[19:34] <asac> pitti: i think I will do the same for the two outstanding -needed tags in nm
[19:35] <pitti> asac: as long as you are using the actual debs from intrepid-proposed, that's fine (compilation errors, wrong linked libs, and all that)
[19:35] <asac> pitti: sure. i am on intrepid still
[19:38] <pitti> asac: nm and nm-applet look good, I'll move that to -updates unless you heared anything bad about it?
[19:39] <pitti> asac: (I'm just at SRU mangling anyway)
[19:40] <pitti> ScottK-laptop: any chance you could test the packages in bug 278075?
[19:41] <ScottK-laptop> pitti: Since I uploaded the fix, does my testing count?
[19:41] <pitti> ScottK-laptop: if you use the actual binaries from the archive, it's much better than no testing at all
[19:42] <pitti> ScottK-laptop: and the bug looks like being actively detrimental, so it seems to me that this should move to -updates soon
[19:42] <ScottK-laptop> pitti: OK.  I was hoping the reporter would test it, but let me see what i can do.
[19:45] <asac> pitti: no nm should be fine ... let me go thorugh the SRU bugs swiftly again
[19:45] <pitti> asac: just checked -gnome, looks fine; 3/4 verified
[19:45] <pitti> (tested by me, too, no apparent regressions)
[19:47] <LaserJock> pitti: do rebuild-only SRUs need to go through the same SRU procedure as everything else?
[19:47] <pitti> LaserJock: yes
[19:48] <asac> pitti: ok ... lets move them then.
[19:52] <pitti> zul: please upload the fix for bug 282518 to jaunty
[19:54] <zul> pitti: np
[20:16] <pitti> doko: python-lxml now seems to b-dep on cython, didn't do that in intrepid; not described in the changelog, can it build without it, or does it need a MIR?
[20:38] <DimStar> Good evening everybody.. I'm an author of the library libproxy and a ubuntu user reported an issue with compiling the lib, linking against mozilla-js on Ubuntu 8.10. Libproxy uses pkg-config in order to identify the location of include files, but apparently on Ubuntu 8.10, this seems not to reflect the reality. Is something like this known to you?
[20:58] <ebroder> Any backporters around who could ACK on #305001 or #301283?
[21:14] <calc> pitti: suitesparse has been in main before so can it be promoted without a new MIR?
[21:19] <paulproteus> DimStar, Yo
[21:19] <DimStar> Hi paulproteus
[21:19] <paulproteus> I'm not aware of that issue, but do you know about the lib*-dev convention in Debian and Ubuntu?
[21:20] <paulproteus> DimStar, On Debian and Ubuntu you'll find that you need lib<package_name>-dev to get the right headers and pkg-config information.
[21:20] <DimStar> paulproteus: not really.. I'm myself openSUSE packager and participate in the libproxy project... and we were informed that this problem exists...
[21:21] <DimStar> maybe you can follow up all what we know so far:
[21:21] <calc> isn't suse like foo-devel for the same things?
[21:21] <DimStar> http://code.google.com/p/libproxy/issues/detail?id=18
[21:21] <paulproteus> Right, exactly - it's that same concept as foo-devel.
[21:21] <DimStar> yes... the user apparently has the .pc file on his system (so I assume he has the -dev package)
[21:21]  * paulproteus nods
[21:22] <DimStar> but the .pc file point in the --cflags to a location different from where he actually finds the jsapi.h file on his system
[21:22] <paulproteus> I see that, yeah.
[21:22] <DimStar> and not knowing all the background behind an ubuntu system I assumed it would be best to get some advice for this issue from you :-)
[21:23] <directhex> #ubuntu-mozillateam for mozilla oddities
[21:23] <DimStar> from 'my side' it looks like a werid packaging issue
[21:24] <DimStar> directhex: I can gladly bring it to the next channel... if this is the best way to go.
[21:25] <calc> DimStar: or perhaps ping asac but he probably isn't around now (he is in germany)
[21:25] <DimStar> calc: then he is only a few km away :-)
[21:26] <calc> DimStar: ah heh
[21:26] <DimStar> 10:30pm here
[21:53] <asac> calc: thanks took over in #ubuntu-mozillateam
[22:37]  * NCommander really hopes restore and backup get better with Jaunty
[22:37] <NCommander> Restoring is a PITA
[22:43] <doko> pitti: it *does* have a MIR. see https://bugs.edge.launchpad.net/ubuntu/+source/cython/+bug/299870
[22:58] <directhex> does anyone know why nant and ndoc are in main?
[22:58] <Hobbsee> they look to be directly seeded, but i don't have copies of the seeds here
[22:59] <directhex> Hobbsee, ndoc needs nant to build - but i'm not sure what uses ndoc these days
[23:00]  * StevenK updates his seed lists
[23:01] <Hobbsee> libndoc-cil
[23:01] <Hobbsee> and the docs
[23:02] <Hobbsee> strange.
[23:03] <directhex> Hobbsee, ndoc is a tool for converting .net xmldoc format to other things (e.g. indexed html). i don't see what it serves by being in main in this day & age
[23:03] <directhex> it might've been used once upon a time instead of monodoc, but i'm guessing