[00:04] slangasek: ok, mono should now build again (not my fault, was broken before :P ) on x86 and friends... could you care for give-backs of gnome-desktop-sharp2 and everything else that failed because of broken mono dependencies after things are working again? :) [00:05] slomo: you need a buildd admin for that [00:07] doko: ^--- :) [00:08] slomo: what is "everything else"? [00:08] will do that tomorrow, if you could give some list [00:10] doko: nothing else it seems... well, if i find something else i'll tell you. i thought f-spot or mono-tools could've failed too but they're fortunately still on dep-wait [00:10] doko: so that's only gnome-desktop-sharp2 [00:12] There might be a possible regression occurring with Hardy. [00:12] A few people have said that network-manage has quit working after the latest updates [00:13] nope, it quit working after the previousupdates [00:13] it works again with the latest updates [00:13] Okay [00:13] So Bug #204897 is Fix released? [00:13] Launchpad bug 204897 in network-manager "[hardy] Network manager causes CPU load to go to 100%" [Undecided,New] https://launchpad.net/bugs/204897 [00:15] yes [00:17] good to know === Pici` is now known as Pici [00:26] My network manager just crashed and came back with a dup from bug #85113 [00:26] Launchpad bug 85113 in network-manager "[apport] NetworkManager crashed with signal 5 in main()" [High,Fix released] https://launchpad.net/bugs/85113 [00:32] sectech: That's correct. The problem is in hal. There's a new package that's been built and should show up on a mirror near you soon. [00:32] There was a second update released for it [00:32] ok [00:34] Was your fix 0.5.11~rc2-1ubuntu2 [00:34] ? [00:34] whoops... hal 0.5.11~rc2-1ubuntu2 [00:35] because that was the one that caused the report.... The version before was the one with the original regression [00:58] sectech: how have you determined that it's a duplicate of bug #85113? I don't see that any new bugs have been marked as duplicates of that [00:58] Launchpad bug 85113 in network-manager "[apport] NetworkManager crashed with signal 5 in main()" [High,Fix released] https://launchpad.net/bugs/85113 [01:00] and if it's not a duplicate, we probably need more information (such as a current backtrace) to track it down [01:13] hey all, im trying to open the source for _gobject.so, under/var/lib/python-support/python2.5/gtk-2.0/gobject, and when i run 'sudo gcc _gobject.so' i get a bunch of compiler errors [01:13] how can i open it to actually read/edit the file though [01:16] sorry, you're trying to do what? the source is in the source package, not in /var/lib/python-support [01:16] hmm okay, where do i get the actual source then? [01:16] sorry im new to this [01:16] apt-get source python-gobject [01:17] but what do you plan to do with the source? [01:17] unable to find source package [01:17] im looking at a bug right now [01:17] then you need to add the right deb-src lines to your /etc/apt/sources.list [01:19] which ones? [01:20] you need a deb-src line for "main", corresponding to the deb lines for your mirror [01:20] posingaspopular, Applications > System > Software Sources [01:21] posingaspopular, Check off the source repositories [01:21] thanks cody [01:21] ITYM System -> Administration -> Software Sources [01:23] either way, im running kde :P [01:30] http://paste.ubuntu-nl.org/60485/ [01:30] it's not working [01:31] sudo apt-get update; sudo apt-get source python-gobject [01:31] is this about the "PySignal_SetWakeupFd" error in your blog? [01:31] yea [01:31] here are my sources list: http://paste.ubuntu-nl.org/60486/ [01:32] which version of python-gobject do you have installed? The current version doesn't appear to reference that symbol. [01:32] mjg59: solved the libx86 issues. [01:32] hmm how do i check [01:33] apt-cache policy python-gobject [01:34] keescook: Really? [01:34] mjg59: yup. [01:34] keescook: Please don't tell me it was just an updated x86emu :) [01:34] yup [01:34] Gah. Misery. [01:34] version 2.1.4-2 [01:34] I extracted your patches (that took most of the time) and applied the updated x86emu [01:34] keescook: Well, update it and win :) [01:34] s/update/upload/ [01:35] mjg59: yup, doing final packaging now. [01:35] Ah well [01:35] mjg59: I basically have 3 patches I extracted: 1 appears to be an ancient version of the inline asm calls, which I have left unapplied. [01:35] I blame cpuid [01:35] cpuid or rdtsc [01:36] 1 is the process memory patch [01:36] Hm. Yeah. [01:36] and the other (the real nasty one that took me so long to find) was the "exit when CS==0 IP==0" [01:36] keescook: is "solved the libx86 issues" as momentous as it sounds? :) [01:36] why is that in our x86emu but not upstream? [01:36] slangasek: yeah, bug 147623 [01:37] w00t [01:37] posingaspopular: 2.1.4-2 is not the current version; can you upgrade to 2.1.4-2ubuntu1 and see if that fixes it? [01:38] (I believe that it does) [01:44] keescook: Thanks for dealing with that! [01:45] mjg59: you bet, it was kind of fun. ironically, my friend's EDID-lacking BIOS still eludes me. [01:45] mjg59: any thoughts on the extracted patches? I'd like to understand the CS==0 IP==0 one at least [01:47] keescook: Oh! I think that's just to make sure that when we return, we immediately bail [01:48] mjg59: without that, upslash freaks out pretty badly. I'm curious why the lack of that difference isn't an issue for xorg [01:48] keescook: Yeah, not sure off-hand. [01:48] it works! [01:49] thanks slangasek [01:49] keescook: But the aim is certainly to ensure that there's a halt instruction when it exits [01:49] slangasek: the debdiff for libx86 is rather sizeable -- should I just shove it in anyway? [01:49] keescook: is it all bugfixes? :) [01:50] slangasek: in theory :) [01:50] heh [01:50] keescook: let's run it through an FFe so we know what we're getting [01:50] I think people will scream loudly if there is a regression in it. but at the very least, it should fix nvidia and possibly other cards. [01:51] right, but the people hitting the regression might not scream at just the right time [01:51] slangasek: okay. worst-case I can extract just the cpuid/rdtsc instruction additions. [01:52] posingaspopular: no problem [01:52] keescook: the 8000er problem? \o/ feel free to abuse me as guinea pig ;) [01:53] sistpoty: sweet. I'll throw it in a PPA [01:53] keescook: source is fine for me as well ;) [01:53] slangasek: It's basically entirely addition of emulated opcodes [01:53] slangasek: I can't see any issue with it [01:53] sistpoty: I'll have a debdiff up shortly [01:53] :) [01:54] mjg59: well, I could extract _just_ those bits -- but since xorg was so different, this is actually a full refresh [01:54] mjg59: what does it currently do with opcodes it doesn't know how to emulate? [01:54] aborts. :P [01:54] ok, push it :) [01:55] slangasek: err, no FFe? [01:56] * keescook is hovering over "submit bug report" button [01:57] keescook: if the new code is just adding emulated opcodes, and unemulated opcodes cause an abort, I don't see how this can be a regression [01:57] so I'm fine with that being uploaded without an FFe [01:57] slangasek: I would agree, if that's what I've got packaged presently. what I have at the moment is a full refresh, which includes other fixes, re-arranged headers, etc. [01:58] ok, then go ahead and click submit and we'll look at it in more detail :) [02:01] hi, are there plans to integrate dmraid into the installer? [02:04] slangasek, sistpoty: FFe for libx86 is 204936 [02:05] cody-somerville: is there any sort of timeline for getting the xubuntu alternate CDs tested for release as a beta/ [02:08] well [02:09] Sorry, the big bus that brings the testers is late. [02:09] * cody-somerville shrugs. [02:10] slangasek, Unfortunately, I can't give any sort of timeline since I can't predict who is willing to volunteer to test and when. [02:10] * sistpoty tests, brb [02:10] I'll send an e-mail off to xubuntu-devel to see if I can round up some people who aren't on IRC [02:11] ok [02:12] shall I just hold off on xubuntu daily rebuilds in the meantime? (since turning them on means that these images may be aged out) [02:12] oh, these images have the broken hal, does that affect anything on xubuntu? [02:13] slangasek, The crash reporter stated it was a duplicate bug... I'm going to reboot to see if I can reproduce the problem, I'll try and provide more information if it happens again [02:13] one minute [02:13] We use network-manager [02:13] has anyone had any network manager breakage when upgrading to the beta? [02:14] jono: it was a post-beta breakage, should be fixed now in hal -1ubuntu2 [02:14] jono: if not, we need more info, because it's fixed for some people [02:15] slangasek: ok, dist-upgrading now [02:15] cody-somerville: ok, then let me reroll the images /again/, so you get a working n-m :) [02:16] sectech: quick reboot, how's it look? [02:16] I just rebooted but was unable to reproduce the error from network-manager. It looks like everything is okay [02:16] sectech: ok, thanks :) [02:16] thank you for the quick fix :) [02:17] if it does show up again, please file a bug report; even if it gets marked as a duplicate, it may still give us new information (such as version numbers, etc) [02:17] okay sounds good === foka__ is now known as foka_ [02:18] oh, whoops -- I had two checkouts of xorg... [02:20] slangasek: In principle, it gives a failure. However, I suspect that cpuid was giving it something that gave /an/ answer, just not one that made sense to the BIOS [02:25] slangasek: have some pretty significant b0rkage here [02:25] keescook: works for me \o/... however there's quite some flickering in usplash and tty1 contains lots of assembly now [02:25] slangasek: firstly, I have two kernels -12 and -14 - I need -14 to even see my wireless interfaces, and NetworkManager allows me to manually set the wireless interface but can't enable it [02:26] also, the -12 kernel is booting as the default instead of the -14 which seems odd [02:26] keescook: also unrelated (since my update of today), my monitor says no signal, when having usplash not installed [02:26] s/update/upgrade/ [02:27] sistpoty: can you capture the output? I was missing an options in the previous debdiff. Can you try the new one? [02:28] s/an options/an instruction/ [02:28] keescook: sure [02:28] (give me a sec) [02:31] are these network manager issues known with the beta? [02:32] keescook: is there any log where the output might be stored? (if not, I've just taken a photo *g*) [02:32] photo works -- you can also just run "usplash -c -v" manually as root and capture stdout/stderr [02:34] slangasek: I've extracted just the new instructions from upstream, not the whole mess of everything. this fixes it too -- however, an interesting side effect (that sistpoty has already seen) is that switching to a console vt ... doesn't work. it needs to do a POST, it seems. [02:35] slangasek: (at least on gutsy) [02:35] ok I have to get to bed [02:35] night all [02:36] gn8 jono [02:36] mjg59: possible regression is putting the video card in a _worse_ state. :P [02:40] keescook: http://www.potyra.de/vt1.photo.jpg [02:41] hrm, fun. [02:41] * keescook goes looking for where he missed the debug output [02:41] sistpoty: I've got yet-another-patch to try (same bug). This one is a minimal debdiff with only the new opcodes. [02:42] keescook: ok, rebuilding [02:44] keescook, slangasek: should I add my findings to the bug report for documentation, or should I rather not clutter it? [02:45] (as /me dislikes cluttered FFe's for universe *g*) [02:45] sistpoty: if the 3rd one behaves the same, then document it. I'll invalid the FFe if the third one fixes it sanely for you. [02:45] ok [02:46] brb ;) [02:48] aaaah, upstream changes made debug sane, and thunk.c still had it enabled. [02:49] * keescook holds his breath [02:49] keescook: 3rd one still works, but tty1 is cluttered with assembly as well [02:50] sistpoty: okay, I think I tracked down the cause of the clutter, but I'm curious why I don't see it on my system. :P [02:50] keescook: should usplash display some text? (the first one did, but I was bitten by a fsck then) [02:50] heh [02:51] sistpoty: not unless you have "quiet" removed from your boot arguments [02:51] ah, k [02:53] keescook: if it helps, I've got a "VGA compatible controller: nVidia Corporation GeForce 8500 GT (rev a1) (prog-if 00 [VGA controller])" (amd64x2, not too sure what's interesting from cpuinfo ;) [02:54] mostly I'm just scratching my head over why I don't get debug output on my system. [02:55] oh! [02:55] keescook: hm.. I've installed the kubuntu usplash thingy, and am running kdm [02:55] (and I'm usually one day behind with updates, since I use a german mirror) [02:56] yeah, it's all self-contained in libx86 -- it's just weird. [02:57] sistpoty: what were you saying earlier about "no video signal" ? [02:57] keescook: if I don't have usplash installed, I don't get a video signal until kdm starts (since an earlier upgrade from this afternoon already, so I guess it's unrelated to libx86) [02:58] might be just, that my monitor doesn't support a specific mode though [03:00] sistpoty: hm, i'm seeing an identical situation in my test system -- once x starts, I can't switch to a vt [03:00] or, I can, it's just "no video signal" [03:00] hmpf [03:02] keescook: no, once X starts, I *can* switch to a VT when not having usplash installed, but not before that [03:02] sistpoty: and if you have usplash installed, you can switch to/from X okay? [03:03] (this may be simple an issue with the gutsy nvidia driver -- my test machine isn't hardy) [03:03] keescook: yes, seems like it doesn't matter if I have usplash installed for that behaviour [03:03] okay, then I don't think there's a regression. now, the spewing of asm instructions to your console -- is it actually visible? [03:04] (during boot?) [03:04] keescook: not during boot, only when switching to it afterwards [03:04] okay, that sounds something we can fix later. ;) [03:05] yes, right now it's still a big improvement.. (and interestingly, when usplash starts, I can see text on my monitor, so I guess switching to tty's would work then, in contrast to not having usplash installed ;) [03:06] hahah true [03:06] what's this big regression that you've been working on exactly keescook ? [03:06] slangasek: okay, sounds like the minimal "only new instructions plus fixes for busted ones" patch is sane. [03:07] superm1: bug 147623 (not a regression, but missing usplash on 64bit nvidia) [03:07] ah [03:07] slangasek: okay to upload it? [03:11] slangasek: based on your earlier "I'm okay with only new opcodes", I'll upload it (and mark the FFe invalid -- I'll upload that bundle for intrepid) [04:15] slangasek: do you have an ETA on when cody somerville's re-rolled xubuntu-alternate ISO may be ready? [04:22] Could someone please retag this bug to much higher priority than low? It resulted in data loss for me: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-utils/+bug/194127 [04:22] Launchpad bug 194127 in gnome-utils "gnome-screenshot closes when chosing not to overwrite an existing file" [Unknown,Confirmed] [04:23] * ScottK2 looks [04:24] YokoZar: Please comment to that effect in the bug. [04:24] I lost my screenshot as a result, since the window had changed [04:24] Sure. It's sort of in the first comment though [04:25] ScottK2: how do I get triage permissions, btw? [04:26] I think you have to be a member of one of the bug triage teams. MOTU will get it for you or you can talk to bdmurray in #ubuntu-bugs if you don't have to wait. [04:27] I'll wait a bit then to see if this MOTU thing happens :) I guess being an Ubuntu member doesn't give it by default. [04:38] No. IIRC it's ubuntu-qa you have to be in. [04:39] YokoZar: Is this a regression do you think? [04:50] keescook: Yeah, make sure the debug enabling code doesn't end up in the distro :) [04:50] keescook: Any text output should be fatal in the non-debug build... [04:57] ScottK2: no I think this bug has been that way since gutsy at least...probably earlier [04:58] OK. I made it medium. If it'd been a regression I'd have gone for high. [05:09] may the next month not require a more empty ban list. amen. [05:10] what? [05:10] that very closely skirts "double negative" territory [05:12] as all good religion does. [05:18] yeah i didnt follow that but its cool that you are removing bans [05:18] remove mine from Ubuntu and Ubuntu-ops [05:20] please [05:26] he leaves after i try to find the op that banned him. [05:27] hrmf. children. ALL OF YOU OFF MY LAWN! [05:27] * LaserJock streaks across mneptok's yard [05:28] * mneptok waves his fist impotently, in bermuda shorts and black dress socks [05:29] they have pills now to help with fist impotence, you know [05:30] or "fistile dysfunction", as they say in the biz [05:30] AND STAY OFF! [05:30] heh [05:30] * mneptok goes back to his stories and gin [05:31] ok, no i don't [05:45] mjg59: that's the part I don't understand -- the diff between what I uploaded and what was already uploaded contains no changes to debugging. (perhaps sistpoty was already using a debug-enabled one?) [05:45] mjg59: I haven't seen the output in my tests. [05:49] mjg59: btw, doesn't an update of libx86 require a update-initramfs run? [05:49] (I could just version-bump usplash....) === hunger_t is now known as hunger [08:14] * pwnguin has a question about deb tarballs versus the .diff [08:15] if you upgrade a package to a new svn revision from upstream, does that go in as a new tarball or a large .diff? [08:16] where is the transition from the debian to ubuntu archives controlled, i.e. which debian packages make it over and which don't? [08:18] cq: partly, its a matter of the schedule. new packages can come in up until the appropriate freeze, after which there's only exceptional circumstances allowed. but i imagine you're curious about the automated part [08:18] no, actually the process... do you take stable or testing, and then freeze it for a release, and rinse, lather, repeat? [08:19] you're close [08:19] the process is branch unstable where appropriate [08:19] then try to stablize that code with various freezes [08:21] during that time bugs are filed, patches are applied, etc [08:22] ok. so the changes between 7.10 and 8.04 are a whole bunch, depending on what got taken and frozen [08:22] can be [08:22] and in whole, absolutely different [08:23] if no changes come in in six months, that's either a pretty stable program or a pretty stagnant one [08:25] and how do kubuntu and ubunto differ, kubuntu sits on ubuntu with a different installer and KDE, or is there more? [08:25] at this junction, kubuntu is a set of packages and an installer within ubuntu repos, no different than say ubuntu-server [08:26] originally, it was a small community formed in protest to the decision to select gnome formally ;) [08:29] lol ... the usual free software discussions :) [08:29] right, and the usual free software response: more software :) [08:30] isn't it possible to make ubuntu a subset of debian the way kubuntu is a set of packages? [08:31] or is the process to get stuff into debian too long, or is ubunto too different in installation? [08:32] ubuntu orginated as a fork of debian for many reasons, and this is starting to veer away from -devel related topics [08:32] I'm just interested in teh technical ones, not the political ones... [08:32] politics takes too much time :) [08:32] well [08:32] heh, precisely [08:33] i mean, ubuntu feeds stuff back upstream to debian as far as I know [08:34] the basic problem with debian that I, having no formal relationship or status within Ubuntu, is that debian is slow and adversarial [08:35] rather than attempt to change from within, i think ubuntu has set forth a few good examples of how to do things better socially [08:36] man what a lot of distributions... just looking at what distributions are around. [08:36] theres a lot of different kinds of people out there [08:38] cq: as an example of the difficulties with merging ubuntu back, imagine a scenario where you'l like a patch included as an ubuntu developer, but the debian developer who owns the package disagrees [08:38] you can go further upstream [08:39] just leaves me wondering where linux would be with 50% less distributions... [08:40] it'd be without a flagship USB drive distro, and a ps3 distro, and a build from scratch distro, and a handicap accessible distro, and a forensics distro [08:40] and a live cd distro [08:41] ...but probably a lot closer to the desktop [08:41] i guess the splinter experiments are necessary to show the big ones what to integrate [08:41] thats a pretty huge sacrifice [08:42] yeah [08:42] if you look at the millions apple's spent in the name of marketshare, i'd say throwing all that away in the name of unity is silly. [08:42] doko: when you're back you could give-back gnome-desktop-sharp2 where it failed, i.e. sparc and powerpc and ia64 [08:42] the splinter experiments are appropriate for some corner cases though. it's the ones that try to re-invent the window and have a better "desktop" OS that hurt [08:43] heh, there should be some disclosure here [08:43] superm1 works on mythbuntu ;) [08:43] hehe :) [08:43] speaking of which, i demand joystick support! [08:43] well but i mean all our development happens in ubuntu though, so we don't do too much harm [08:43] its in [08:44] superm1: If you get joystick support, could you also do remote control support for games? [08:44] that's what I mean though, if you get a good base that's configurable, then you need less splinters and the whole thingmoves faster [08:44] well joystick support works, remote control support in games is a challenge to be honest though [08:45] depends on how you have your remote configured if it would be even considered to be possible at this point [08:45] How did you do joystick support? Separate driver support, or merge of Lirc and /dev/input ? [08:45] if all you do is change package groups etc. and feed everything back, great. [08:45] honestly, i havent tested joystick support since the backport [08:45] persia, the joystick support works off a normal X input device [08:45] well not even X [08:45] just /dev/jsX [08:46] should have said [08:46] cq: ubuntu distinguishes itself from debian by embracing, rather than hiding, from users, and predictable release cycles [08:46] Ah, but lirc is still separate? That's what I thought, and was wildly excited for a brief period. [08:46] yeah lirc is still separate. quite the little bastard kid too [08:47] personally, i'd just as soon use a wiimote [08:47] i'm hopefully going to try to triage a bunch of its offspring bugs tomorrow [08:47] not enough buttons on it to be useful [08:47] Always good to prune the orchard :) [08:47] does ubuntu run on all the systems debian runs on? or is it more focused on the core PC systems [08:47] cq: oh, debian still has more arch ports [08:48] persia: how many buttons would you need to be useful? [08:48] pwnguin: I have four input devices with over 100, and I'm still not happy :p (but I think you didn't mean to ask me) [08:49] pwnguin, you mean to direct that at me ? [08:49] ah, yes [08:49] pwnguin, 2x vol, 2x chan, play/pause, stop,ff,rr,skip+,skip-, esc [08:49] 2x volume? [08:49] vol+/vol- [08:50] stop and esc can be combined [08:50] so that's 10 buttons to be useful for me [08:50] well and up/down/left/right of course [08:50] 14 :) [08:50] 10? I count 11 (or 15) [08:50] the wiimote itself has 11 plus extensions [08:50] play/pause is one [08:51] pwnguin, but they're hardly intuitive however you spin it [08:51] home = esc seems reasonable [08:51] Ah. Right. [08:52] okay so arrows = arrows, +/- = either vol +/-, 1/2 is chan+/-, but then you still have all the skips [08:52] and the play pause [08:52] http://distrowatch.com/dwres.php?resource=major seems like a good distro comparison [08:52] what are the arrows for? [08:52] menus [08:52] shouldnt that be seperate? [08:53] you mean external controller? [08:53] no, i mean, menu controls seperate from mplayer controls ;) [08:53] oh i'm saying mythtv controls, not mplayer controls [08:54] well, im still using mplayer for playback [08:54] no tvtuner [08:54] with 0.21, the internal player is fairly nice. don't necessarily need to call an external player for stuff [08:55] what do the arrows do with the internal player? [08:55] large skips [08:55] and if you hit menu to choose menu stuff [08:56] i think you could define a set of contexts wherein 10 or 11 buttons would work [08:56] but right now, wminput needs work first [08:57] i see. well if you come up with a good layout, i'll pair one of my wiimotes and give it a shot some day [08:57] :) [08:57] no need to pair [08:57] just turn off the wii and hit 1+2 [08:57] its a standard BT device? [08:57] yea [08:57] it doesnt need to pair? [08:58] you can tell it to be promiscous [08:58] oh neat [08:58] well that's far more useful then [08:58] i didn't like the idea of having to pair back and forth between the two [08:59] lemme have a look at my current binding [08:59] it's not the greatest [08:59] but it passes for navigation so far [09:00] well i can't test until at least early next week anyhow. my little usb/bt adapter for pc is in the office [09:00] the thing to watch out for is that wminput doesn't set lights [09:00] or disconnect on long idle sessions [09:01] or handle multiple wiimotes readily yet. and it seems to crash on daemon mode for me on the mythbox [09:01] but not on my desktop [09:01] i guess what im saying is patches welcome ;) [09:02] hehe [09:33] cannot remove /var/lib/apt/lists/lock: read only filesystem huh?? [09:34] I have one huge partition, and it's mounted RO for some reason... any ideas? [09:34] check dmesg for signs of a kernel problem [09:35] (kernel/disk) [09:35] argh. [09:35] had that yesterday. "attempt to access beyond end of device". just did a clean reintsall, still there [09:36] memory check was OK... ran that yesterday too [09:37] would a fsck solve that problem, or is that a disk or other hardware problem? [09:40] pitti, langpack update? Please? [09:41] cq: I don't know; "attempt to access beyond end of device" could mean that the filesystem and the partition table don't agree about the size of the disk [09:42] it could mean your hardware has problems accessing very large disks, if this is a new disk? [09:42] (in an old system) [09:52] hm. system is a few years old, not sure how old, disk is 30GB and newer. [09:52] fujitsu siemens amilo k 7600 [09:56] would reinstalling to a smaller partition, say 8gb help? [09:57] and use the other one as a user partition? [09:57] fg [09:58] Do packages pushed to ppa have to have source in tar.gz format, or can I have orig.tar.bz2? [09:59] or how can I test if the HD works with the machine? [09:59] YokoZar: You may get a better answer to that in #launchpad [10:00] persia: do you know of any source restrictions for officially uploaded packages? [10:00] I know almost nothing about launchpad internals [10:04] TomaszD: tonight we'll get the latest Rosetta export, and tomorrow early morning the cronjob will build and upload them [10:04] pitti, ok [10:04] mjg59: ah, that sounds easy enough; thanks === DktrKran12 is now known as DktrKranz2 [10:35] Hi all [10:35] Does anyone know why the command update-mozilla-firefox-chrome is not available in beta 4 of firefox 3? [10:35] I am in the beta of Hardy now [10:35] slangasek: thanks for cleaning up after me (hal) [10:47] gnome-desktop-sharp2 given back [10:47] slomo_: ^^^ [10:47] thanks :) [10:57] slangasek: if you're awake, can you get the gnome-desktop-sharp2 binary packages accepted from binary NEW? they're finally built on all archs and two packages from main are waiting for it (or more specific libgtkhtml3.16-cil) [10:58] Is there anyone ...? [10:58] pitti: or you? :) [10:59] slomo_: me? [10:59] ah [10:59] looking [10:59] you can move gtkhtml3.8 out of main afterwards iirc [11:00] yay [11:01] slomo_: hm, why didn't it build on i386? [11:01] NEW only has sparc, ia64, and powerpc [11:01] pitti: buildlog_ubuntu-hardy-i386.gnome-desktop-sharp2_2.20.1-2ubuntu2_FULLYBUILT.txt.gz [11:01] it has :) [11:01]