[00:01] evil udev :( [00:04] ogra_cmpc: I guess the experiment failed? === bjf is now known as bjf[afk] [00:05] Chipzz, no, i didnt start it yet [00:06] i cant get wlan to work on the device i want to try it [00:06] and the kernel is to old for newer udev [00:06] i'll try it as soon as i can [00:07] hm. [00:07] debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable [00:07] but udev and upstart are the ones that prevent me from using maverick on that machine [00:07] I have seen this in several bug reports over the past 2 months [00:08] SpamapS: "some other package manager is running" [00:10] please don't reassign such bugs to debconf in any event. I can't do anything with them there [00:12] cjwatson: regarding the installer name rename, I understand and agree :) [00:12] cjwatson, well, you could dump the processlist somewhere from debconf with that error :) [00:13] elmo: are there any actual real differences (from an ubuntu perspective) between amd64 and em64t? [00:14] cjwatson: yes I think its doing its job. [00:14] cjwatson: I just wonder if we shouldn't add a feature to *list* the lock holder. [00:15] cjwatson: my guess is somebody is running apt-get while update manager is running in the background already. [00:18] btw, the latest i386 mini.iso works great. ;) === jjohansen is now known as jj-afk === bjf[afk] is now known as bjf [00:59] p'tahk [01:04] pitti: https://bugs.launchpad.net/ubuntu/+source/ubuntu-font-family-sources/+bug/650729 [01:04] Launchpad bug 650729 in ubuntu-font-family-sources (Ubuntu) "Ubuntu Font should support (at least some) Klingon" [Wishlist,New] [01:12] Has lifeless been at the ubuntu-font bugtracker? :) [01:40] RAOF: no [01:40] RAOF: I added klingon for pitti/keybuk etc. [01:40] RAOF: I don't speak/read it at all [01:42] Aaah. === ivoks is now known as ivoks-afk [01:44] RAOF: I just happen to be (sadly) familiar with the black hole that is i18n [01:44] having found the skeletons [01:45] Heh. [01:46] Why does the source package have '-sources' on the end? [02:15] I'm working on porting some networking stuff for my business from windows to Ubuntu. It was originally written in .NET, so I was considering MonoDevelop; then I heard of KDevelop (C++), which also worked amazingly well. So I was wondering if anything is 'better' about using KDevelop or MonoDevelop as an IDE. [02:17] Is there anything better about one or the other? [03:25] is there a channel specific to theme issues? the new default theme in maverick apparently uses a dark color for the default window foreground color.... the gnome cpu frequency monitor applet seems to use this for its font when displaying on the pannel, which also has a dark background, making it impossible to read. Is the applet using the wrong theme attribute, or is the theme broken? [03:34] Hi, for a new upstream version update, if there are no Ubuntu specific changes, and it would normally be a Debian sync, except Debian's frozen, is it still appropriate to use -0ubuntu1 ? [03:34] Or, is this a case where it's reasonable to use -0build1, so the autosync happens automatically in natty? [03:35] maxb: can it go into experimental? [03:35] you can sync from there [03:35] maxb: we just stick that stuff in experimental and sync from that for X stuff [03:35] experimental is already occupied with an upstream beta [03:35] too slow! :) [03:35] package is bzr, ftr [03:37] * micahg would think to use -0ubuntu1 and then file a sync bug when natty opens or the first version becomes available [03:42] maxb: sid and squeeze have different versions, you can't upload to sid? [03:43] No. Sid's reserved for things which should end up in Squeeze, and that's frozen. [03:43] RAOF: well, the package isn't migrating anyways and the versions are different [03:43] Jelmer says sid and squeeze only have different versions because of a particularly unfortunate freeze timing, and doesn't want to compound the difference [03:43] sid has 2.2.0-1 and squeeze had 2.1.2-1 [03:44] * micahg doesn't see the difference between 2.2.0 and 2.2.1 in sid at this point... [04:28] anyone op in #ubuntu? why am I banned? [04:32] hagabaka: You should ask your questino in #ubuntu-ops I think. [04:32] thanks [04:34] maxb: Use -0ubuntu1 if it's not in Debian yet. [05:25] hello, is anyone awake? === SolidLiq is now known as solid_liq [05:26] Well, I guess I'll wait until later === diwic is now known as diwic_afk [05:44] !ask | pathogen [05:44] pathogen: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) [06:05] I'm just curious, but how will client side window handling affect things like kwin window tabbing? [06:07] They won't, unless kwin claims to support CSD. [06:08] Hmm [06:08] So, what's the benefit of client side windows then? Other than being bale to skin themselves [06:09] *being able [06:09] You mean “client side *decorations* ”, here. [06:09] right [06:09] Both GTK and Qt use client-side-windows already :) [06:09] lol [06:09] Yes, so what's the benefit of using a client handled window decoration? [06:10] One benefit is that apps can skin themselves *consistently* [06:10] it'll make window management a mess... [06:10] Why? [06:10] Apps are already able to skin themselves. It's just a lot of effort to both skin yourself *and* be consistent with the rest of the desktop. [06:10] Well, you say that apps will be able to skin themselves consistently, but in turn, there won't be a consistent theme of window decoration for all apps [06:11] Why not? [06:11] Apps can do this *right now* - Chromium does it, for example. [06:11] If you use emerald for example to skin your windows, the client side skinned ones will stand out [06:11] Right. [06:11] my point exactly [06:11] chromium sticks out like a sore thumb [06:11] So, emerald doesn't set the “I support CSD” bit, and nothing uses it. [06:12] hmm [06:12] (One of) the idea(s) of CSD is to allow apps to do something like Chromium but *without* sticking out like a sore thumb. [06:13] So, if using a window manager without the CSD bit, the application will still have full functionality? [06:13] or will that be the app's developer's choice? [06:13] Part of the app developer's choice. [06:13] hm [06:14] It will mean that the *toolkit* (ie: GTK and Qt) won't draw the decorations. [06:15] Is CSD being developed in qt right now? [06:15] or is it just a gtk thing for the most part? [06:16] I believe that Qt's been able to draw its own decorations forever. [06:16] (essentially) [06:16] I see [06:17] I guess there's not much of hope of consistency between qt's window drawing style and gtk's window drawing style [06:19] Actually, probably more so if GTK goes CSD - after all, Qt currently sets a QtGtkStyle, so GTK apps fit in nicely. [06:20] I've tested that out for a while on my machine, but it was a bit buggy at times [06:20] I've had a lot of success with qtcurve themes though [06:20] those are themes designed to look the same [06:20] as in reimplemented using different engines [06:21] right [06:21] but it works very well [06:21] of course it does. [06:21] if you wish to reimplement every nice looking theme you have in both gtk+ and qt, i think you'll find that they all will work very well too. [06:21] hmm [06:22] what's needed is the reverse of the gtk style in qt [06:22] which makes qt apps look at home in GNOME. [06:22] afaik there was an engine for gtk that rendered using qt3 [06:22] and it worked pretty good [06:22] ah I see what you mean [06:22] then qt4 arrived, and the reverse happened [06:23] For a second I thought you were talking about making qt4 look like gtk [06:23] not that i'm complaining though, i'm a GNOME user. [06:23] instead of gtk look like qt4 [06:23] I agree completely [06:23] qt4 already looks like gtk with that engine =) [06:23] now gtk needs to look like at4. [06:23] yeah [06:23] qt4* [06:23] I have a lot of qt apps, more than gtk [06:24] i have a lot of gtk apps, more than qt. [06:24] my gtk ones always look out of place [06:24] it annoys me that kde themes are completely different, though [06:24] hmm [06:24] as in i can't use KDE applications without some kind of hack to make them use the gtk theme [06:24] Yeah, I wish there was a universal theme engine [06:24] * hyperair nods [06:25] The closest I can get so far is qtcurve [06:25] either way i've tried switching to KDE a few times in the past, and could never figure out where all the settings were [06:25] at least GNOME's settings are in intuitive places [06:25] all in one place [06:25] even if they're missing. [06:26] systemsettigns in the terminal will give you all of the settings for kde [06:26] yes i know [06:26] *systemsettings [06:26] the problem is hunting for the setting you want *inside* systemsettings [06:26] they're all over the place [06:26] Have you used any of the more recent kde builds? [06:26] in fact, i haven't been able to find the kwin settings for ages [06:26] no, i don't think so [06:26] i use what's in lucid [06:27] when maverick arrives i might give it another go [06:27] They've cleaned it up a LOT in the newest 4.5 release [06:27] but i hate amarok. [06:27] meh [06:27] amarok 1.4 was good [06:27] amarok 2 was ¬_¬ [06:27] ^ this [06:27] Yeah, I disliked amarok 2 for a long time [06:27] but banshee 1.x beats amarok 1.4 flat =p [06:27] I still thing it has far too much bloat [06:27] hmm [06:27] the interface is weird. [06:27] never used banshee [06:28] you should give it a go. [06:28] it's a GNOME app though [06:28] you should try out clementine [06:28] doesn't look like it's in the ubuntu repository [06:28] http://code.google.com/p/clementine-player/ [06:29] debian 579859 [06:29] Debian bug 579859 in wnpp "ITP: clementine -- Music player and library organizer" [Wishlist,Open] http://bugs.debian.org/579859 [06:29] lol [06:29] I think it's already got debian packages ready to roll [06:30] It's basically a clone of amarok 1.4 written for qt4 [06:30] ah [06:30] i see [06:30] it's not up to feature parity yet, but it's still pretty nice [06:31] very light, integrated with the new projectM, and quick database searches [06:31] now here's one thing i really don't like about amarok 1.4: there isn't really a specific playlists view [06:31] i mean there isn't any proper separation between "entire library" and "playlist" [06:31] so i had to maintain them separately [06:32] what do you mean? [06:32] and every time i changed the playlist, it took a long time to repopulate. [06:32] try using banshee, you'll get what i mean. [06:32] Wait, I think I know what you mean [06:32] haha [06:32] hmm [06:32] apart from that, amarok's searching was #1 at that time. [06:33] I never really had a problem with that [06:33] until banshee appeared [06:33] Yeah, I'm not wuite sure what the amarok devs were thinking when they made amarok 2 [06:34] Pretty much everyone aknowledged that amarok 1.x was the best linux music player [06:34] until banshee 1.x came along [06:34] i jumped ship at 0.98.1 [06:34] well, just installed it and it froze... [06:35] banshee 0.1x was nowhere near amarok 1.4, but banshee 1.x is great [06:35] which version? [06:35] froze, i mean. [06:35] 1.7.6 [06:35] right, that one has a bug regarding a race condition with dbus [06:35] between some dbus and network thing [06:35] 1.7.5 is fine [06:35] and 1.8.0 will be fine. [06:36] in fact, 1.8.0 is due today [06:36] hm [06:36] well, I'm running updates now so it should get fixed (I hope) [06:37] have you tried clementine yet? [06:37] nope. [06:37] i might give it a go the next time i try kde4 [06:37] which will be when i upgrade to maverick. [06:37] do you not have any qt dependancies installed or something? [06:38] i have. [06:38] but none of the -dev [06:38] and i'm lazy to get those at the moment. [06:38] you don't have to build it [06:38] it's already pre-built [06:38] even in a .deb [06:38] besieds, i have to get to packaging pdfmod, followed by libgpod and then banshee. [06:39] it's more of a time constraints thing [06:39] *facepalm* [06:39] i've got a crapton of things to do, or i'll be spending time trying out compiz++ and posting backtraces [06:39] I thought you really liked banshee? [06:39] yes, i'm banshee's maintainer. [06:40] why wouldn't you have it already XD [06:40] because 1.8.0 hasn't been released? [06:40] ah [06:40] and it's due for release today? [06:40] i think i mentioned this earlier ¬_¬ [06:40] I see [06:41] banshee 1.8.0 will require libgpod from git. [06:41] hmm [06:41] but libgpod is also getting released today [06:41] on git? [06:41] so i'll have to wait for that first [06:41] no, it'll be released, as in 0.7.95 [06:41] oh I see [06:42] So is maintaining banshee something you do as a hobby, or is it your job? [06:43] I'm just curious because I've always wanted to get involved in the FOSS scene, but didn't see how I could [06:43] it's a hobby [06:44] and also my starting point towards becoming an ubuntu developer [06:45] So, what does maintaining a project like banshee entail? [06:45] hyperair: I assume at this point banshee 1.8 is not going into maverick, given main frozen, libgpod in main, etc. [06:45] more like maintaining the package. [06:46] TheMuso: err oh crap, i forgot that. [06:46] hyperair: banshee is still in universe [06:46] So you download the releases, compile them for various architectures, and then submit them to the repository? [06:46] micahg: but libgpod needs tobe updated. [06:46] pathogen: no, i download the release, prepare the source package, and upload to ubuntu. it gets built for different architectures there [06:46] Oh, I see [06:47] What usually has to be done to prepare the source? [06:47] TheMuso: could we get a freeze exception for that, i wonder. [06:48] hyperair: Given libgpod is on the Ubuntu CD, and given we are frozen for RC, and given that the absolute minimum amount of changes are generally made between RC and final, doubtful. [06:48] I could be wrong though. [06:48] =\ [06:48] Another option would be to 0-day SRU it. [06:48] * hyperair sighs. it's always a rush during finalfreeze [06:49] Yeah there is that... [06:49] what is a 0-day SRU? [06:49] An update that's ready to go on release day. [06:49] Oh, I see [06:49] Because respinning/retesting the CDs is a significant effort. [06:50] maybe i could take that path. [06:50] So instead of adding it to the cd, you just make it a zero day update [06:50] Laney, directhex: what do you think? [06:50] * RAOF wishes mesa also had a “absolute minimum changes after RC” policy. [06:50] RAOF: heh [06:50] RAOF: that takes all the fun out of life [06:50] It was looking so good, too! [06:51] There were just a couple of commits since our very-nearly-RC1 snapshot. [06:51] RAOF: But is mesa on a timed release schedule? [06:51] It's expected to release on December 4. [06:52] Right. [06:52] Oh. [06:52] Whoops. [06:52] *October* 4 [06:52] lol [06:52] I was going to say... :) [06:52] mesa is a graphics library for X? [06:52] it's where all our 3d drivers are [06:52] And, of course, the best thing to do post RC1 is to pull in the Sandybridge driver. [06:53] I see [06:53] ahem, lovely. [06:54] Because practically *nobody* has hardware driven by i965_dri.so :( [06:54] new driver, or major changes to the existing driver? [06:54] I do [06:54] Changes to the existing driver. [06:54] o/ as well [06:55] RAOF: that don't sound very RC-worthy :P [06:55] RAOF: what! i do! [06:55] wow [06:55] I can't stop laughing about it hear actually, its certainly not RC worthy in my book. [06:55] basically everyone here has that hardware [06:55] micahg, ajmitch: Hush. Everyone knows that intel's GPUs are only aimed at a tiny niche audience : [06:55] those who want battery life? [06:55] I can feel the sarcasm oozing from your text [06:56] of course, I don't have any current hardware with intel drivers, so they can't be that important :) [06:56] Afaik sandybridge is not really out in the wild yet. [06:56] Indeed it is not. [06:56] So it could have waited. [06:56] but in 6 months time it may be [06:56] Those who only want static images on their screens. :-P [06:56] Beleive it or not, my intel architecture and gpu has lasted very well through the years [06:57] i915 is a little underpowered for gaming though :) [06:57] Will a little elbow grease, I can make it play even the newest games [06:57] * micahg is guessing the new GPU support is making Flash better on Maverick even in powersave mode [06:57] at fairly acceptable framerates too :D [06:57] ajmitch: hey i play games with my intel chip. [06:57] pathogen: No fair if you're doing the GL transforms on paper [06:57] hyperair: nethack doesn't count [06:57] ROFL [06:57] Portal! [06:57] to both comments [06:57] ajmitch: lol. i play touhou =p [06:58] ajmitch: but my intel chip has a tendency to send my machine into spurious hangs that eventually result in hanging the ethernet chip [06:58] i have no idea what connection there is between a graphics and ethernet chip, but somehow it succeeds. [06:58] lol [06:58] rmmod and modprobe again won't work. the only thing that works is suspending and resuming [06:58] * ajmitch has the joys of using fglrx still [06:58] or of course, a complete shutdown [06:58] ajmitch: Ewwww [06:59] hyperair: I am surprised even that works. [06:59] using the compiz cube would randomly lock up my desktop 3 years ago [06:59] TheMuso: which one? [06:59] * StevenK hugs his GeForce, and then treats the burn [06:59] StevenK: yeah, it's not exactly easy to figure out why resuming often makes everything dog slow :) [06:59] Suspending and resuming. [06:59] StevenK: Sizzle! [06:59] TheMuso: yeah i was pretty surprised too. [06:59] * TheMuso thought a shutdown would be the only way to clear it. [06:59] * hyperair shrugs [06:59] if i suspend and resume, then wait, say 15 minutes, i can game for another hour [07:00] The GPU does get fully shut down on suspend then reinitialised on resume, so it's possible. [07:00] Has anyone got a compaq presario cq60 laptop? [07:00] RAOF: ah ok, makes more sense. [07:00] Perhaps more surprising is that you can actually suspend at all ;) [07:00] * micahg is guessing that's why apport shows 127 apport GPU crashes on resume :) [07:00] RAOF: but what about the ethernet chip? [07:00] The laptop always hangs when suspending to the hard drive... [07:00] hyperair: The GPU can scribble on arbitrary memory! [07:01] RAOF: ...oh crap. [07:01] pathogen: that's a feature. [07:01] Doesn't _that_ make you feel safer with WebGL? :) [07:01] hyperair: riiiiiiiight.... [07:02] RAOF: wtf is webgl? D= [07:02] RAOF: who needs their data anyway? [07:02] webgl is fairly cool [07:02] hyperair: the ability to play quake in the browser [07:02] it allows a webpage to run script in opengl using your gpu [07:02] hyperair: Pretty much what it says on the box: OpenGL for web clients. [07:02] pathogen: yep, it's meant to spread the word that suspend-to-disk is a dumb concept and people should focus their efforts on making suspend-to-ram better. [07:02] RAOF: heh lol =p [07:03] My old acer sapire could run for days while suspended [07:03] so if the gpu can scribble on arbitrary memory, how come my apps aren't segfaulting? [07:03] I was inpressed [07:03] and only the transmission portion of my tg3 card hangs? [07:03] receiving still works [07:04] hyperair: Probably because that's not the issue. Or because your GPU has a bug which deterministically scribbles on a specific part of your ethernet card's MMIO space? [07:04] * hyperair groans [07:04] =( [07:04] then shouldn't rmmod and modprobe reinitialize the card? [07:05] Not if the state is broken. [07:05] they reinitialize the kernel drivers [07:05] I guess it could be possible for the GPU to be in a state the driver doesn't know how to recover from, but doesn't break suspend. [07:05] but, the problem prolly exists on the hardware level [07:06] in that case, power cycling fixes it [07:06] or suspend/resume =p [07:07] perhaps, perhaps depending on the architecture of the computer [07:07] in my case, graphics works, it's just the ethernet portion that hangs [07:07] pretty strange [07:07] Well, I'm off to bed [07:07] happy sleeping [07:08] I shall! === diwic_afk is now known as diwic [07:45] Good morning [07:45] highvoltage: heh [07:47] Morning pitti. [07:48] hey TheMuso [07:56] Howdie pitti. === hunger is now known as Guest82770 === Guest82770 is now known as hunger|home === smb` is now known as smb === smb is now known as smb` === smb` is now known as smb [08:43] good morning === spike_ is now known as spikeWRK [09:09] pitti: i'm seeking your further advice on bug 636930 [09:09] Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo'" [High,Triaged] https://launchpad.net/bugs/636930 [09:09] can we kick off an SRU from the 2.2.1 microrelease there? [09:09] poolie: we can, yes [09:09] poolie: a few days ago we were still open for last-minute changes, but now it needs to become an SRU, I'm afraid [09:10] that's ok [09:11] will it be on hold until after 10/10, or can that happen in parallel with the release? [09:12] poolie: it can be uploaded before [09:12] poolie: the queue is open, but we won't accept it until very near the release [09:12] ok [09:13] bit of a shame we didn't hit that, but it's better not to rush [09:13] so what do we need to do now to get it into that queue? [09:15] poolie: just uploading it, with making sure that the changelog refers to all bugs, etc. [09:19] ttx: wrt bug 650893, I suppose you don't have dbus installed on server, right? [09:19] Launchpad bug 650893 in cups (Ubuntu Maverick) "[maverick] cups does not start at boot time" [High,New] https://launchpad.net/bugs/650893 [09:20] so I guess I'll again hit the wall of how to specify weak dependencies in "start on" clauses [09:22] slangasek: would something like this work for "start after dbus if present"? [09:22] ... and (started dbus or runlevel [2345]) and .. === asac_ is now known as asac [09:25] cjwatson, Its not really a big issue but has the option to set an apt proxy at installation time to be used for the downloads been dropped consciously or was it more a side effect. Or should I have read some installation notes which would have explained it to me where things have gone? [09:25] bdrung_, hi [09:25] ttx: I sent a proposed upstart script to the bug, would be awesome if you could test it [09:26] bdrung_, why did you start the discussion about the sponsoring process on -discuss? It's probably a list that most concerned people don't read if they are busy [09:31] pitti: I'll reinstall one "print server" now [09:33] seb128: because 'discuss' was in the name. where should i have send the mail? === doko_ is now known as doko [09:35] pitti: i'm not sure if maxb can upload it to proposed(?), could you do it if he can't? [09:36] bdrung_, not sure, it might be right for getting opinions but u-d might be better to get the process changed or replies from people doing sponsoring [09:36] poolie: upload permissions aren't pocket specific; so anyone who can upload to devel can upload to proposed as well [09:38] ok [09:38] seb128: or ubuntu-motu? [09:39] bdrung_, it's likely not everybody is reading the motu list [09:39] bdrung_, I guess busy people only read u-d, not sure if you want feedback from everybody though [09:40] bdrung_, u-d is likely best. u-m is mostly interesting only when there's something that only affects MOTU. u-d-d is for coordination between developers and users (this would be mostly between developers) === almaisan-away is now known as al-maisan [09:45] Wow. Looking at https://edge.launchpad.net/builders makes me feel like uploading something :) [09:45] before they get too bored [09:46] open natty! open natty! [09:46] "is natty open yet?" [09:47] So, I know we have a more streamlined process, but I believe we still have to complete each release before we can open the next one. [09:47] It was going to be opened in 2 hours, but now that you've asked, it's 3. [09:47] <\sh> sed -i "s/maverick/natty/" /etc/apt/sources.list ; apt-get update ; apt-get dist-upgrade [09:47] But there's lots of other stuff that needs building. Anyone run `apt-cache -i unmet` recently? [09:48] StevenK, You already fixed Soyuz so we can start asking this early, and only pay a 1-hour delay? [09:48] <\sh> persia: and as scottk proposed: http://qa.ubuntuwire.com/bugs/rcbugs/ [09:48] StevenK: oh, I thought it wouldn't even be possible as long as maverick is still open? [09:48] persia: No, I was trying to make a joke that references the releaseparty deley [09:48] *delay [09:49] StevenK, It was a good joke. Please fix Soyuz so that you can tease us like that. [09:49] hah. now you've been told! [09:50] * StevenK goes back to writing bugs [09:51] <\sh> persia: and not forgetting the list of FTBFS packages...still in bad shape [09:52] smb: text or graphical installer? [09:53] cjwatson, Personally I only saw the Kubuntu graphical and the alternate text installer, but cking said he did not remember seeing that option in the Ubuntu graphical installer either. [09:54] smb: I was kind of hoping for a single answer [09:54] cjwatson, "all" ? === oSoMoN_ is now known as oSoMoN [09:54] pitti: tested, works, commented on the bug [09:55] * ttx is about to leave to catch a train [09:55] ttx: yippie [09:55] * pitti commits [09:55] smb: nothing has changed regarding the proxy option in the text installer, as far as I know [09:55] smb: for the graphical installer, you would have to ask ev [09:56] pitti: for post-RC, or do you think we should trigger a respin for that ? [09:56] Daviey: about to leave, any question ? [09:56] ttx: that's a question for you really, but my gut feeling is that post RC is sufficient, with a release note [09:56] pitti: that's my feeling too. [09:56] cjwatson, ok, let me pay closer attention on it for the text installer, maybe I just missed it. Will have a look at the graphical again as well and talk to ev [09:57] smb: it's not exposed in the UI anymore. [09:57] for the graphical installer [09:57] if anything else comes up that warrants a respin, then we can catch that one in it [09:57] ev, Ah ok, so its a grub commandline I could test? [09:57] Daviey ^ [09:57] ttx, sorry [09:57] can't possibly be a grub command line [09:57] given that the live CD doesn't boot using grub [09:58] (yet) [09:58] I think he means kernel command line preseeding [09:58] right, just that grub happens the place you enter it most of the time. [09:58] indeed, I'm just nitpicking :) [09:58] smb: mirror/http/proxy=true [09:58] should do it [09:59] err [09:59] mirror/http/proxy=whatever.your.proxy.is [09:59] uh [09:59] oh, yes, indeed :) [09:59] clearly not enough coffee in my et [09:59] yet [09:59] not that form though [09:59] mirror/http/proxy=http://whatever.your.proxy.is/ [09:59] The proxy information should be given in the standard form of [09:59] "http://[[user][:pass]@]host[:port]/". [09:59] right-o [09:59] simple and clear. :-P [10:00] ttx: nope! [10:00] ttx: Have fun :) [10:02] ev, Do we mention option in the release notes? (asked by the person notoriously forgetting to read them) [10:02] Daviey: ok, back in ~4hours [10:04] smb: yeah, definitely === diwic is now known as diwic_afk [10:18] dholbach: you are back? [10:19] bdrung_, yes [10:19] bdrung_, got back yesterday afternoon [10:19] welcome back dholbach [10:19] thanks bdrung_ [10:21] hey [10:21] how do i use bzr correctly with the packages? [10:21] should i always commit before i build? [10:22] because now i have a lot of changes that were caused by debuild [10:29] if you have a package that applies patches during the build, you can always 'debuild clean' before committing [10:30] whether to commit before building is mostly a matter of taste - it does mean that you're committing something you haven't tested yet [10:31] but you can always uncommit. I've run into some issues where if you don't commit, bzr bd builds with files that should have been deleted (bzr rm) [10:33] that's only bzr bd [10:33] (and should be filed as a bug on bzr-builddeb, IMO) === diwic_afk is now known as diwic [10:35] cjwatson: yeah, I need to do that [10:58] micahg: were you able to do anything with Profile-Guided Firefox this cycle? [11:00] YokoZar, no, but i'm working on that for next cycle [11:01] chrisccoulson: does firefox build with a .mozconfig yet or is it still a bunch of command switches in the build script? [11:01] chrisccoulson: sorry for not doing it myself this cycle I know I hinted I would at UDS [11:01] YokoZar, no mozconfig [11:02] chrisccoulson: That should be the path forward then, as once you use the mozconfig file building with PGO is a switch [11:02] YokoZar, yeah, i know ;) [11:03] but it's not just a straight switch to a mozconfig, as we have lots of logic to determine our build flags [11:03] * YokoZar is a bit amazed Firefox performance wasn't a major priority for us years ago... [11:03] chrisccoulson: Yeah, I got about half way going into UDS-maverick before I got distracted with real life ;) [11:03] well, mozilla are working hard to make PGO work, but it's not straightforward. [11:03] it doesn't work well at all with GCC < 4.5 [11:03] Fair enough [11:04] so, unless we use that version next cycle, PGO is a non-starter ;) [11:04] Well we ship GCC 4.5 in maverick, nothing wrong with building Firefox against it ;) [11:04] well, the version we ship will be using the standard toolchain ;) [11:05] chrisccoulson: I don't see anything wrong with building with 4.5? [11:05] pitti - oh, well, if that's the case ;) [11:05] ... in natty (not proposing to switch now in maverick :) ) [11:05] pitti - anyway, there are some bugs in GCC4.5 which break optimisation in firefox [11:06] eg http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623 [11:06] gcc.gnu.org bug 45623 in tree-optimization "[4.5 Regression] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?" [Normal,Resolved: fixed] [11:07] chrisccoulson: you mean fixed in 4.5 yes? [11:07] i don't think it's fixed in the version we have, but i'd need to check [11:07] seeing as it was only fixed a few days ago [11:08] oh so a newer point release of 4.5 [11:09] i really need another machine to do builds on :( === diwic is now known as diwic_afk [11:24] mvo, pitti: I'm using Hardware Drivers to install the B43 Driver and I got SystemError: installArchives() failed. [11:25] davmor2: anything that looks like a error in /var/log/apt/term.log (the last few lines)? [11:25] pitti: also the STA driver seems to of mysteriously stopped connecting on maverick but lucids does connect correctly :( [11:28] mvo: all I got is Log started: date time and Log ended: Date time [11:30] davmor2: anything in /var/log/jockey.log? [11:30] davmor2: I just installed UNE on my mini 10, which auto-installed wl [11:30] (which works fine) [11:32] pitti: mine is a compaq mini 110 and on network-manager said there were no firmware drivers. I installed the STA like I normally do and it sees the router it just won't connect. [11:34] pitti: apport has just woken up and given me an error so I'll send that report [11:40] pitti: bug 651010 [11:40] Launchpad bug 651010 in b43-fwcutter (Ubuntu) "package firmware-b43-installer 4.150.10.5-4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/651010 [11:41] davmor2: hm, what an useless dpkg log :( http://launchpadlibrarian.net/56733878/DpkgTerminalLog.txt [11:41] davmor2: if you do sudo dpkg --configure -a, what do you see? [11:43] pitti: Not support low-power chip with PCI id 14e3:4315! that could be the clincher :) [11:44] hm, and yet the modalias claims to support it? bad b43 [11:44] I seriously consider to just drop the b43 handler for good [11:44] it seems to cause nothing but trouble, and STA is generally better [11:47] pitti: I've added the full info to the bug. I'll try the sta driver again is there anyway I can get the debug info from N-M to get some decent info for you guys? [11:49] probably a quetion for Mathieu [11:49] davmor2: but /var/log/daemon.log should already get quite far [11:49] pitti: thanks :) [11:55] hey pitti. Do we have to discuss when the final full language export should be requested in LP? Arne tended to do it around 22:00 UTC on the day of the translation deadline, so I was thinking of just doing that. [11:55] dpm: I already requested the full export; it shoudl be produced today, right? [11:55] dpm: I'd like to prepare and test them tomorrow, so that they can build right after RC [11:55] pitti, no, the translations deadline is tomorrow [11:56] dpm: but then the next export would only be on Sunday [11:56] <\sh> hmmm...a question to our famous gtk specialist: should libgdk-pixbuf-2.0 ship an .la file or not? [11:57] pitti, I guess we should have discussed that before. Translators look at the schedule and think they can still translate until tomorrow [11:57] <\sh> (which should normally be in the -dev package of the lib) [11:57] dpm: "until today" would be better, I think, otherwise we have zero margin for a rebuild [11:58] \sh: we try to get rid of those beasties as much as we can [11:58] <\sh> pitti: so I have to further patch ginspector to not use it [11:59] \sh: how does it use a .la file? [11:59] pitti, ok, that would be a good compromise, but next cycle we should look at putting the LanguagePackDeadline on the schedule on a day we can actually request the export with enough time [11:59] <\sh> http://paste.ubuntu.com/502566/ [11:59] dpm: *nod*; on a Wed or Sun would make sense, to align with the days when the exports actually happen [12:00] \sh: but usually the .la files need to be cleaned up from top to bottom, i. e. I'd expect GTK to be one of the last packages to drop it [12:00] <\sh> pitti: I just wonder, because libgtk2.0-dev ships as well an .la [12:00] top/bottom in the dependency tree, I mea [12:00] n [12:01] * pitti defers to seb128 [12:01] <\sh> pitti: I'm just trying to fight the ftbfs of ginspector... === diwic_afk is now known as diwic [12:02] pitti, ah, just a question. Why is it a problem that the next export is on Sunday? When requesting a full export, the export is produced straight away, isn't it? (well, not straight away, but just the time it takes to create the tarball) [12:02] so that does not have anything to do with the Sunday's export [12:03] dpm: oh, I understood that differently [12:04] dpm: I thought marking this checkbox means "the next time you create a langapck", not "do an extracurricular export NOW NOW NOW" [12:04] I flipped it on two days ago, and https://translations.edge.launchpad.net/ubuntu/maverick/+language-packs has a full export from today [12:04] so I guess the export starts very early on Wed/Sun, not late [12:04] and the langpacks are then built late in a day, to allow some slack [12:05] pitti, let me check with danilo [12:17] dpm: If you look at http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html there are a number of -kde- language packs listed as uninstallable. I checked and they are all missing updates to the underlying language-pack-foo in the last export. Are those going to be OK this last time around? === cking is now known as cking-afk [12:18] ScottK: yes [12:19] cjwatson: Thanks. [12:19] (checked this a few days ago) [12:19] Excellent. === tkamppeter_ is now known as tkamppeter === badipod is now known as ldunn === MacSlow is now known as MacSlow|lunch [12:42] lool: qemu-kvm is currently listed in Packages-arch-specific as amd64 and i386 only. Apparently nobody noticed since it built fine on armel and powerpc in lucid. A test-build on kakadu shows that it currently fails to build on armel (http://paste.ubuntu.com/502586/). Do you care? [12:43] ogra: ^- ditto [12:44] that failure is apparently in arm-specific assembly code [12:47] cjwatson, well, no clue if it runs, feel free to remove it from PAS [12:47] then we could actually try :) [12:47] well, as I say it certainly doesn't build [12:48] build on powerpc is still going but looking healthier [12:48] oh, sorry i misread [12:48] * ogra is in 10 conversations simultaneously [12:49] then better leave it in PAS until natty :) unless linaro wants to do some last minute debugging here [12:51] well, it's NBS. If I leave it in P-a-s, then I have to remove the stale binary since there's no matching source for it [12:57] * cjwatson grabs a vaguely current ARM ARM to see what the constraints on rndd and friends should be [13:02] cjwatson: I did bring this up with the server team a while ago; Debian has qemu / qemu-kvm and added qemu-kvm to Pas recently [13:03] cjwatson: I do care just a bit, but it's not terribly important really [13:03] I just hate that we have no qemu builds on armel, while Debian builds "qemu" on all arches [13:03] what would the consequences of removing the arm binaries be? [13:03] it might not be that hard to fix this code .. [13:03] cjwatson: Pretty much no consequence I would think [13:04] I guess I'm worried about lurking build-deps and the like [13:04] I really can't think of any, but I didn't grep [13:04] In the future, kvm will be used on armel, but that's still far off [13:04] does anybody know what translation file has the ubiquity string "retrieving files n of n (