| ogra_cmpc | evil udev :( | 00:01 |
|---|---|---|
| Chipzz | ogra_cmpc: I guess the experiment failed? | 00:04 |
| === bjf is now known as bjf[afk] | ||
| ogra_cmpc | Chipzz, no, i didnt start it yet | 00:05 |
| ogra_cmpc | i cant get wlan to work on the device i want to try it | 00:06 |
| ogra_cmpc | and the kernel is to old for newer udev | 00:06 |
| ogra_cmpc | i'll try it as soon as i can | 00:06 |
| SpamapS | hm. | 00:07 |
| SpamapS | debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable | 00:07 |
| ogra_cmpc | but udev and upstart are the ones that prevent me from using maverick on that machine | 00:07 |
| SpamapS | I have seen this in several bug reports over the past 2 months | 00:07 |
| cjwatson | SpamapS: "some other package manager is running" | 00:08 |
| cjwatson | please don't reassign such bugs to debconf in any event. I can't do anything with them there | 00:10 |
| highvoltage | cjwatson: regarding the installer name rename, I understand and agree :) | 00:12 |
| ogra_cmpc | cjwatson, well, you could dump the processlist somewhere from debconf with that error :) | 00:12 |
| highvoltage | elmo: are there any actual real differences (from an ubuntu perspective) between amd64 and em64t? | 00:13 |
| SpamapS | cjwatson: yes I think its doing its job. | 00:14 |
| SpamapS | cjwatson: I just wonder if we shouldn't add a feature to *list* the lock holder. | 00:14 |
| SpamapS | cjwatson: my guess is somebody is running apt-get while update manager is running in the background already. | 00:15 |
| SpamapS | btw, the latest i386 mini.iso works great. ;) | 00:18 |
| === jjohansen is now known as jj-afk | ||
| === bjf[afk] is now known as bjf | ||
| highvoltage | p'tahk | 00:59 |
| highvoltage | pitti: https://bugs.launchpad.net/ubuntu/+source/ubuntu-font-family-sources/+bug/650729 | 01:04 |
| ubottu | Launchpad bug 650729 in ubuntu-font-family-sources (Ubuntu) "Ubuntu Font should support (at least some) Klingon" [Wishlist,New] | 01:04 |
| RAOF | Has lifeless been at the ubuntu-font bugtracker? :) | 01:12 |
| lifeless | RAOF: no | 01:40 |
| lifeless | RAOF: I added klingon for pitti/keybuk etc. | 01:40 |
| lifeless | RAOF: I don't speak/read it at all | 01:40 |
| RAOF | Aaah. | 01:42 |
| === ivoks is now known as ivoks-afk | ||
| lifeless | RAOF: I just happen to be (sadly) familiar with the black hole that is i18n | 01:44 |
| lifeless | having found the skeletons | 01:44 |
| RAOF | Heh. | 01:45 |
| wgrant | Why does the source package have '-sources' on the end? | 01:46 |
| IDWMaster | 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:15 |
| IDWMaster | Is there anything better about one or the other? | 02:17 |
| psusi | 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:25 |
| maxb | 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 |
| maxb | Or, is this a case where it's reasonable to use -0build1, so the autosync happens automatically in natty? | 03:34 |
| micahg | maxb: can it go into experimental? | 03:35 |
| micahg | you can sync from there | 03:35 |
| Sarvatt | maxb: we just stick that stuff in experimental and sync from that for X stuff | 03:35 |
| maxb | experimental is already occupied with an upstream beta | 03:35 |
| Sarvatt | too slow! :) | 03:35 |
| maxb | package is bzr, ftr | 03:35 |
| * micahg would think to use -0ubuntu1 and then file a sync bug when natty opens or the first version becomes available | 03:37 | |
| micahg | maxb: sid and squeeze have different versions, you can't upload to sid? | 03:42 |
| RAOF | No. Sid's reserved for things which should end up in Squeeze, and that's frozen. | 03:43 |
| micahg | RAOF: well, the package isn't migrating anyways and the versions are different | 03:43 |
| maxb | 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 |
| micahg | sid has 2.2.0-1 and squeeze had 2.1.2-1 | 03:43 |
| * micahg doesn't see the difference between 2.2.0 and 2.2.1 in sid at this point... | 03:44 | |
| hagabaka | anyone op in #ubuntu? why am I banned? | 04:28 |
| TheMuso | hagabaka: You should ask your questino in #ubuntu-ops I think. | 04:32 |
| hagabaka | thanks | 04:32 |
| ScottK | maxb: Use -0ubuntu1 if it's not in Debian yet. | 04:34 |
| pathogen | hello, is anyone awake? | 05:25 |
| === SolidLiq is now known as solid_liq | ||
| pathogen | Well, I guess I'll wait until later | 05:26 |
| === diwic is now known as diwic_afk | ||
| micahg | !ask | pathogen | 05:44 |
| ubottu | 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. :-) | 05:44 |
| pathogen | I'm just curious, but how will client side window handling affect things like kwin window tabbing? | 06:05 |
| RAOF | They won't, unless kwin claims to support CSD. | 06:07 |
| pathogen | Hmm | 06:08 |
| pathogen | So, what's the benefit of client side windows then? Other than being bale to skin themselves | 06:08 |
| pathogen | *being able | 06:09 |
| RAOF | You mean “client side *decorations* ”, here. | 06:09 |
| pathogen | right | 06:09 |
| RAOF | Both GTK and Qt use client-side-windows already :) | 06:09 |
| pathogen | lol | 06:09 |
| pathogen | Yes, so what's the benefit of using a client handled window decoration? | 06:09 |
| RAOF | One benefit is that apps can skin themselves *consistently* | 06:10 |
| pathogen | it'll make window management a mess... | 06:10 |
| RAOF | Why? | 06:10 |
| RAOF | 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 |
| pathogen | 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:10 |
| RAOF | Why not? | 06:11 |
| RAOF | Apps can do this *right now* - Chromium does it, for example. | 06:11 |
| pathogen | If you use emerald for example to skin your windows, the client side skinned ones will stand out | 06:11 |
| RAOF | Right. | 06:11 |
| pathogen | my point exactly | 06:11 |
| pathogen | chromium sticks out like a sore thumb | 06:11 |
| RAOF | So, emerald doesn't set the “I support CSD” bit, and nothing uses it. | 06:11 |
| pathogen | hmm | 06:12 |
| RAOF | (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:12 |
| pathogen | So, if using a window manager without the CSD bit, the application will still have full functionality? | 06:13 |
| pathogen | or will that be the app's developer's choice? | 06:13 |
| RAOF | Part of the app developer's choice. | 06:13 |
| pathogen | hm | 06:13 |
| RAOF | It will mean that the *toolkit* (ie: GTK and Qt) won't draw the decorations. | 06:14 |
| pathogen | Is CSD being developed in qt right now? | 06:15 |
| pathogen | or is it just a gtk thing for the most part? | 06:15 |
| RAOF | I believe that Qt's been able to draw its own decorations forever. | 06:16 |
| RAOF | (essentially) | 06:16 |
| pathogen | I see | 06:16 |
| pathogen | I guess there's not much of hope of consistency between qt's window drawing style and gtk's window drawing style | 06:17 |
| RAOF | Actually, probably more so if GTK goes CSD - after all, Qt currently sets a QtGtkStyle, so GTK apps fit in nicely. | 06:19 |
| pathogen | I've tested that out for a while on my machine, but it was a bit buggy at times | 06:20 |
| pathogen | I've had a lot of success with qtcurve themes though | 06:20 |
| hyperair | those are themes designed to look the same | 06:20 |
| hyperair | as in reimplemented using different engines | 06:20 |
| pathogen | right | 06:21 |
| pathogen | but it works very well | 06:21 |
| hyperair | of course it does. | 06:21 |
| hyperair | 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 |
| pathogen | hmm | 06:21 |
| hyperair | what's needed is the reverse of the gtk style in qt | 06:22 |
| hyperair | which makes qt apps look at home in GNOME. | 06:22 |
| hyperair | afaik there was an engine for gtk that rendered using qt3 | 06:22 |
| hyperair | and it worked pretty good | 06:22 |
| pathogen | ah I see what you mean | 06:22 |
| hyperair | then qt4 arrived, and the reverse happened | 06:22 |
| pathogen | For a second I thought you were talking about making qt4 look like gtk | 06:23 |
| hyperair | not that i'm complaining though, i'm a GNOME user. | 06:23 |
| pathogen | instead of gtk look like qt4 | 06:23 |
| pathogen | I agree completely | 06:23 |
| hyperair | qt4 already looks like gtk with that engine =) | 06:23 |
| hyperair | now gtk needs to look like at4. | 06:23 |
| pathogen | yeah | 06:23 |
| hyperair | qt4* | 06:23 |
| pathogen | I have a lot of qt apps, more than gtk | 06:23 |
| hyperair | i have a lot of gtk apps, more than qt. | 06:24 |
| pathogen | my gtk ones always look out of place | 06:24 |
| hyperair | it annoys me that kde themes are completely different, though | 06:24 |
| pathogen | hmm | 06:24 |
| hyperair | as in i can't use KDE applications without some kind of hack to make them use the gtk theme | 06:24 |
| pathogen | Yeah, I wish there was a universal theme engine | 06:24 |
| * hyperair nods | 06:24 | |
| pathogen | The closest I can get so far is qtcurve | 06:25 |
| hyperair | 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 |
| hyperair | at least GNOME's settings are in intuitive places | 06:25 |
| pathogen | all in one place | 06:25 |
| hyperair | even if they're missing. | 06:25 |
| pathogen | systemsettigns in the terminal will give you all of the settings for kde | 06:26 |
| hyperair | yes i know | 06:26 |
| pathogen | *systemsettings | 06:26 |
| hyperair | the problem is hunting for the setting you want *inside* systemsettings | 06:26 |
| hyperair | they're all over the place | 06:26 |
| pathogen | Have you used any of the more recent kde builds? | 06:26 |
| hyperair | in fact, i haven't been able to find the kwin settings for ages | 06:26 |
| hyperair | no, i don't think so | 06:26 |
| hyperair | i use what's in lucid | 06:26 |
| hyperair | when maverick arrives i might give it another go | 06:27 |
| pathogen | They've cleaned it up a LOT in the newest 4.5 release | 06:27 |
| hyperair | but i hate amarok. | 06:27 |
| pathogen | meh | 06:27 |
| hyperair | amarok 1.4 was good | 06:27 |
| hyperair | amarok 2 was ¬_¬ | 06:27 |
| pathogen | ^ this | 06:27 |
| pathogen | Yeah, I disliked amarok 2 for a long time | 06:27 |
| hyperair | but banshee 1.x beats amarok 1.4 flat =p | 06:27 |
| pathogen | I still thing it has far too much bloat | 06:27 |
| pathogen | hmm | 06:27 |
| hyperair | the interface is weird. | 06:27 |
| pathogen | never used banshee | 06:27 |
| hyperair | you should give it a go. | 06:28 |
| hyperair | it's a GNOME app though | 06:28 |
| pathogen | you should try out clementine | 06:28 |
| hyperair | doesn't look like it's in the ubuntu repository | 06:28 |
| pathogen | http://code.google.com/p/clementine-player/ | 06:28 |
| micahg | debian 579859 | 06:29 |
| ubottu | Debian bug 579859 in wnpp "ITP: clementine -- Music player and library organizer" [Wishlist,Open] http://bugs.debian.org/579859 | 06:29 |
| hyperair | lol | 06:29 |
| pathogen | I think it's already got debian packages ready to roll | 06:29 |
| pathogen | It's basically a clone of amarok 1.4 written for qt4 | 06:30 |
| hyperair | ah | 06:30 |
| hyperair | i see | 06:30 |
| pathogen | it's not up to feature parity yet, but it's still pretty nice | 06:30 |
| pathogen | very light, integrated with the new projectM, and quick database searches | 06:31 |
| hyperair | now here's one thing i really don't like about amarok 1.4: there isn't really a specific playlists view | 06:31 |
| hyperair | i mean there isn't any proper separation between "entire library" and "playlist" | 06:31 |
| hyperair | so i had to maintain them separately | 06:31 |
| pathogen | what do you mean? | 06:32 |
| hyperair | and every time i changed the playlist, it took a long time to repopulate. | 06:32 |
| hyperair | try using banshee, you'll get what i mean. | 06:32 |
| pathogen | Wait, I think I know what you mean | 06:32 |
| hyperair | haha | 06:32 |
| pathogen | hmm | 06:32 |
| hyperair | apart from that, amarok's searching was #1 at that time. | 06:32 |
| pathogen | I never really had a problem with that | 06:33 |
| hyperair | until banshee appeared | 06:33 |
| pathogen | Yeah, I'm not wuite sure what the amarok devs were thinking when they made amarok 2 | 06:33 |
| pathogen | Pretty much everyone aknowledged that amarok 1.x was the best linux music player | 06:34 |
| hyperair | until banshee 1.x came along | 06:34 |
| hyperair | i jumped ship at 0.98.1 | 06:34 |
| pathogen | well, just installed it and it froze... | 06:34 |
| hyperair | banshee 0.1x was nowhere near amarok 1.4, but banshee 1.x is great | 06:35 |
| hyperair | which version? | 06:35 |
| hyperair | froze, i mean. | 06:35 |
| pathogen | 1.7.6 | 06:35 |
| hyperair | right, that one has a bug regarding a race condition with dbus | 06:35 |
| hyperair | between some dbus and network thing | 06:35 |
| hyperair | 1.7.5 is fine | 06:35 |
| hyperair | and 1.8.0 will be fine. | 06:35 |
| hyperair | in fact, 1.8.0 is due today | 06:36 |
| pathogen | hm | 06:36 |
| pathogen | well, I'm running updates now so it should get fixed (I hope) | 06:36 |
| pathogen | have you tried clementine yet? | 06:37 |
| hyperair | nope. | 06:37 |
| hyperair | i might give it a go the next time i try kde4 | 06:37 |
| hyperair | which will be when i upgrade to maverick. | 06:37 |
| pathogen | do you not have any qt dependancies installed or something? | 06:37 |
| hyperair | i have. | 06:38 |
| hyperair | but none of the -dev | 06:38 |
| hyperair | and i'm lazy to get those at the moment. | 06:38 |
| pathogen | you don't have to build it | 06:38 |
| pathogen | it's already pre-built | 06:38 |
| pathogen | even in a .deb | 06:38 |
| hyperair | besieds, i have to get to packaging pdfmod, followed by libgpod and then banshee. | 06:38 |
| hyperair | it's more of a time constraints thing | 06:39 |
| pathogen | *facepalm* | 06:39 |
| hyperair | i've got a crapton of things to do, or i'll be spending time trying out compiz++ and posting backtraces | 06:39 |
| pathogen | I thought you really liked banshee? | 06:39 |
| hyperair | yes, i'm banshee's maintainer. | 06:39 |
| pathogen | why wouldn't you have it already XD | 06:40 |
| hyperair | because 1.8.0 hasn't been released? | 06:40 |
| pathogen | ah | 06:40 |
| hyperair | and it's due for release today? | 06:40 |
| hyperair | i think i mentioned this earlier ¬_¬ | 06:40 |
| pathogen | I see | 06:40 |
| hyperair | banshee 1.8.0 will require libgpod from git. | 06:41 |
| pathogen | hmm | 06:41 |
| hyperair | but libgpod is also getting released today | 06:41 |
| pathogen | on git? | 06:41 |
| hyperair | so i'll have to wait for that first | 06:41 |
| hyperair | no, it'll be released, as in 0.7.95 | 06:41 |
| pathogen | oh I see | 06:41 |
| pathogen | So is maintaining banshee something you do as a hobby, or is it your job? | 06:42 |
| pathogen | 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 |
| hyperair | it's a hobby | 06:43 |
| hyperair | and also my starting point towards becoming an ubuntu developer | 06:44 |
| pathogen | So, what does maintaining a project like banshee entail? | 06:45 |
| TheMuso | hyperair: I assume at this point banshee 1.8 is not going into maverick, given main frozen, libgpod in main, etc. | 06:45 |
| hyperair | more like maintaining the package. | 06:45 |
| hyperair | TheMuso: err oh crap, i forgot that. | 06:46 |
| micahg | hyperair: banshee is still in universe | 06:46 |
| pathogen | So you download the releases, compile them for various architectures, and then submit them to the repository? | 06:46 |
| hyperair | micahg: but libgpod needs tobe updated. | 06:46 |
| hyperair | pathogen: no, i download the release, prepare the source package, and upload to ubuntu. it gets built for different architectures there | 06:46 |
| pathogen | Oh, I see | 06:46 |
| pathogen | What usually has to be done to prepare the source? | 06:47 |
| hyperair | TheMuso: could we get a freeze exception for that, i wonder. | 06:47 |
| TheMuso | 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 |
| TheMuso | I could be wrong though. | 06:48 |
| hyperair | =\ | 06:48 |
| RAOF | Another option would be to 0-day SRU it. | 06:48 |
| * hyperair sighs. it's always a rush during finalfreeze | 06:48 | |
| TheMuso | Yeah there is that... | 06:49 |
| pathogen | what is a 0-day SRU? | 06:49 |
| RAOF | An update that's ready to go on release day. | 06:49 |
| pathogen | Oh, I see | 06:49 |
| RAOF | Because respinning/retesting the CDs is a significant effort. | 06:49 |
| hyperair | maybe i could take that path. | 06:50 |
| pathogen | So instead of adding it to the cd, you just make it a zero day update | 06:50 |
| hyperair | Laney, directhex: what do you think? | 06:50 |
| * RAOF wishes mesa also had a “absolute minimum changes after RC” policy. | 06:50 | |
| TheMuso | RAOF: heh | 06:50 |
| ajmitch | RAOF: that takes all the fun out of life | 06:50 |
| RAOF | It was looking so good, too! | 06:50 |
| RAOF | There were just a couple of commits since our very-nearly-RC1 snapshot. | 06:51 |
| TheMuso | RAOF: But is mesa on a timed release schedule? | 06:51 |
| RAOF | It's expected to release on December 4. | 06:51 |
| TheMuso | Right. | 06:52 |
| RAOF | Oh. | 06:52 |
| RAOF | Whoops. | 06:52 |
| RAOF | *October* 4 | 06:52 |
| TheMuso | lol | 06:52 |
| ajmitch | I was going to say... :) | 06:52 |
| pathogen | mesa is a graphics library for X? | 06:52 |
| hyperair | it's where all our 3d drivers are | 06:52 |
| RAOF | And, of course, the best thing to do post RC1 is to pull in the Sandybridge driver. | 06:52 |
| pathogen | I see | 06:53 |
| TheMuso | ahem, lovely. | 06:53 |
| RAOF | Because practically *nobody* has hardware driven by i965_dri.so :( | 06:54 |
| ajmitch | new driver, or major changes to the existing driver? | 06:54 |
| pathogen | I do | 06:54 |
| RAOF | Changes to the existing driver. | 06:54 |
| micahg | o/ as well | 06:54 |
| ajmitch | RAOF: that don't sound very RC-worthy :P | 06:55 |
| hyperair | RAOF: what! i do! | 06:55 |
| pathogen | wow | 06:55 |
| TheMuso | I can't stop laughing about it hear actually, its certainly not RC worthy in my book. | 06:55 |
| pathogen | basically everyone here has that hardware | 06:55 |
| RAOF | micahg, ajmitch: Hush. Everyone knows that intel's GPUs are only aimed at a tiny niche audience : | 06:55 |
| hyperair | those who want battery life? | 06:55 |
| pathogen | I can feel the sarcasm oozing from your text | 06:55 |
| ajmitch | of course, I don't have any current hardware with intel drivers, so they can't be that important :) | 06:56 |
| TheMuso | Afaik sandybridge is not really out in the wild yet. | 06:56 |
| RAOF | Indeed it is not. | 06:56 |
| TheMuso | So it could have waited. | 06:56 |
| ajmitch | but in 6 months time it may be | 06:56 |
| StevenK | Those who only want static images on their screens. :-P | 06:56 |
| pathogen | Beleive it or not, my intel architecture and gpu has lasted very well through the years | 06:56 |
| ajmitch | i915 is a little underpowered for gaming though :) | 06:57 |
| pathogen | 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 | |
| pathogen | at fairly acceptable framerates too :D | 06:57 |
| hyperair | ajmitch: hey i play games with my intel chip. | 06:57 |
| StevenK | pathogen: No fair if you're doing the GL transforms on paper | 06:57 |
| ajmitch | hyperair: nethack doesn't count | 06:57 |
| TheMuso | ROFL | 06:57 |
| pathogen | Portal! | 06:57 |
| TheMuso | to both comments | 06:57 |
| hyperair | ajmitch: lol. i play touhou =p | 06:57 |
| hyperair | 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 |
| hyperair | i have no idea what connection there is between a graphics and ethernet chip, but somehow it succeeds. | 06:58 |
| pathogen | lol | 06:58 |
| hyperair | 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 | |
| hyperair | or of course, a complete shutdown | 06:58 |
| StevenK | ajmitch: Ewwww | 06:58 |
| TheMuso | hyperair: I am surprised even that works. | 06:59 |
| pathogen | using the compiz cube would randomly lock up my desktop 3 years ago | 06:59 |
| hyperair | TheMuso: which one? | 06:59 |
| * StevenK hugs his GeForce, and then treats the burn | 06:59 | |
| ajmitch | StevenK: yeah, it's not exactly easy to figure out why resuming often makes everything dog slow :) | 06:59 |
| TheMuso | Suspending and resuming. | 06:59 |
| RAOF | StevenK: Sizzle! | 06:59 |
| hyperair | 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 | |
| hyperair | if i suspend and resume, then wait, say 15 minutes, i can game for another hour | 06:59 |
| RAOF | The GPU does get fully shut down on suspend then reinitialised on resume, so it's possible. | 07:00 |
| pathogen | Has anyone got a compaq presario cq60 laptop? | 07:00 |
| TheMuso | RAOF: ah ok, makes more sense. | 07:00 |
| RAOF | 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 | |
| hyperair | RAOF: but what about the ethernet chip? | 07:00 |
| pathogen | The laptop always hangs when suspending to the hard drive... | 07:00 |
| RAOF | hyperair: The GPU can scribble on arbitrary memory! | 07:00 |
| hyperair | RAOF: ...oh crap. | 07:01 |
| hyperair | pathogen: that's a feature. | 07:01 |
| RAOF | Doesn't _that_ make you feel safer with WebGL? :) | 07:01 |
| pathogen | hyperair: riiiiiiiight.... | 07:01 |
| hyperair | RAOF: wtf is webgl? D= | 07:02 |
| ajmitch | RAOF: who needs their data anyway? | 07:02 |
| pathogen | webgl is fairly cool | 07:02 |
| ajmitch | hyperair: the ability to play quake in the browser | 07:02 |
| pathogen | it allows a webpage to run script in opengl using your gpu | 07:02 |
| RAOF | hyperair: Pretty much what it says on the box: OpenGL for web clients. | 07:02 |
| hyperair | 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 |
| hyperair | RAOF: heh lol =p | 07:02 |
| pathogen | My old acer sapire could run for days while suspended | 07:03 |
| hyperair | so if the gpu can scribble on arbitrary memory, how come my apps aren't segfaulting? | 07:03 |
| pathogen | I was inpressed | 07:03 |
| hyperair | and only the transmission portion of my tg3 card hangs? | 07:03 |
| hyperair | receiving still works | 07:03 |
| RAOF | 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 | |
| hyperair | =( | 07:04 |
| hyperair | then shouldn't rmmod and modprobe reinitialize the card? | 07:04 |
| RAOF | Not if the state is broken. | 07:05 |
| pathogen | they reinitialize the kernel drivers | 07:05 |
| RAOF | 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 |
| pathogen | but, the problem prolly exists on the hardware level | 07:05 |
| pathogen | in that case, power cycling fixes it | 07:06 |
| hyperair | or suspend/resume =p | 07:06 |
| pathogen | perhaps, perhaps depending on the architecture of the computer | 07:07 |
| hyperair | in my case, graphics works, it's just the ethernet portion that hangs | 07:07 |
| pathogen | pretty strange | 07:07 |
| pathogen | Well, I'm off to bed | 07:07 |
| hyperair | happy sleeping | 07:07 |
| pathogen | I shall! | 07:08 |
| === diwic_afk is now known as diwic | ||
| pitti | Good morning | 07:45 |
| pitti | highvoltage: heh | 07:45 |
| TheMuso | Morning pitti. | 07:47 |
| pitti | hey TheMuso | 07:48 |
| RAOF | Howdie pitti. | 07:56 |
| === 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 | ||
| dholbach | good morning | 08:43 |
| === spike_ is now known as spikeWRK | ||
| poolie | pitti: i'm seeking your further advice on bug 636930 | 09:09 |
| ubottu | 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 |
| poolie | can we kick off an SRU from the 2.2.1 microrelease there? | 09:09 |
| pitti | poolie: we can, yes | 09:09 |
| pitti | 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:09 |
| poolie | that's ok | 09:10 |
| poolie | will it be on hold until after 10/10, or can that happen in parallel with the release? | 09:11 |
| pitti | poolie: it can be uploaded before | 09:12 |
| pitti | poolie: the queue is open, but we won't accept it until very near the release | 09:12 |
| poolie | ok | 09:12 |
| poolie | bit of a shame we didn't hit that, but it's better not to rush | 09:13 |
| poolie | so what do we need to do now to get it into that queue? | 09:13 |
| pitti | poolie: just uploading it, with making sure that the changelog refers to all bugs, etc. | 09:15 |
| pitti | ttx: wrt bug 650893, I suppose you don't have dbus installed on server, right? | 09:19 |
| ubottu | Launchpad bug 650893 in cups (Ubuntu Maverick) "[maverick] cups does not start at boot time" [High,New] https://launchpad.net/bugs/650893 | 09:19 |
| pitti | so I guess I'll again hit the wall of how to specify weak dependencies in "start on" clauses | 09:20 |
| pitti | slangasek: would something like this work for "start after dbus if present"? | 09:22 |
| pitti | ... and (started dbus or runlevel [2345]) and .. | 09:22 |
| === asac_ is now known as asac | ||
| smb | 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 |
| seb128 | bdrung_, hi | 09:25 |
| pitti | ttx: I sent a proposed upstart script to the bug, would be awesome if you could test it | 09:25 |
| seb128 | 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:26 |
| ttx | pitti: I'll reinstall one "print server" now | 09:31 |
| bdrung_ | seb128: because 'discuss' was in the name. where should i have send the mail? | 09:33 |
| === doko_ is now known as doko | ||
| poolie | pitti: i'm not sure if maxb can upload it to proposed(?), could you do it if he can't? | 09:35 |
| seb128 | 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 |
| pitti | poolie: upload permissions aren't pocket specific; so anyone who can upload to devel can upload to proposed as well | 09:36 |
| poolie | ok | 09:38 |
| bdrung_ | seb128: or ubuntu-motu? | 09:38 |
| seb128 | bdrung_, it's likely not everybody is reading the motu list | 09:39 |
| seb128 | bdrung_, I guess busy people only read u-d, not sure if you want feedback from everybody though | 09:39 |
| persia | 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) | 09:40 |
| === almaisan-away is now known as al-maisan | ||
| soren | Wow. Looking at https://edge.launchpad.net/builders makes me feel like uploading something :) | 09:45 |
| pitti | before they get too bored | 09:45 |
| pitti | open natty! open natty! | 09:46 |
| Hobbsee | "is natty open yet?" | 09:46 |
| persia | 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 |
| StevenK | 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 |
| persia | But there's lots of other stuff that needs building. Anyone run `apt-cache -i unmet` recently? | 09:47 |
| persia | 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 |
| pitti | StevenK: oh, I thought it wouldn't even be possible as long as maverick is still open? | 09:48 |
| StevenK | persia: No, I was trying to make a joke that references the releaseparty deley | 09:48 |
| StevenK | *delay | 09:48 |
| persia | StevenK, It was a good joke. Please fix Soyuz so that you can tease us like that. | 09:49 |
| Hobbsee | hah. now you've been told! | 09:49 |
| * StevenK goes back to writing bugs | 09:50 | |
| \sh | persia: and not forgetting the list of FTBFS packages...still in bad shape | 09:51 |
| cjwatson | smb: text or graphical installer? | 09:52 |
| smb | 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:53 |
| cjwatson | smb: I was kind of hoping for a single answer | 09:54 |
| smb | cjwatson, "all" ? | 09:54 |
| === oSoMoN_ is now known as oSoMoN | ||
| ttx | pitti: tested, works, commented on the bug | 09:54 |
| * ttx is about to leave to catch a train | 09:55 | |
| pitti | ttx: yippie | 09:55 |
| * pitti commits | 09:55 | |
| cjwatson | smb: nothing has changed regarding the proxy option in the text installer, as far as I know | 09:55 |
| cjwatson | smb: for the graphical installer, you would have to ask ev | 09:55 |
| ttx | pitti: for post-RC, or do you think we should trigger a respin for that ? | 09:56 |
| ttx | Daviey: about to leave, any question ? | 09:56 |
| pitti | ttx: that's a question for you really, but my gut feeling is that post RC is sufficient, with a release note | 09:56 |
| ttx | pitti: that's my feeling too. | 09:56 |
| smb | 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:56 |
| ev | smb: it's not exposed in the UI anymore. | 09:57 |
| ev | for the graphical installer | 09:57 |
| ttx | if anything else comes up that warrants a respin, then we can catch that one in it | 09:57 |
| smb | ev, Ah ok, so its a grub commandline I could test? | 09:57 |
| ttx | Daviey ^ | 09:57 |
| smb | ttx, sorry | 09:57 |
| cjwatson | can't possibly be a grub command line | 09:57 |
| cjwatson | given that the live CD doesn't boot using grub | 09:57 |
| cjwatson | (yet) | 09:58 |
| ev | I think he means kernel command line preseeding | 09:58 |
| smb | right, just that grub happens the place you enter it most of the time. | 09:58 |
| cjwatson | indeed, I'm just nitpicking :) | 09:58 |
| ev | smb: mirror/http/proxy=true | 09:58 |
| ev | should do it | 09:58 |
| ev | err | 09:59 |
| ev | mirror/http/proxy=whatever.your.proxy.is | 09:59 |
| cjwatson | uh | 09:59 |
| cjwatson | oh, yes, indeed :) | 09:59 |
| ev | clearly not enough coffee in my et | 09:59 |
| ev | yet | 09:59 |
| cjwatson | not that form though | 09:59 |
| cjwatson | mirror/http/proxy=http://whatever.your.proxy.is/ | 09:59 |
| cjwatson | The proxy information should be given in the standard form of | 09:59 |
| cjwatson | "http://[[user][:pass]@]host[:port]/". | 09:59 |
| ev | right-o | 09:59 |
| smb | simple and clear. :-P | 09:59 |
| Daviey | ttx: nope! | 10:00 |
| Daviey | ttx: Have fun :) | 10:00 |
| smb | ev, Do we mention option in the release notes? (asked by the person notoriously forgetting to read them) | 10:02 |
| ttx | Daviey: ok, back in ~4hours | 10:02 |
| ev | smb: yeah, definitely | 10:04 |
| === diwic is now known as diwic_afk | ||
| bdrung_ | dholbach: you are back? | 10:18 |
| dholbach | bdrung_, yes | 10:19 |
| dholbach | bdrung_, got back yesterday afternoon | 10:19 |
| bdrung_ | welcome back dholbach | 10:19 |
| dholbach | thanks bdrung_ | 10:19 |
| corecode | hey | 10:21 |
| corecode | how do i use bzr correctly with the packages? | 10:21 |
| corecode | should i always commit before i build? | 10:21 |
| corecode | because now i have a lot of changes that were caused by debuild | 10:22 |
| cjwatson | if you have a package that applies patches during the build, you can always 'debuild clean' before committing | 10:29 |
| cjwatson | 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:30 |
| tumbleweed | 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:31 |
| cjwatson | that's only bzr bd | 10:33 |
| cjwatson | (and should be filed as a bug on bzr-builddeb, IMO) | 10:33 |
| === diwic_afk is now known as diwic | ||
| tumbleweed | cjwatson: yeah, I need to do that | 10:35 |
| YokoZar | micahg: were you able to do anything with Profile-Guided Firefox this cycle? | 10:58 |
| chrisccoulson | YokoZar, no, but i'm working on that for next cycle | 11:00 |
| YokoZar | chrisccoulson: does firefox build with a .mozconfig yet or is it still a bunch of command switches in the build script? | 11:01 |
| YokoZar | chrisccoulson: sorry for not doing it myself this cycle I know I hinted I would at UDS | 11:01 |
| chrisccoulson | YokoZar, no mozconfig | 11:01 |
| YokoZar | chrisccoulson: That should be the path forward then, as once you use the mozconfig file building with PGO is a switch | 11:02 |
| chrisccoulson | YokoZar, yeah, i know ;) | 11:02 |
| chrisccoulson | 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 | |
| YokoZar | chrisccoulson: Yeah, I got about half way going into UDS-maverick before I got distracted with real life ;) | 11:03 |
| chrisccoulson | well, mozilla are working hard to make PGO work, but it's not straightforward. | 11:03 |
| chrisccoulson | it doesn't work well at all with GCC < 4.5 | 11:03 |
| YokoZar | Fair enough | 11:03 |
| chrisccoulson | so, unless we use that version next cycle, PGO is a non-starter ;) | 11:04 |
| YokoZar | Well we ship GCC 4.5 in maverick, nothing wrong with building Firefox against it ;) | 11:04 |
| chrisccoulson | well, the version we ship will be using the standard toolchain ;) | 11:04 |
| pitti | chrisccoulson: I don't see anything wrong with building with 4.5? | 11:05 |
| chrisccoulson | pitti - oh, well, if that's the case ;) | 11:05 |
| pitti | ... in natty (not proposing to switch now in maverick :) ) | 11:05 |
| chrisccoulson | pitti - anyway, there are some bugs in GCC4.5 which break optimisation in firefox | 11:05 |
| chrisccoulson | eg http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623 | 11:06 |
| ubottu | 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:06 |
| YokoZar | chrisccoulson: you mean fixed in 4.5 yes? | 11:07 |
| chrisccoulson | i don't think it's fixed in the version we have, but i'd need to check | 11:07 |
| chrisccoulson | seeing as it was only fixed a few days ago | 11:07 |
| YokoZar | oh so a newer point release of 4.5 | 11:08 |
| chrisccoulson | i really need another machine to do builds on :( | 11:09 |
| === diwic is now known as diwic_afk | ||
| davmor2 | mvo, pitti: I'm using Hardware Drivers to install the B43 Driver and I got SystemError: installArchives() failed. | 11:24 |
| mvo | davmor2: anything that looks like a error in /var/log/apt/term.log (the last few lines)? | 11:25 |
| davmor2 | pitti: also the STA driver seems to of mysteriously stopped connecting on maverick but lucids does connect correctly :( | 11:25 |
| davmor2 | mvo: all I got is Log started: date time and Log ended: Date time | 11:28 |
| pitti | davmor2: anything in /var/log/jockey.log? | 11:30 |
| pitti | davmor2: I just installed UNE on my mini 10, which auto-installed wl | 11:30 |
| pitti | (which works fine) | 11:30 |
| davmor2 | 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:32 |
| davmor2 | pitti: apport has just woken up and given me an error so I'll send that report | 11:34 |
| davmor2 | pitti: bug 651010 | 11:40 |
| ubottu | 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:40 |
| pitti | davmor2: hm, what an useless dpkg log :( http://launchpadlibrarian.net/56733878/DpkgTerminalLog.txt | 11:41 |
| pitti | davmor2: if you do sudo dpkg --configure -a, what do you see? | 11:41 |
| davmor2 | pitti: Not support low-power chip with PCI id 14e3:4315! that could be the clincher :) | 11:43 |
| pitti | hm, and yet the modalias claims to support it? bad b43 | 11:44 |
| pitti | I seriously consider to just drop the b43 handler for good | 11:44 |
| pitti | it seems to cause nothing but trouble, and STA is generally better | 11:44 |
| davmor2 | 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:47 |
| pitti | probably a quetion for Mathieu | 11:49 |
| pitti | davmor2: but /var/log/daemon.log should already get quite far | 11:49 |
| davmor2 | pitti: thanks :) | 11:49 |
| dpm | 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 |
| pitti | dpm: I already requested the full export; it shoudl be produced today, right? | 11:55 |
| pitti | dpm: I'd like to prepare and test them tomorrow, so that they can build right after RC | 11:55 |
| dpm | pitti, no, the translations deadline is tomorrow | 11:55 |
| pitti | 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:56 |
| dpm | 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 |
| pitti | dpm: "until today" would be better, I think, otherwise we have zero margin for a rebuild | 11:57 |
| pitti | \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:58 |
| pitti | \sh: how does it use a .la file? | 11:59 |
| dpm | 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 |
| pitti | dpm: *nod*; on a Wed or Sun would make sense, to align with the days when the exports actually happen | 11:59 |
| pitti | \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 |
| pitti | top/bottom in the dependency tree, I mea | 12:00 |
| pitti | n | 12:00 |
| * pitti defers to seb128 | 12:01 | |
| \sh | pitti: I'm just trying to fight the ftbfs of ginspector... | 12:01 |
| === diwic_afk is now known as diwic | ||
| dpm | 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 |
| dpm | so that does not have anything to do with the Sunday's export | 12:02 |
| pitti | dpm: oh, I understood that differently | 12:03 |
| pitti | dpm: I thought marking this checkbox means "the next time you create a langapck", not "do an extracurricular export NOW NOW NOW" | 12:04 |
| pitti | 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 |
| pitti | so I guess the export starts very early on Wed/Sun, not late | 12:04 |
| pitti | and the langpacks are then built late in a day, to allow some slack | 12:04 |
| dpm | pitti, let me check with danilo | 12:05 |
| ScottK | 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? | 12:17 |
| === cking is now known as cking-afk | ||
| cjwatson | ScottK: yes | 12:18 |
| ScottK | cjwatson: Thanks. | 12:19 |
| cjwatson | (checked this a few days ago) | 12:19 |
| ScottK | Excellent. | 12:19 |
| === tkamppeter_ is now known as tkamppeter | ||
| === badipod is now known as ldunn | ||
| === MacSlow is now known as MacSlow|lunch | ||
| cjwatson | 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:42 |
| cjwatson | ogra: ^- ditto | 12:43 |
| cjwatson | that failure is apparently in arm-specific assembly code | 12:44 |
| ogra | cjwatson, well, no clue if it runs, feel free to remove it from PAS | 12:47 |
| ogra | then we could actually try :) | 12:47 |
| cjwatson | well, as I say it certainly doesn't build | 12:47 |
| cjwatson | build on powerpc is still going but looking healthier | 12:48 |
| ogra | oh, sorry i misread | 12:48 |
| * ogra is in 10 conversations simultaneously | 12:48 | |
| ogra | then better leave it in PAS until natty :) unless linaro wants to do some last minute debugging here | 12:49 |
| cjwatson | 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:51 |
| * cjwatson grabs a vaguely current ARM ARM to see what the constraints on rndd and friends should be | 12:57 | |
| lool | 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:02 |
| lool | cjwatson: I do care just a bit, but it's not terribly important really | 13:03 |
| lool | I just hate that we have no qemu builds on armel, while Debian builds "qemu" on all arches | 13:03 |
| cjwatson | what would the consequences of removing the arm binaries be? | 13:03 |
| cjwatson | it might not be that hard to fix this code .. | 13:03 |
| lool | cjwatson: Pretty much no consequence I would think | 13:03 |
| cjwatson | I guess I'm worried about lurking build-deps and the like | 13:04 |
| lool | I really can't think of any, but I didn't grep | 13:04 |
| lool | In the future, kvm will be used on armel, but that's still far off | 13:04 |
| seb128 | does anybody know what translation file has the ubiquity string "retrieving files n of n (<time> remaining)" | 13:04 |
| seb128 | ? | 13:04 |
| cjwatson | there are several deps/build-deps | 13:04 |
| cjwatson | even on armel | 13:05 |
| cjwatson | they might not work - I guess I'm reluctant to make those uninstallable at this point | 13:05 |
| cjwatson | seb128: apt | 13:06 |
| seb128 | cjwatson, thanks | 13:06 |
| cjwatson | msgid "Retrieving file %li of %li (%s remaining)" | 13:06 |
| cjwatson | msgstr "Téléchargement du fichier %li sur %li (%s restant)" | 13:06 |
| seb128 | hum | 13:06 |
| seb128 | I'm wondering why the RC image doesn't have those in french | 13:06 |
| cjwatson | if you're not seeing it translated, I don't know why ... | 13:06 |
| seb128 | well the french langpacks are not on the iso | 13:07 |
| cjwatson | locale not copied to target at the point when it's running or something? | 13:07 |
| cjwatson | langpack shouldn't matter | 13:07 |
| cjwatson | apt is excluded from langpacks since it's needed before they're installed | 13:07 |
| lool | cjwatson: I poked the rdepends of qemu, kvm, and qemu-kvm, and I see nothing critical for armel in there; most of the time, the packages are used on x86 desktops | 13:07 |
| lool | hmm grub build-deps on qemu | 13:07 |
| cjwatson | lool: right, but since my aim is archive consistency I'm a bit scared of something that would make things worse in some sense | 13:07 |
| cjwatson | grub doesn't build on armel | 13:08 |
| cjwatson | well, I'll look into this constraints error and see if it's easy to fix | 13:08 |
| cjwatson | if it is then I'll just fix it | 13:08 |
| cjwatson | if it isn't, I'll drop the binaries | 13:08 |
| lool | cjwatson: I tihkn I remember this | 13:09 |
| lool | cjwatson: It's very old code | 13:09 |
| lool | cjwatson: I think this is for an older FPU than VFP | 13:09 |
| cjwatson | it's particularly odd since I don't see the code in upstream git | 13:09 |
| lool | cjwatson: I definitely remember patching out this code in the past already | 13:09 |
| cjwatson | assuming I'm using the right git repository since there are millions of the things | 13:10 |
| cjwatson | "rndd" is not mentioned in the current ARM ARM | 13:10 |
| dpm | seb128, this seems to have been fixed in bug 644736 (see the strings in the duplicate). Perhaps the translations have not yet been exported from LP? | 13:10 |
| ubottu | Launchpad bug 644736 in Ubuntu Translations "Untranslatable messages in the installer (dup-of: 646109)" [Medium,Triaged] https://launchpad.net/bugs/644736 | 13:10 |
| ubottu | Launchpad bug 646109 in Ubuntu Translations "Translations not loaded for some messages during installation in Ubiquity" [Medium,Triaged] https://launchpad.net/bugs/646109 | 13:10 |
| lool | shit, the fact that the fpu is called maverick doesn't help google it | 13:10 |
| Riddell | dholbach: steven kelly moved his slot from friday to tomorrow in https://wiki.kubuntu.org/UbuntuAppDeveloperWeek | 13:10 |
| dholbach | akgraner, ^ | 13:11 |
| lool | cjwatson: But if you just patch out the arm specific code, that part will definitely build with the C implementation | 13:11 |
| cjwatson | qemu-kvm builds fine on powerpc, so we can deal with that at least | 13:11 |
| dholbach | thanks Riddell | 13:11 |
| cjwatson | lool: ok, I'll give it a try, thanks | 13:11 |
| akgraner | dholbach, Riddell I'll make that change - thanks for the heads up :-) | 13:11 |
| seb128 | dpm, I doubt those translations are new they should be in the current export | 13:12 |
| cjwatson | lool: would anyone be able to test that it's not completely broken if I did this? | 13:12 |
| seb128 | dpm, apt didn't get an upload for a week | 13:12 |
| seb128 | dpm, did you notice the same issue in spanish? | 13:13 |
| bilalakhtar | dholbach: Welcome back! | 13:13 |
| jibel | dpm, seb128, I'm testing a wubi upgrade from 10.04.1 and the problem also exists during installation of 10.04.1 | 13:13 |
| dpm | seb128, I use Catalan, but yes, I noticed it too :). If they come from apt, could it be that they need to be exported and put in the package? | 13:14 |
| dpm | during install translations are not in language packs | 13:14 |
| seb128 | dpm, cf what cjwatson said before, apt is not in langpacks because it's used before those are installed | 13:15 |
| seb128 | in fact apt-all.mo is in langpacks | 13:15 |
| seb128 | but the string is translated in the mo according to msgunfmt | 13:15 |
| dpm | seb128, does the string come perhaps from somewhere else? libapt-pkg or such? | 13:16 |
| seb128 | dpm, it's in apt-all.mo on the disk and translated | 13:16 |
| cjwatson | the whole apt source package is supposed to be blacklisted from langpack stripping | 13:17 |
| cjwatson | I think it's more likely that the locale isn't set up properly ... | 13:18 |
| cjwatson | (could be wrong, it would just be my first hypothesis) | 13:18 |
| fta | pitti, what makes apport create a crash file or not? i just had milter-greylist crashing in all my ubuntu boxes at the same time, but no crash file in any of them :( | 13:19 |
| seb128 | dpm, I guess it's worth reopening that ubiquity bug or opening a new one | 13:19 |
| seb128 | cjwatson, thanks | 13:19 |
| lool | cjwatson: qemu-kvm 0.12.3-0ubuntu2: | 13:22 |
| lool | * New patch, arm-host-fix-compiler-warning, drops __arm__ specific code | 13:22 |
| lool | which was probably FPA specific (certainly not ARM/VFP) and was dropped | 13:22 |
| lool | upstream in bc4347b883e8175dadef77ed9e02ccaa5e8eba94; helps build on | 13:22 |
| lool | armel. | 13:22 |
| YokoZar | Anyone with main upload rights feel like sponsoring a pretty trivial change? | 13:34 |
| YokoZar | https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/351429 | 13:35 |
| ubottu | Launchpad bug 351429 in file-roller (Ubuntu) "file-roller associates itself with windows executables that it can't handle" [Low,Triaged] | 13:35 |
| dpm | seb128, ok, I've unduplicated bug 644736 and added a comment. | 13:35 |
| ubottu | Launchpad bug 644736 in Ubuntu Translations "Untranslatable messages in the installer" [Medium,Triaged] https://launchpad.net/bugs/644736 | 13:35 |
| seb128 | dpm, thanks | 13:35 |
| dpm | np | 13:35 |
| cjwatson | lool: aha! thanks, will resurrect | 13:36 |
| cjwatson | just waiting for the testbuild | 13:36 |
| hyperair | is it possible to ship in a new upstream release of libgpod at this point? | 13:38 |
| hyperair | seb128: ^ | 13:38 |
| seb128 | not really | 13:39 |
| seb128 | depends of the change I guess, if that's a one liner fix for a blocker issue | 13:39 |
| hyperair | unfortunately it's a lot more than a one-liner | 13:39 |
| seb128 | otherwise better to SRU it | 13:39 |
| hyperair | http://paste.debian.net/92350/ | 13:39 |
| seb128 | no way for that diffstat | 13:39 |
| seb128 | it will be a SRU in best case for this cycle | 13:40 |
| hyperair | okay. | 13:40 |
| hyperair | has ubuntu-sru opened up for SRU applications yet? | 13:40 |
| seb128 | usually uploads work already yes | 13:41 |
| seb128 | but nothing stop you to do the update and the bug work, add the debdiff etc | 13:41 |
| seb128 | then try to upload and if that doesn't work just keep the update to upload later | 13:41 |
| hyperair | oh okay | 13:41 |
| lool | cjwatson: I was expecting to find the problematic code in qemu-kvm.git, at least in the 0.12 branch, but I did not; not sure why really | 13:41 |
| hyperair | seb128: don't SRUs need to be already fixed in ubuntu+1, though? | 13:42 |
| seb128 | hyperair, no | 13:43 |
| hyperair | okay then. | 13:43 |
| * hyperair remembers reading something of taht sort in a wiki page | 13:43 | |
| seb128 | when the version are the same the sru is pocket copied | 13:43 |
| hyperair | ah okay. | 13:43 |
| seb128 | well sometime it help to have testing on the unstable version | 13:43 |
| seb128 | but you should rather make sure it lands in the next unstable as well | 13:43 |
| hyperair | right. | 13:43 |
| seb128 | in practice when the version didn't change yet we pocket copy the sru to it | 13:43 |
| seb128 | it's less work for everybody | 13:44 |
| hyperair | okay. | 13:44 |
| dpm | pitti, re: when the full export happens you were right - ticking the box in LP marks them to be exported on the next scheduled day | 13:54 |
| dpm | I've updated the exports schedule to include info on when the language pack builds happen: | 13:54 |
| dpm | https://dev.launchpad.net/Translations/LanguagePackSchedule | 13:54 |
| === MacSlow|lunch is now known as MacSlow | ||
| pitti | dpm: nice, thank you | 13:55 |
| dpm | np :) | 13:55 |
| dpm | pitti, Considering that RCs are on Thursdays (the other milestones I guess are not that critical for language packs), I think the schedule is ok -> language pack exports on Tuesdays (and ready on Wed) | 13:55 |
| dpm | I think the only thing that we should consider next cycle is to move the LanguagePackDeadline 2 days before to match the exports schedule. | 13:55 |
| dpm | What do you think? | 13:55 |
| pitti | dpm: so I'm currently considering using today's export (0929) for the final langpacks | 13:56 |
| pitti | next Sunday gets pretty tight | 13:56 |
| pitti | if they will work well, we have enough time, but if they fail, we are screwed | 13:57 |
| dpm | pitti, yeah, that's fine. I understand that there is no other way for this cycle | 13:57 |
| dpm | I'll let translators know. | 13:57 |
| pitti | dpm: as usual we can do a first SRU a few weeks after release, whenever it's suitable | 13:58 |
| dpm | pitti, sure, that sounds good, my question is also what you think about moving the LanguagePackDeadline day in future releases to an earlier date ^ | 13:58 |
| pitti | dpm: I agree; Tuesday before the RC sounds appropriate | 13:59 |
| dpm | ok thanks pitti | 13:59 |
| pitti | thanks dpm! | 13:59 |
| pitti | dpm: I'll start the langpack builds now | 14:01 |
| Riddell | pitti: why can't an export be done tomorrow? | 14:02 |
| pitti | Riddell: because the Great Gods of Launchpad's third commandment says "Maverick language packs are creates on Tuesdays and Saturdays" | 14:02 |
| pitti | Riddell: well, it can probably be done, but with some extra manual effort | 14:03 |
| pitti | s/creates/created/ | 14:03 |
| Riddell | well seems the extra effort, launchpad are ment to do what we need them to do after all | 14:03 |
| pitti | Riddell: we can locally build the Saturday export and use it if they work, but I'd like to have today's export as a fallback at least | 14:04 |
| Riddell | as it is the translations I imported today because I was following the schedule won't get in and that'll annoy upstream lots | 14:04 |
| pitti | dpm: do you know if/how it's possible to schedule an exra run? | 14:05 |
| Riddell | akgraner: are there any edited logs for app developer week? | 14:05 |
| JFo | asac, mind taking a look at https://bugs.launchpad.net/bugs/649357 ? | 14:09 |
| ubottu | Launchpad bug 649357 in network-manager (Ubuntu) "network-manager on une will not connect" [Undecided,New] | 14:09 |
| dpm | pitti, it's a cron job in LP, so I can ask the LP devs to ask LOSAs to schedule a one-off run I guess. Let me ask danilo. I'll be back in a few mins | 14:11 |
| dpm | Riddell, ^ | 14:11 |
| asac | JFo: not time this week. talk to cyphermox or ask seb128 who is looking into those this cycle | 14:12 |
| dpm | pitti, Riddell, if that were possible, when should this next one-off export be started? | 14:12 |
| pitti | dpm: from my POV, tonight would be good | 14:12 |
| Riddell | dpm: whenever you told the translators the deadline was | 14:13 |
| cyphermox | JFo, already noticed it this morning; I was hoping to get my hands on a similar system to test it (I definitely didn't see this on my netbook) | 14:13 |
| pitti | that was today, no? | 14:13 |
| Riddell | dpm: but mostly after the .pos I uploaded are imported :) | 14:13 |
| cyphermox | asac, ^^ | 14:13 |
| asac | cyphermox: what chipset? | 14:16 |
| JFo | cyphermox, cool | 14:20 |
| JFo | :) | 14:20 |
| === zyga is now known as zyga-cold | ||
| cjwatson | lool: qemu> apparently applied upstream as bc4347b883e8175dadef77ed9e02ccaa5e8eba94. no idea why it's not in our package. | 14:25 |
| cyphermox | asac: may be specific to Broadcom, or even STA :/ | 14:25 |
| cjwatson | (test-build still running but looks a lot better) | 14:25 |
| cyphermox | asac, mine is an aspire one ZG5, so atheros, iirc. | 14:26 |
| persia | cjwatson, Dunno about armel, but I have an interest in KVM/powerpc (and have added a few patches here and there for it), so I'd rather it wasn't P-a-s'd | 14:27 |
| cjwatson | persia: right, I'll definitely be un-P-a-s-ing it on powerpc at least | 14:29 |
| persia | Thanks. Still a little shaky in maverick, but I'm fairly confident we'll have everything but the bootloader working in natty (still need to find a way around not being able to build arch:all packages on powerpc) | 14:30 |
| cjwatson | you could use grub2 | 14:31 |
| cjwatson | it probably needs minor fixes but we'd welcome them | 14:32 |
| persia | heh. I'll take a look. If that's easier than convincing Soyuz to build openfirmware, it may be the way to go. | 14:32 |
| cjwatson | I have heard that it works on Debian, modulo some glitches with prefix (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597538) | 14:33 |
| ubottu | Debian bug 597538 in grub-ieee1275 "grub-ieee1275: grub-install needs to pass a --prefix option to grub-mkimage" [Important,Open] | 14:33 |
| cjwatson | and grub-installer would need to be taught about it | 14:34 |
| slangasek | pitti: why would you OR the dbus with 'runlevel'? dbus is not guaranteed to be started before entering the runlevel, it races in parallel | 14:34 |
| cjwatson | but those are relatively superficial things | 14:34 |
| persia | That's very promising. I'll definitely take a deeper look at that, rather than fussing with openfirmware (especially since dropping sparc means there is only one package left that would need the Soyuz hack) | 14:35 |
| asac | cyphermox: ok... bc is still painful i guess :/ | 14:35 |
| lool | cjwatson: It's simply not fixed in the stable-0.12 branch; only in qemu-kvm master | 14:36 |
| pitti | slangasek: I understood that "runlevel 2345" is started later in the game, so to push it out a little bit | 14:36 |
| cjwatson | persia: why was openfirmware needed anyway? I don't remember that being needed for yaboot | 14:36 |
| cjwatson | persia: which powerpc subarch are we talking about here? | 14:36 |
| cjwatson | lool: ah, ok | 14:37 |
| lool | (I was looking at the wrong file when I checked stable-0.12 earlier; I checked softfloat.c instead of softfloat-native.c) | 14:37 |
| slangasek | pitti: a) it's racy, b) you've or'ed it so the only effect it could have is to start your job sooner rather than later...? | 14:37 |
| pitti | slangasek: but I'm open to other suggestions; just the smbd story has taught me that weak dependencies aren't really working with current upstart methods | 14:37 |
| lool | cjwatson: Were you able to build with that bugfix alone? | 14:37 |
| lool | s/bugfix/patch | 14:37 |
| cjwatson | lool: I'll tell you when kakadu finishes with it ... | 14:37 |
| cjwatson | it's certainly got well past that failure | 14:37 |
| pitti | slangasek: the effect is to start it at all on servers | 14:37 |
| lool | Poor kakadu | 14:37 |
| pitti | slangasek: since we don't have dbus on servers | 14:38 |
| dpm | Riddell, pitti. I've just spoken to danilo. A one-off full langpack export can be arranged, we just have to decide on the date, which should probably be today or tomorrow. I'd be up for tomorrow, as that was the date on the maverick schedule, but you guys know best if that would be too tight or not. Riddell, as per checking whether the files you uploaded have been imported, you can do it here: https://translations.edge.launchpad.net/~jr/+imports?field.f | 14:38 |
| dpm | ilter_status=all&field.filter_extension=po - they don't seem to have been yet. So what date should I tell danilo to start the export? | 14:38 |
| cjwatson | persia: (oh, wait, is openfirmware not a package name? I mean I know it's what the firmware implementation is called, but I don't know quite which particular Soyuz hack you mean ...) | 14:38 |
| slangasek | pitti: er, if it starts fine w/o dbus, why 'start on dbus' at all then? | 14:38 |
| pitti | slangasek: well, it starts without dbus, but then jobs aren't broadcast | 14:38 |
| slangasek | hmm | 14:39 |
| pitti | slangasek: i. e. if dbus is installed, I want cups to start after it | 14:39 |
| cjwatson | so do the same thing as with samba? | 14:39 |
| pitti | so the "or runlevel" was the best hack I could come up with | 14:39 |
| cjwatson | SIGHUP dbus, or whatever makes it deal | 14:39 |
| pitti | cjwatson: that would mean to sighup cups when dbus starts | 14:39 |
| slangasek | pitti: it's not a very reliable hack | 14:39 |
| pitti | slangasek: I know | 14:39 |
| cjwatson | ok, the other way round. isn't that fine too? | 14:39 |
| cjwatson | conditional start is not something you can do in upstart | 14:40 |
| cjwatson | all the available hacks, as far as I know, make things worse | 14:40 |
| cjwatson | sending signals doesn't generally make things worse, if it's supported | 14:40 |
| pitti | but at least not worse than in lucid | 14:40 |
| pitti | init.d scripts were also started on runlevel [2345] in essence | 14:40 |
| cjwatson | if we're changing it in maverick then IMO we should do it right | 14:40 |
| cjwatson | we're just storing up future really really confusing bugs for ourselves otherwise | 14:41 |
| pitti | cjwatson: right, but so far I don't know what "right" is | 14:41 |
| persia | cjwatson, last I looked, we had OF implementations for both PPC and Sparc, but they have to be built on their target architectures, and the binaries are arch:all (for use with qemu), so... | 14:41 |
| pitti | we need a weak dependency like "should-start:" or "on starting" (which doesn't work for practical scenarios) | 14:41 |
| cjwatson | persia: oh, I thought you were still talking about the boot loader | 14:41 |
| cjwatson | pitti: what's wrong with notifying cups when dbus starts? | 14:42 |
| persia | Soyuz hack would be to add some way to hint to Soyuz that a certain source needs to be built on a certain arch, and still allow it to produce arch:all binaries. | 14:42 |
| cjwatson | persia: right, I just wasn't sure of the particular package name. now I know that you're talking about qemu not about the boot loader, it makes more sense | 14:42 |
| pitti | cjwatson: telling dbus about all services that can support dbus and should be restarted doesn't sound like the "right" solution to me | 14:42 |
| persia | OF *is* a bootloader (among other things). As you indicate, switching to grub2 would make everything easier. | 14:42 |
| pitti | that's just backwards | 14:42 |
| cjwatson | grub2 on powerpc needs open firmware | 14:43 |
| persia | cjwatson, I'm talking about a bootloader to use with qemu :) | 14:43 |
| cjwatson | pitti: well, you *don't have* weak dependencies | 14:43 |
| persia | Oh :( | 14:43 |
| cjwatson | looking for them is going to make things worse | 14:43 |
| persia | So for KVM, I still need a first-stage bootloader (as grub2 will only handle second stage). Well, might be natty. might be natty+1. Anyway, the binaries from Debian work. | 14:43 |
| persia | Current source packages seem to be "openbios-sparc" and "openbios-ppc" ("openhackware" was an old one, as well as some using "openfirmware" in their names) | 14:44 |
| cjwatson | I'd still like to switch to grub2 for actual powerpc installations | 14:44 |
| cjwatson | but not having a working powerpc right now makes it hard to drive that | 14:44 |
| YokoZar | cjwatson: new icoutils uploaded (in queue atm) | 14:45 |
| cjwatson | ok, thanks | 14:45 |
| persia | cjwatson, Would you find yourself more productive with a working powerpc? | 14:46 |
| pitti | cjwatson: we can certainly formulate the conditions in a strong dependency, but then we need an additional state property "service foo exists" | 14:47 |
| cjwatson | pitti: this is all a next-version-of-upstart thing | 14:47 |
| pitti | cjwatson: oh, good to hear | 14:47 |
| cjwatson | but right now, you don't have it | 14:47 |
| pitti | so, "dbus or runlevel" should be what we had in lucid | 14:47 |
| cjwatson | persia: differently productive. I would probably get less of the work I'm supposed to do done ... | 14:47 |
| pitti | and we hacked around the problem with cups and smbd, so for maverick it should be okay | 14:48 |
| persia | cjwatson, heh. OK. I'll keep that in mind :) | 14:48 |
| cjwatson | mvo: is bug 650525 happening due to the RT ticket you filed? | 15:02 |
| ubottu | Launchpad bug 650525 in ubuntu-extras-keyring (Ubuntu) "Failed to fetch http://extras.ubuntu.com/ubuntu/dists/maverick/Release ; missing key" [Undecided,New] https://launchpad.net/bugs/650525 | 15:02 |
| cjwatson | mvo: I thought we shipped the key text so that we didn't have to rely on fetching the key from the network, though, so not quite getting it | 15:03 |
| mvo | cjwatson: the RT is for the software-center, this one is different, let me look | 15:03 |
| YokoZar | mvo: btw, now that software center does its initial apt-get update on first open, the number of incidences of valid apt:// links not working due to "package not found" should reduce (though still possible if someone clicks an apturl link before opening software center or running update manager on a fresh install) | 15:05 |
| mvo | YokoZar: yep | 15:06 |
| YokoZar | mvo: I have a suspicion gnome-codec-install might be affected similarly (I think it breaks when no apt-get update was yet run) | 15:06 |
| YokoZar | hopefully someone runs software center before they poke around their movie files or look up howtos ;) | 15:07 |
| YokoZar | part of me wonders if it would be reasonable to ship a (even slightly out of date) universe packages list on the install | 15:08 |
| mvo | YokoZar: there is a open bug about it iirc, but the additional disk space on the live cd has been a problem | 15:10 |
| mvo | YokoZar: the first apt-get update cron job will heal it | 15:10 |
| mvo | YokoZar: in the case of gnome-codec-install I vaguely remember there was code that detects misisng universe and offers to update, but I may mis remember | 15:11 |
| persia | Isn't there some stuff that gnome-codec-install requests that isn't suitable for being on images? | 15:11 |
| YokoZar | mvo: missing universe is different from never having run update (I think that code is way back when universe was unticked by default) | 15:11 |
| YokoZar | persia: err yeah I guess multiverse package list too | 15:11 |
| YokoZar | persia: but a package list is different from a package ;) | 15:12 |
| persia | Ah, true. Although I still have reservations about multiverse :) | 15:12 |
| mvo | YokoZar: right, I just tested and its clever enough to notice that there is stuff in sources.list but the data in /var/lib/apt/liss is not there | 15:16 |
| mvo | YokoZar: I vaguely remember I added that code at some point | 15:16 |
| YokoZar | ahh | 15:16 |
| YokoZar | so maybe it's just apt-url that's the problem then | 15:16 |
| mvo | yeah | 15:17 |
| mvo | very possible | 15:17 |
| james_w | jibel: very useful, thanks | 15:44 |
| james_w | jibel: I now have a much better idea of where the problem is, but no idea for a fix yet | 15:44 |
| jibel | james_w, you're welcome. If you had an idea for the fix but no idea where the problem is, that would be a problem. | 15:45 |
| jibel | :) | 15:45 |
| james_w | jibel: well, that's what I was trying before :-) | 15:46 |
| jibel | james_w, don't hesitate if you need to try something else. | 15:47 |
| micahg | YokoZar: no, but it's scheduled for next cycle | 15:47 |
| dpm | [15:38] <dpm> Riddell, pitti. I've just spoken to danilo. A one-off full langpack export can be arranged, we just have to decide on the date, which should probably be today or tomorrow. I'd be up for tomorrow, as that was the date on the maverick schedule, but you guys know best if that would be too tight or not. Riddell, as per checking whether the files you uploaded have been imported, you can do it here: https://translations.edge.launchpad.net/~jr/+i | 15:51 |
| dpm | mports?field.f | 15:51 |
| dpm | ilter_status=all&field.filter_extension=po - they don't seem to have been yet. So what date should I tell danilo to start the export? | 15:51 |
| dpm | Riddell, pitti, in case you haven't seen the question earlier on: if you could look at the question whenever you've got time, I can then ask Danilo to schedule the export ^^ | 15:51 |
| dpm | thanks! | 15:51 |
| pitti | dpm: whenever the KDE translations are finished, I guess | 15:52 |
| dpm | pitti, but in case they take really long to import and we cannot wait for them to finish, what would be the latest date for the full export request and to make sure there is room for a rebuild if there are any issues with the langpacks. Tomorrow? | 15:56 |
| pitti | dpm: tomorrow evening, I think | 15:57 |
| pitti | the buildds will be crammed with "OMGrightafterRC" builds, put the langpacks on top of that, and we'll have a large enough backlog already | 15:58 |
| dpm | pitti, ok thanks. I'll watch the KDE translations and make the request for tomorrow evening the latest if they are not imported yet - Riddell it would really help me if you could tell me which translations you uploaded, or if you could keep an eye on them yourself as well | 16:00 |
| === doko_ is now known as doko | ||
| Riddell | dpm: I uploaded the ones I e-mailed you about last night | 16:25 |
| ogra | grrr upstart | 16:26 |
| Guest23154 | hi all im probably in the wrong channel but i guessed someone in here would be bale to tell me whats needed to build 32 efls for linux on a 64 bit ubuntu. thanks | 16:32 |
| cjwatson | mvo: the timestamp on /etc/apt/trusted.gpg is the time when ubuntu-keyring was installed (11:01) rather than the time when ubuntu-extras-keyring was installed (11:11) | 16:32 |
| cjwatson | suggests that the ubuntu-extras-keyring package isn't doing what it claims to do | 16:33 |
| cjwatson | no obvious reason why it shouldn't, though, from looking at apt-key | 16:35 |
| james_w | jibel: http://paste.ubuntu.com/502692/ is my latest guess, I've just pushed it to my PPA. If you could test that would be great | 16:36 |
| jibel | james_w, this test machine is currently ... testing isos. I'll be able to try that this evening or tomorrow morning. | 16:38 |
| james_w | jibel: ok, thanks | 16:38 |
| james_w | if anyone else sees the bug where the policykit password dialog loses the textbox and then hangs, I would appreciate your feedback | 16:39 |
| james_w | bug 649939 has the details | 16:39 |
| ubottu | Launchpad bug 649939 in software-center (Ubuntu) "authentication popup does nothing when installating new software" [High,Confirmed] https://launchpad.net/bugs/649939 | 16:39 |
| mvo | cjwatson: indeed, what is odd is that the "OK" comes from apt-key, I will see if I can run the build livefs image script and reproduce it wit hthat | 16:40 |
| cjwatson | mvo: I'm trying that now | 16:41 |
| cjwatson | I have a local mirror so it shouldn't take forever | 16:42 |
| cjwatson | mvo: (I'm shoving 'set -x' into apt-key after debootstrap) | 16:48 |
| mvo | excellent, that should solve the puzzle | 16:50 |
| === RoAkSoAx is now known as andreserl | ||
| === andreserl is now known as RoAkSoAx | ||
| === JanC_ is now known as JanC | ||
| === deryck is now known as deryck[lunch] | ||
| === ivoks-afk is now known as ivoks | ||
| jjardon | Hello, is there any possiblity to ship pygobject 2.26 in maverick? It's the only supported python bindings supported upstream | 17:57 |
| jjardon | PyGTK apps are recommended to switch to PyGObject | 18:00 |
| SpamapS | should iso's from 20100928 still say "development branch" in the issue/motd/etc ? | 18:20 |
| persia | SpamapS, Most certainly. | 18:22 |
| SpamapS | just verifying that while doing iso testing. | 18:22 |
| persia | That usually changes just before the final candidates, when the name is removed, and the number added. | 18:23 |
| === deryck[lunch] is now known as deryck | ||
| doko | bdrung_: ping | 19:00 |
| bdrung_ | doko: pong | 19:01 |
| doko | a lot of the audacious plugins fail to build | 19:01 |
| doko | hmm, no all that I did give back | 19:02 |
| doko | audacious-dumb g15daemon-audacious imms upse xmp | 19:03 |
| bdrung_ | not again... | 19:03 |
| bdrung_ | i start disliking audacious... | 19:04 |
| === al-maisan is now known as almaisan-away | ||
| doko | bdrung_: all but one is missing/moved header file | 19:05 |
| kees | barry: can I pick your brain (or other python superstars) on a quick "how to I make this shorter?" puzzle: http://paste.ubuntu.com/502757/ | 19:06 |
| kees | if it we C I'd use an inline conditional | 19:07 |
| kees | *were | 19:07 |
| === amitk is now known as amitk-afk | ||
| kklimonda | kees: http://paste.ubuntu.com/502763/ - you save over 20 characters! ;) | 19:15 |
| kklimonda | almost 30.. ;) | 19:15 |
| kees | oh, I didn't know you could do a conditional like that. nice! | 19:16 |
| mterry | jcastro, is there some wiki documentation on how to run a good ubuntu-classroom session? Like how to use ClassBot, how to get Lernid to see a session's slides(?), that sort of thing. | 19:57 |
| mterry | jcastro, ah, just found it. Classroom on the wiki | 19:58 |
| jcastro | yep | 19:58 |
| jcastro | I find that reading logs of other people's sessions are useful | 19:58 |
| jcastro | https://wiki.ubuntu.com/UbuntuOpenWeek <-- top right there are years of session logs | 19:59 |
| uni4dfx | can someone patch the Radiance theme? there's a very simple mistake in metacity-theme-1.xml | 20:02 |
| === rgreening_ is now known as rgreening | ||
| uni4dfx | anyone? it's a 1-character mistake | 20:07 |
| mterry | uni4dfx, file a bug? "ubuntu-bug light-themes" | 20:10 |
| uni4dfx | mterry you know nothing is going to happen if i file a bug | 20:11 |
| uni4dfx | they're gonna dump the theme before they get to it | 20:11 |
| uni4dfx | and it's 3 seconds of work to fix it | 20:11 |
| uni4dfx | even if i submit a patch, they won't even look at it | 20:12 |
| mterry | uni4dfx, that's a depressing attitude. :) Bugs are how ubuntu developers track and fix things, even trivial ones. Doesn't mean it will get fixed faster, but it helps it get fixed at all | 20:12 |
| micahg | uni4dfx: we have a patch review team now that tries to get to the patches | 20:12 |
| uni4dfx | So if I submit a patch can it be applied before Maverick is out? | 20:13 |
| mterry | uni4dfx, it's pretty tight schedule wise. depends on how severe the bug is. If it doesn't make it, it can be released as an update | 20:13 |
| uni4dfx | mterry it's a bug that can be fixed by changing 1 character in an xml file | 20:14 |
| mterry | uni4dfx, right, but that doesn't mean it's a severe bug. Like a bug that crashes everyone's desktop will probably be squeezed in, but a bug that just means the wrong color of purple was used somewhere will probably just be released as an update | 20:15 |
| micahg | the why examples are appropriate now as well: https://wiki.ubuntu.com/StableReleaseUpdates#Why | 20:16 |
| uni4dfx | well that's like saying we're going to spend 6 months fixing 2 bugs and screw the rest that actually have patches committed | 20:17 |
| doko | siretart: ping | 20:17 |
| siretart | doko: hi | 20:18 |
| doko | siretart: https://edge.launchpad.net/ubuntu/+source/odin/1.8.1-2build1/+build/1921597 | 20:18 |
| doko | is ffmpeg/altivec built with -fPIC? | 20:19 |
| doko | I love builds which don't show compiler flags ... | 20:19 |
| mterry | uni4dfx, my advice is still to file a bug with the patch | 20:20 |
| siretart | does powerpc accept shared library builds without -fPIC at all? | 20:20 |
| uni4dfx | mterry on it | 20:21 |
| siretart | oh, yeah, I see what you mean | 20:22 |
| siretart | doko: I'm pretty sure that it is, and I need to switch off this obfuscation for natty, right | 20:22 |
| doko | siretart: how do you turn it on? VERBOSE=1 doesn't work too well | 20:41 |
| === dwatson is now known as davewatson | ||
| siretart | V=1 | 20:57 |
| === davewatson is now known as dwatson | ||
| === sebner__ is now known as sebner | ||
| lex79 | slangasek: can you look at this bug 262679 please? it's there since jaunty | 21:20 |
| ubottu | Launchpad bug 262679 in EasyPeasy Overview "eeepc-acpi-scripts is not installable" [Low,Confirmed] https://launchpad.net/bugs/262679 | 21:21 |
| lex79 | basically eeepc-acpi-scripts depends on acpi-support-base which is not in archive | 21:21 |
| pnt | anyone running 10.04 that can help me confirm a bug in scanf? | 21:22 |
| persia | pnt, We typically coordinate that sort of thing on #ubuntu-bugs | 21:22 |
| pnt | thanks | 21:22 |
| * ogra_ac found the right kernel tree for the ac100 to build modules \o/ | 21:24 | |
| ogra_ac | and its still usable even with running make -j2 in the background | 21:25 |
| izzytemp | Where is the information stored in the panel. When it becomes customized, where do the customizations go? | 21:27 |
| izzytemp | I put some stuff there and I would like to be able to transfer it to other machines | 21:28 |
| slangasek | lex79: frankly, that package needs a lot more help to be properly integrated in Ubuntu than just fixing a dependency | 21:30 |
| lex79 | slangasek: but that package shouldn't be in archive imho | 21:31 |
| lex79 | for now I mean | 21:31 |
| slangasek | well, we can remove it and blacklist it from being synced from Debian, sure | 21:31 |
| lex79 | it just make confusion on users | 21:31 |
| slangasek | lex79: subscribed ubuntu-archive to bug #328989; I don't have time to process it just this moment | 21:33 |
| ubottu | Launchpad bug 328989 in eeepc-acpi-scripts (Ubuntu) "eeepc-acpi-scripts package should be removed" [Undecided,New] https://launchpad.net/bugs/328989 | 21:33 |
| lex79 | slangasek: ok | 21:33 |
| yofel | pitti: can you merge https://code.edge.launchpad.net/~yofel/apport/lp-590521/+merge/37069 ? typo fix | 22:27 |
| ogra_ac | does anyone else have a weird experience going to people.c.c ? | 22:47 |
| ogra_ac | i get an advertisement | 22:48 |
| ogra_ac | This domain may be for sale. Buy this Domain | 22:48 |
| * ajmitch doesn't | 22:48 | |
| ogra_ac | http://people.canoncial.com/~ogra/ | 22:48 |
| ogra_ac | lol | 22:48 |
| ajmitch | heh | 22:48 |
| ajmitch | nice typo? :) | 22:48 |
| ogra_ac | i should learn to type | 22:48 |
| asac | bug 642792 feels really nasty. anyone knows if there was an explicit decision made this cycle to change that? | 22:53 |
| ubottu | Launchpad bug 642792 in metacity (Ubuntu) "ALT+PrtSc not recognised" [Undecided,Confirmed] https://launchpad.net/bugs/642792 | 22:53 |
| === yofel_ is now known as yofel | ||
| persia | asac, That's an extra-hard one: it's about contention between kernel and GNOME. | 22:58 |
| asac | well | 22:59 |
| asac | persia: what i want to understand where the change resulting in this regression was decided ;) | 22:59 |
| asac | and ensure that that discussion involved all the right parties | 22:59 |
| persia | I don't believe there was such an explicit decision. | 23:00 |
| asac | then it needs to be changed back | 23:00 |
| asac | or fixed | 23:00 |
| asac | ;) | 23:00 |
| asac | alt-print cannot be changed without an explicit decision imo ... at least not from the kernel side | 23:01 |
| persia | asac, So, which bit needs to be "changed back"? the kernel, or GNOME? | 23:07 |
| asac | persia: i assume the kernel changed this cycle | 23:08 |
| asac | gnome didnt change | 23:08 |
| asac | whatever changed this cycle needs to be changed back ;) ... at least the default setting of gnome was not touched | 23:08 |
| ogra_ac | asac, just use your digital camera | 23:15 |
| asac | lol | 23:16 |
| hallyn | cjwatson: kirkland suggested i should be talking to you... i've got two cases where lucid will do the right thing with external disks, and maverick won't (last tested last weekend). the first, using cryptsetup, i opened a bug for a long time ago | 23:17 |
| asac | ogra_ac: actually i tried changing it to something else in keybindings preference and now i cannot change it back because its not recognized as any key-combo at all; in short: i am all set :-P | 23:17 |
| hallyn | cjwatson: the other, is an iomega drive, not encrypted, 1 partition, which automounts under lucid, but (same laptop) in maverick fdisk -l says something about bogus sectors | 23:17 |
| hallyn | cjwatson: alas the drives and laptop are at home, and i'm out for the week, so i can't give details right now | 23:17 |
| asac | ogra_ac: so according to that bug if you disable sysrq the key combo is recognized as "Alt-SysRq" rather than "Alt-Print" in gnome | 23:18 |
| ogra_ac | wow | 23:19 |
| asac | ogra_ac: what do you think changed that would cause this? | 23:19 |
| persia | Depends on the keyboard, really. | 23:19 |
| asac | kernel? gtk? keymaps? | 23:19 |
| ogra_ac | kernely or keymaps i'd say | 23:19 |
| asac | persia: does it work for you? ;) | 23:19 |
| persia | asac, "work" how? | 23:19 |
| asac | persia: press alt+print ... and see if you get a screenshot of current window | 23:20 |
| persia | The answer is "sometimes". | 23:20 |
| asac | are you running maverick? | 23:20 |
| persia | Depends whether I use my German or Japanese keyboard (both are connected) | 23:20 |
| persia | Yep. | 23:20 |
| asac | so its german keyboard only? | 23:20 |
| persia | German keyboard works. Japanese keyboard works only if I press Alt+SysRq twice in a row quickly enough | 23:21 |
| hallyn | jjohansen: kees: cjwatson: btw, bug #622762 was the one i originally openedd for the first issue | 23:21 |
| ubottu | Launchpad bug 622762 in cryptsetup "encrypted partition works in lucid, not maverick" [Undecided,New] https://launchpad.net/bugs/622762 | 23:21 |
| asac | hmm. my german keyboard does not work | 23:21 |
| persia | (where "works" means I get the screenshot popup) | 23:21 |
| asac | persia: and a screenshot of window rather than full root window? | 23:21 |
| asac | ogra_ac: does it work for you? | 23:21 |
| persia | asac, I don't think it's the layout of the keyboards, but rather how they encode SysRq. the Japanese keyboard is Logitech and the German keyboard is Cherry | 23:22 |
| ogra_ac | asac, i cant find the print key | 23:22 |
| asac | omg :-P | 23:22 |
| asac | ogra_ac: its often somewhere at the top ;) | 23:23 |
| ogra_ac | i know :P | 23:23 |
| ogra_ac | this thing has an android adjusted kbd | 23:23 |
| persia | asac, Strangely, when I tried to reproduce, I ended up with a stuck ALT key until reseting *both* keyboards simultaneously (plug events) | 23:24 |
| * persia concludes Alt*SysRq behaviour is determinisitic in far too complicated a manner | 23:25 | |
| ogra_ac | asac, i dont use an ubuntu kernel, but nothing happens if i hit alt+print | 23:25 |
| ogra_ac | (german keymap though) | 23:25 |
| ogra_ac | print alone gets me a desktop shot | 23:25 |
| asac | interesting | 23:26 |
| asac | does not really help us much ;) | 23:27 |
| * asac out | 23:30 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!