[00:41] Chipzz define bootstrapping...and i have till march to do this...so ive got plenty of time... [01:36] lamont: hmm, why did bind9's binary packages all get fatter in jaunty? [01:36] or should I be directing that question at kees/doko? [01:42] slangasek: define "fatter" [01:43] lamont: bind9-host is 30% bigger in jaunty than intrepid, with no difference in file contents [01:43] s/file/package/ [01:44] * dig: add -DDIG_SIGCHASE to compile options. LP: #257682 [01:44] * enable largefile support. Closes: #497040 [01:44] otherwise, nfc [01:44] 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] ok, thanks; time to test builds in a chroot [01:44] I haven't really looked [02:01] bug 257682 [02:01] Launchpad bug 257682 in bind9 "dig compiled without -DDIG_SIGCHASE!" [Undecided,Fix released] https://launchpad.net/bugs/257682 [02:02] Chipzz: yep. that's the bug alright [02:04] lamont: wanted to take a look at it myself :P [02:04] heh [02:05] I was just wondering, ubotu should probably generate those links automatically when someone says "LP: #xxxxx" [02:07] heh [02:07] bug 497040 [02:07] Error: Launchpad bug 497040 could not be found [02:07] weird [02:25] lamont: curiously, if I do a local rebuild, bind9-host comes out even larger... [02:25] with dpkg-buildpackage -B [02:25] interesting [02:26] oh, langpack stripping maybe? [02:26] yeah - possibly [02:26] hmm, no [02:26] Chipzz: debian bug 497040 [02:26] Debian bug 497040 in bind9 "bind9: Log files limitited to 2GB" [Normal,Closed] http://bugs.debian.org/497040 [02:27] lamont: right, don't use 'du' to compare file sizes across systems with different block sizes :) [02:39] lamont: ah heh. fail on my part :P [02:39] slangasek: heh [03:04] 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] slangasek: git clone git://git.debian.org/~lamont/bind9.git [03:05] hmm? [04:02] slangasek: that has the entire history if you wanna bisect the changes... :) [04:02] though there aren't really that many of htem [04:02] * lamont sleeps [04:21] slangasek: btw for alpha-2 could you include in the release notes a known-issue with i8xx chips (bug #304871) [04:21] Launchpad bug 304871 in xserver-xorg-video-intel "[Jaunty,845G] Fatal server error: Couldn't bind memory for BO front buffer " [High,Confirmed] https://launchpad.net/bugs/304871 [04:22] 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] bryce: ok, noted [04:53] lamont: apparently it's the DIG_SIGCHASE change that does it [04:54] ArneGoetje: FYI, the change in ttf-arphic-uming to select dpkg compression based on dist name doesn't work [04:55] anybody know offhand a page that clearly says what Ubuntu's security support policies are? [04:56] 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] slangasek: so, your suggestion would be to build-depend on lsb-release? [05:03] ArneGoetje: yeah (just uploaded with that change) [05:03] slangasek: ok, thanks [05:03] 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] slangasek: ttf-sazanami-{gothic,mincho} [05:06] ah, already changed in the seed and just needs an upload :) [07:18] good morning === dholbach_ is now known as dholbach [08:14] hi [08:15] pitti, hi [08:55] Good morning [08:55] tkamppeter: hey [08:56] Hey pitti [08:56] pitti: had a good trip? [08:56] everyone landed safely again? /me had a very broken trip [08:56] what happened? [08:56] lool: most improbable EVER [08:57] 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] and guess whom we ran into [08:57] mvo, ogra, and the other dudes which took the other plane 40 mins earlier [08:57] whose plane broke as well, in a much more scary manner [08:58] and then in Frankfurt I had to stand in line for 2.5 hours to get my ticket rebooked [08:58] pitti, I have an SRU for bug 306125 and bug 288570. Can you improve the Intrepid tasks of these bugs? [08:58] Launchpad bug 306125 in ghostscript "PostScript produced with particular eps file when using graphicx-psmin gives error in ghostscript" [Undecided,Fix released] https://launchpad.net/bugs/306125 [08:58] Launchpad bug 288570 in ghostscript "Ghostscript eats all hard drive space and prints errors when printing with 1200 dpi" [High,Fix released] https://launchpad.net/bugs/288570 [08:58] pitti: Sounds fun :-/ [08:59] eww, wiki.u.c. down? [08:59] pitti: Doesn't respond for me either [09:00] I get a 503 Service Unavailable [09:00] I get a timeout; are you using a proxy? [09:00] I got a few 500 this morning. [09:00] and now it's a timeout. [09:02] Now I got 503 [09:02] tkamppeter: done [09:03] pitti, thanks, will upload the new gs to -proposed. Please pass it through. [09:07] pitti, new gs is uploaded. Can you pass it through, thanks. [09:07] will process the queue later [09:24] 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] pitti: Are you planning to do the libspe2 merge on main-manual? [09:40] oh, I didn't even look at that; I touched libspe2? [09:49] pitti: According to MoM, you did [10:26] 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] Launchpad bug 271350 in cups "pdftopdf filter on PowerPC corrupts data" [Undecided,Fix committed] https://launchpad.net/bugs/271350 [10:26] 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] tkamppeter: it's there for 19 days already; it should really get tested [10:27] some feedback about "still works for me" [10:30] pitti, what do you mean with 'some feedback about "still works for me"'? [10:30] 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] 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] tkamppeter: yes [10:53] tkamppeter: but before I'd like to move 4 to -updates [11:00] pitti, the bugs which I want to fix with 2ubuntu5 are bug 286048, bug 300312, bug 244840, and bug 47649. [11:00] Launchpad bug 286048 in cups "RELEASE FREEZE EXCEPTION: When requesting n copies, n*n or even n*n*n copies get printed" [Critical,Fix released] https://launchpad.net/bugs/286048 [11:00] Launchpad bug 300312 in cups "tagged PDF with rotation is not printed correctly" [Undecided,Fix released] https://launchpad.net/bugs/300312 [11:00] Launchpad bug 244840 in cups "Landscape PDF documents get printed portrait, truncated" [Undecided,New] https://launchpad.net/bugs/244840 [11:00] Launchpad bug 47649 in cups "Landscape PDF printed as portrait (and truncated)" [Medium,Confirmed] https://launchpad.net/bugs/47649 [11:00] pitti, it would be great if the reporters of these bugs could start to test now. [11:01] tkamppeter: I might also have a fix for bug 237256 in time [11:01] Launchpad bug 237256 in cupsys "Audit failure in CUPS for Brother DCP-9045CDN" [Undecided,New] https://launchpad.net/bugs/237256 [11:01] pitti, great. How do you fix that one. [11:03] pitti, can you approve the Intrepid tasks of the bugs I mentioned above? [11:04] tkamppeter: replied to 237256 [11:05] tkamppeter: done [11:06] pitti, you simply added "/usr/Brother/** Ux" to the AppArmor file? [11:08] pitti, thanks for approving the Intrepid tasks. [11:09] Keybuk, kees: on whose plate is the d-bus (security/new version) update? [11:10] mine [11:10] it's not urgent, as far as we can tell there's no escalation you can get from it [11:10] and the fix is as bad as the cure [11:11] 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] Launchpad bug 271350 in cups "pdftopdf filter on PowerPC corrupts data" [Undecided,Fix committed] https://launchpad.net/bugs/271350 [11:11] tkamppeter: *shrug* WFM [11:15] pitti, WFM? "Works for me"? "Wait for me"? [11:15] tkamppeter: "works for me" [11:17] doko: when you have some spare time, mind looking/commenting at bug 254790? Thanks. [11:17] Launchpad bug 254790 in binutils "strip segfaults on dietlibc-built executables" [Unknown,Fix released] https://launchpad.net/bugs/254790 [11:23] pitti, so can you give me your fix for Brother then and I will upload 2ubuntu5? === ogra_ is now known as ogra [11:34] 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] soren: what kind of problems are you expecting? [11:53] Keybuk: Each host will notice the raid superblock and configure the raid set... Right? [11:54] hi, what allows u to mount hd partitions without fstab entry? [11:54] 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] pitti: am tracking the d-bus issue on bug #30632 [11:55] Launchpad bug 30632 in soyuz "Builder "Change mode" page should enable optional comment." [High,Fix released] https://launchpad.net/bugs/30632 [11:55] err [11:55] pitti: am tracking the d-bus issue on bug #306362 [11:55] Launchpad bug 306362 in dbus "Default D-Bus system bus policy is allow" [Critical,In progress] https://launchpad.net/bugs/306362 [11:56] the issue is that just about every existing dbus policy file is wrong in some way [11:56] so if we upload the "fixed" version of d-bus, every service will break [11:56] and worse, services will break because *other* policy files are broken [11:57] e.g. say that /etc/dbus-1/service.d/foo.conf has [11:57] [11:57] [11:57] [11:57] that means [11:57] "by default, deny ANY SERVICE from receiving messages for the com.ubuntu.Frob interface [11:58] AND, since we have denied interfaces, deny ANY SERVICE from receiving messages _with_no_interface_set_" [11:58] (sending messages without the interface set is default for things like Python) [11:58] assumedly what they really meant was [11:58] [11:58] or [11:58] [11:59] though if you have the former, you don't need the latter [12:00] also almost nobody allows people to receive their signals ;) [12:08] 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] 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] soren: why should udev ignore them? [12:13] you still want them in the udevdb and still want them in /dev surely? [12:13] Keybuk: Not really. [12:13] why not?> [12:13] I don't understand why you'd want a connected device which udev doesn't know about? [12:13] Keybuk: Well, I suppose it depends on what you refer to by "them". :) [12:13] if it's in /sys, there's no reason it shouldn't be in /dev [12:14] 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] you generally want a match between /sys/dev/block <=> /dev/block and /sys/dev/char <=> /dev/char [12:14] ah, I see what you mean [12:15] you want the top-level block device to appear, but don't want to run mdadm and/or lvm on it? [12:15] Right. [12:15] what heuristic would you follow to decide that? [12:15] My specificu use case is virtual machines, so exporting some sort of list from libvirt would be a good start. [12:17] soren: can you tell me how the mounting works without fstab entry for hd partitions? [12:18] soren: if we have a blacklist, I'd use it to skip the entire "persistent" bit of the udev rules [12:18] 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] e.g. /dev/disk/by-*, mdadm, lvm, etc. [12:18] even better if we could generate that blacklist in the form of udev rules in the first place [12:18] 59-blacklist.rules [12:18] Keybuk: Ah, good idea [12:18] BLAH==BLAH, GOTO="symlinks_end" [12:18] 79-symlinks-end.rules [12:19] LABEL="symlinks_end" [12:19] Keybuk: The target of GOTO doesn't need to be in the same file? [12:19] type thing [12:19] That's convenient. [12:19] no, you can jump files with it [12:19] hell, you may want to just do [12:19] BLAH==BLAH, OPTIONS+="last_rule" [12:19] to prevent any further processing, including hal [12:19] in fact, I think last_rule is probably correct [12:19] otherwise you may still get hal automounting [12:20] Yeah, that would suck. [12:20] Hm... It won't suffice for lvm, though. [12:21] 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] ah, true [12:21] I'm still waiting for incremental LVM [12:21] incremental? [12:21] how would that work? [12:21] 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] \sh: ping [12:22] Keybuk: ah. in that sense. that makes sense :-) [12:22] and lvm would only activate when it has all the pieces it needs [12:23] Keybuk: Scanning alone should be fine, I suppose. As long as it doesn't get activated, we should be golden, right? [12:23] hmm. I have my lvms on raid ;-) [12:23] but I guess we can do the same for mdraid? :-) [12:23] right, "I have /dev/dm-0, do you want it?" [12:24] soren: we activate everything [12:24] Keybuk: I realise. [12:24] Hmm... [12:25] 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] s/even/even though/ [12:25] we don't have any ability to prevent activation [12:25] unless lvm has a conf file for taht [12:26] vgchange -ay takes an argument. [12:26] of the specific device you want to activate, right? [12:26] not a list of ones you do *not* [12:27] volume group. [12:27] Right. [12:27] Erm... [12:27] so that would break things ;) [12:27] Ok, I see where you're going. [12:27] right now, lvm only works *because* we always activate [12:28] Ok, what we need to do is to make vgscan ignore the relevant block devices altogether. [12:29] agree [12:30] Cool. I'll look into that. [12:30] upstream is already working on something like that [12:31] (agk) [12:33] Keybuk: Cool. I'll see if I can strike up a conversation with him. [12:33] Keybuk: Thanks for your input! [12:34] I wouldn't expect it in this release [12:35] 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] ...but should definitely be fixed. [12:35] there is mdadm incremental support upstream [12:35] but we don't use it yet [12:35] so with mdadm, we scan and activate all devices on each new block device [12:35] *blink* [12:35] Really? [12:36] I thought we did that incrementally. [12:36] nope [12:36] * soren needs to run out for an hour or so.. [12:36] it's on my TODO list [12:36] but there's a lot of things on my TODO list ;) [12:36] if you want to take a stab, go for it [12:37] basically instead of calling mdadm within watershed, we would call mdadm --incremental for each block device [12:37] AIUI [12:37] needs lots of code reading and testing to make sure it'll do the right thing [12:40] slangasek: interesting... still, having SIGCHASE is a good thing [13:35] random thought of the day [13:35] on server, instead of having six gettys on different tty1s... [13:35] ...why don't we have just one tty/getty and run screen by default [13:36] 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] my mail server doesn't have a lot of memory and occasionally SA kills it ... [13:37] ttys are in userspace though? [13:37] you still have to go through login. pam, shell, etc. [13:37] which is harder work than opening a new screen pty and running the shell in it [13:37] not if you've anticipated this possibility and already have something logged in with a tail of syslog [13:38] then it's just kernelspace [13:38] you'd have a screen logged in with a tail of syslog? [13:38] screen would have to get scheduled in order to switch to it [13:38] I wish this were a hypothetical problem for me :( [13:38] hmm. that's a reasonable point [13:39] (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] tail's parent (the shell) has to be scheduled as well [13:40] for tail -f? [13:40] surely not [13:40] 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] cjwatson: sure [13:40] if you kill your running tail [13:40] tail has to be scheduled to receive SIGTERM and do something about it [13:41] then the shell has to be scheduled to receive SIGCHLD and call wait() [13:41] oh, no, I just meant leaving tail -f running forever [13:41] and assumedly scheduled enough to show the next prompt and allow you to run something else (nice generally :p) [13:41] ah, you only wanted to read the tail? [13:41] I thought you meant having a handy logged-in-as-root shell somewhere that you happened to run tail in normally [13:41] ie. you switched, killed tail, then used that shell to rescue the box [13:42] though that also brings up an interesting point [13:42] 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] or whatever [13:42] syslog is useful on servers, why *not* have it sent to a spare tty automatically? [13:42] it's a fairly significant time-saver [13:42] d-i style [13:42] I've always thought that was a good idea; I run it on tty [13:42] I used to use tty24 [13:43] Some might see it as a security breach to have a syslog taik setup automatically to a spare tty. [13:43] some might be wrong. if you have physical access then you have root [13:44] obviously if the machine is specially locked-down then you'd want to disable it [13:44] but that's not the common case and already requires other work [13:44] http://www.jerkcity.com/emu//jerkcity1110.html [13:44] (SFW) [13:45] heh [13:47] slangasek, yes, definitely. it's just a long slog, unfortunately [13:47] slangasek, http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO shows current progress [13:48] 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] 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] (or at least, to within spitting distance) [13:49] the *real* baddie is libgtk2.0-cil - but if we update that too early, it will break all untransitioned apps [13:49] 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] slangasek, http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition [13:50] 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] slangasek, basically the libs used by it need to be 2.0, as well as tomboy itself [13:51] tjaalton: quantify "old and exotic" for me, please? :) [13:51] slangasek: -summa for instance, no real changes to the code since 2005 [13:52] directhex: so tomboy can't switch until gtk-sharp2 and gnome-sharp2 (and perhaps others) are transitioned? [13:52] ie. hardware that no-one using jaunty will miss ;) [13:52] slangasek, essentially, yes. [13:53] tjaalton: hrm, that one's already in universe though, so presumably isn't a dep of -all? [13:54] 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] (IMHO) [13:54] slangasek: oh, haha [13:54] silly me then [13:54] 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] carry on.. [13:57] 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] have sync requests been filed? [13:57] if so, I'll switch gears right now and take care of those [13:57] tkamppeter: Brother fix> I asked the submitter for testing it [13:58] 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] slangasek, the ones i filed have been ack'd. i don't know what delay there is after someone says "ACK" though [13:58] "until an archive admin does them" [13:59] Keybuk: lol, so in the end we don't need to do a security update at all? :-) [14:02] 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] 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] Hi. How can I tell which packages get security updates for the full five years in an LTS release? [14:06] 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] 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] fbond, do you have a gui on your system? [14:07] directhex: Sort of. It's a pretty custom image with a light GUI that is deployed on digital signs. [14:08] directhex: That's why I asked the question the way I did. [14:08] directhex: Is there some kind of policy on this? I keep getting heuristics from people. [14:08] fbond, "stuff in main" [14:09] directhex: Okay, thanks. [14:09] no, that isn't accurate unfortunately [14:09] "stuff that's server-ish" [14:09] it's not? [14:09] cjwatson: I figured as much... [14:10] I owe Nick Barcet some work to process the work he's been doing on defining this more tightly [14:10] cjwatson: Okay, sounds like I can only really count 3 years for my app. [14:10] Thanks. [14:12] directhex: oh, perhaps the ones with '[mono2.0transition]' in the title ;) [14:12] slangasek, bug 308179, bug 307580, bug 307593, bug 307973, bug 307970 [14:12] Launchpad bug 308179 in podsleuth "Please sync podsleuth 0.6.3-3 (universe) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/308179 [14:12] Launchpad bug 307580 in smuxi "[mono2.0transition] Please sync smuxi 0.6.2-4 from Debian Experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/307580 [14:12] Launchpad bug 307593 in gnome-rdp "[mono2.0transition] Please sync gnome-rdp 0.2.3-1 from Debian Experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/307593 [14:12] Launchpad bug 307973 in gfax "Please sync gfax 0.7.6-10 (universe) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/307973 [14:12] Launchpad bug 307970 in giver "Please sync giver 0.1.8-3 (universe) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/307970 [14:12] directhex: got it - those will all be done shortly, then [14:13] and one more... 308180 [14:13] cjwatson: will have a look at those installer packages at the end of this sync run [14:13] FYI, the deps on ubuntu-dev-tools should be stricter. i get nasty errors running jaunty requestsync on hardy [14:14] i hope this newer python-launchpad-bugs fixes it [14:15] 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] (bug #307593) [14:15] Launchpad bug 307593 in gnome-rdp "[mono2.0transition] Please sync gnome-rdp 0.2.3-1 from Debian Experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/307593 [14:16] slangasek, according to the changelog, it should be synced now [14:16] ok [14:16] "after Hardy this should be simply [14:16] synced. [14:16] -- Sebastian Dröge " [14:17] 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] slangasek: ta [14:18] slangasek: any objection to me bumping base-files to 8.04.2 in preparation? [14:18] cjwatson: feel free [14:19] (it's a build-dep of debian-installer, you see) [14:19] aha, alpha 2. THAT's where this talk of cd space came from === fargiola` is now known as fargiolas === maxb is now known as Guest20139 [14:39] directhex: ok, syncs done except for gfax (since as dholbach notes, the tgzs don't match and a fake sync is needed) [14:39] directhex: how far ahead does that move us? :) [14:40] slangasek, did you catch [14:13] and one more... 308180 ? [14:40] yes [14:40] * directhex updates wiki [14:41] https://bugs.launchpad.net/ubuntu-cdimage/+bug/140458/comments/33 any objection to me just doing that? [14:41] Launchpad bug 140458 in wubi "Provide official Ubuntu metalink files on a public webserver" [Low,Fix released] [14:41] slangasek: I assume I should edit the files in MirrorMetalink/templates/ ? [14:41] 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] 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] cjwatson: no objection / yes [14:43] directhex: sorry, which are the ones you named? I seem to have lost track [14:44] 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] ok [14:45] 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] hm, i think i forgot one [14:50] tangerine? [14:50] oh, you win \o/ [14:50] Laney, good guess! bug 308189 [14:50] Launchpad bug 308189 in tangerine "Please sync tangerine 0.3.0+dfsg-3 (universe) from Debian experimental (main)." [Undecided,New] https://launchpad.net/bugs/308189 [14:50] doko: are you planning a hardy upload for bug 288279? (8.04.2 is coming up soonish) [14:50] Launchpad bug 288279 in openjdk-6 "Wrong path for dejavu fonts" [Undecided,Fix released] https://launchpad.net/bugs/288279 [14:50] slangasek, sorry for missing that one [14:51] directhex: no worries, syncing now [14:53] http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO looks a lot greener than it did an hour ago [14:53] and gbrainy is not yet ready to sync? [14:53] or is it? [14:54] nope. rainct wanted to ask upstream for a new version w/ minor fixes [14:54] you'll have to ask him - it's not a team-maintained package so we can't upload it willy nilly [14:55] ok [14:56] slangasek, what does a fakesync involve, WRT gfax? === dfiloni is now known as devfil [14:56] directhex: manually applying the Debian diff to the Ubuntu tarball, signing and uploading [14:57] PITA [14:58] yes, blame whoever diverged the tarball :) [14:58] this is why I was banging on about making sure the core stack tarballs are the same :) [14:59] cjwatson, they are! or i think they are [14:59] too lazy to md5sum them by hand, but we certainly coordinated that [14:59] wasn't saying they weren't [14:59] just saying that this is the problem I was trying to make sure we didn't encounter there as well [14:59] right [15:00] well, any volunteers to do the gfax fakesync? can you think of anyone, Laney? [15:00]