| aliendude3500 | cjwatson, Thanks for the help! It works flawlessly! :) | 00:06 |
|---|---|---|
| crimsun | slangasek: do I need a UserInterfaceFreeze exception for the pulseaudio task in bug 533877? The effect is an addition of the correct "Connector" in gnome-volume-control's Input tab. | 00:09 |
| ubottu | Launchpad bug 533877 in alsa-utils "[SigmaTel STAC9228] Recording problem - integrated microphone no longer available on Dell XPS 1330" [Low,Fix released] https://launchpad.net/bugs/533877 | 00:09 |
| crimsun | ^^ anyone else on the release team | 00:10 |
| crimsun | (err, am I supposed to be asking in -release?) | 00:10 |
| Riddell | tjaalton, bryceh: any X dudes about? | 00:10 |
| cjwatson | aliendude3500: good, happy to help | 00:11 |
| bryceh | Riddell, mm? | 00:20 |
| Riddell | bryceh: has the intel version string changed recently? | 00:21 |
| Riddell | I mean the format | 00:21 |
| Riddell | bryceh: kwin expects something like "20061017" but it seems to be "2009" "Q" "4" | 00:22 |
| bryceh | Riddell, it quite possibly could have | 00:34 |
| bryceh | Riddell, they have adopted a quarterly release process and it seems quite likely they'd change the nomenclature to suit | 00:34 |
| bryceh | Riddell, probably worth making kwin's regex support either style | 00:35 |
| xnox | thanks to everyone involved in UDD, bzr and lp! I've just did bzr merge-package and it did the right thing without generating a single conflict! | 00:35 |
| cjwatson | nice, isn't it :) | 00:36 |
| xnox | cjwatson: It's awesome. Thank you ;-) | 00:36 |
| cjwatson | not I, really | 00:36 |
| xnox | cjwatson: btw - there are no bzr-nightly builds for lucid | 00:38 |
| cjwatson | I wouldn't know about that | 00:39 |
| xnox | I can update cookbook branch (or do a merge proposal) but do i need to poke james westby about that? | 00:39 |
| cjwatson | check whoever seems to be uploading the others, or runs the team, or whatever ... | 00:39 |
| xnox | Yeah it's james =) | 00:39 |
| * xnox is stuck in stone age without bzr nightly builds for lucid ;-) | 00:40 | |
| slangasek | crimsun: I don't think that needs a UI freeze exception | 00:46 |
| === jono_ is now known as jono | ||
| bdrung | cjwatson: what's the status of bug #513197? | 01:14 |
| ubottu | Launchpad bug 513197 in ntfs-3g "Please merge ntfs-3g 1:2010.1.16-0.1 (main) from Debian testing (main)" [Wishlist,Triaged] https://launchpad.net/bugs/513197 | 01:14 |
| cjwatson | I intend to apply for a feature freeze exception for it, but have not got round to it yet. no other statuss | 01:14 |
| cjwatson | *status | 01:14 |
| cjwatson | ArneGoetje: gbrainy.mo is in both base and gnome langpacks, breaking DVD builds. Where's a good place to report this sort of thing, that isn't specific to a single package? | 01:29 |
| ArneGoetje | cjwatson: those exceptions are handled individually in langpack-o-matic | 01:36 |
| ArneGoetje | cjwatson: so, I take it that it should be only present in the gnome langpacks? | 01:39 |
| cjwatson | ArneGoetje: I don't know; I just know it shouldn't be in both :-) | 01:42 |
| ArneGoetje | cjwatson: ok, I'll check | 01:42 |
| cjwatson | err, it's part of what used to be gnome-games isn't it? | 01:42 |
| cjwatson | and it's in ubuntu-desktop and not kubuntu-desktop | 01:42 |
| cjwatson | so yes, I think that would make it gnome langpacks | 01:42 |
| ArneGoetje | cjwatson: ok | 01:43 |
| ArneGoetje | cjwatson: I will add an override to langpack-o-matic. | 01:44 |
| cjwatson | great, thank you | 01:45 |
| cjwatson | will there be another langpack upload before beta-1? | 01:45 |
| slangasek | I think it's important that we have buildable DVDs for beta-1 | 01:46 |
| cjwatson | agreed, I was wondering whether new langpacks were planned anyway, or would need to be added | 01:46 |
| ArneGoetje | cjwatson: current situation is that in the -base langpacks (full-export), gbrainy.po is in the base package. In one of the delta updates it seems to have switched over to the gnome langpacks. So, what I can do now is to manually delete it from the gnome langpack updates and re-upload them. | 01:47 |
| ArneGoetje | cjwatson: next full-export is scheduled for Saturday night (UTC), so new langpacks will be available on MOnday | 01:48 |
| ArneGoetje | cjwatson: and with the next langpacks gbrainy.po should be in the gnome langpacks only. | 01:50 |
| cjwatson | that sounds workable | 01:50 |
| cjwatson | as long as we get the delta fixes before Saturday, since we'll need to iterate some more on DVD builds and need as much lead time as we can get | 01:50 |
| ArneGoetje | cjwatson: yes, I will do it right away | 01:50 |
| cjwatson | they've been failing since January on and off, so we can't expect them to be particularly sound :( | 01:50 |
| === yofel_ is now known as yofel | ||
| cjwatson | (not your fault, this is the first time I've seen this particular error) | 01:51 |
| cjwatson | great, thank you | 01:51 |
| ArneGoetje | cjwatson: :) | 01:51 |
| maco2 | Any archive admins around? https://edge.launchpad.net/ubuntu/+source/spim/8.0-0ubuntu1 should be in universe, not multiverse | 01:56 |
| maco2 | (license changed this release; it's now 3-clause BSD) | 01:56 |
| ArneGoetje | cjwatson: ok, so gbrainy will be without translation updates for this short period, but will get them back on Monday. | 02:04 |
| maco2 | cjwatson: can i borrow you a moment? | 02:07 |
| slangasek | maco2: is there a bug report open for this? There's no interface that lets us comment on component changes, so a bug report is our best bet for figuring out why it moved if there are questions later | 02:11 |
| maco2 | slangasek: i can go file one | 02:12 |
| slangasek | appreciated :) | 02:12 |
| maco2 | slangasek: sure, now there's bug 537063 | 02:14 |
| ubottu | Launchpad bug 537063 in spim "spim 8.0 should be moved from multiverse to universe" [Undecided,New] https://launchpad.net/bugs/537063 | 02:14 |
| ArneGoetje | cjwatson: gaa, doesn't work this way... need to run the complete delta update again, otherwise it will mess up the packages... should not take that long... | 02:15 |
| slangasek | maco2: and promoted | 02:17 |
| maco2 | slangasek: thanks | 02:18 |
| === cjohnston_ is now known as cjohnston | ||
| micahg | ArneGoetje: I wanted to ask you about bug 534417 | 02:32 |
| ubottu | Launchpad bug 534417 in thunderbird "Thunderbird: localization not installed automatically" [Undecided,Confirmed] https://launchpad.net/bugs/534417 | 02:32 |
| ArneGoetje | micahg: right, need to move that bug to software-center. That function is already implemented in language-selector and software-center just needs to call a function to get this. I will add a comment and move it over later, when I'm done with the language-packs | 02:35 |
| micahg | ArneGoetje: great...I also wanted to ask you about the template for the firefox langpacks | 02:36 |
| micahg | do you want to switch from firefox-3.6 to firefox after beta 1? | 02:36 |
| ArneGoetje | micahg: template has been fixed | 02:36 |
| micahg | ArneGoetje: it's firefox now? | 02:36 |
| ArneGoetje | micahg: oh, that... no, we can only switch when 3.0 and 3.5 are out of life and firefox has been upgraded to 3.6 for all releases. | 02:37 |
| micahg | ArneGoetje: oh, I thought it was going to be sooner...ok, I'll talk to asac about the translation menu link in ubufox then | 02:38 |
| ArneGoetje | micahg: ok, thanks | 02:38 |
| leagris | Hello, anyone interested in kernel BUG at /build/buildd/linux-2.6.31/fs/btrfs/inode.c:735 ? | 03:00 |
| persia | leagris: I suspect a number of folk are. I'd recommend running `ubuntu-bug linux` to gather up a lot of the information about the bug and your system, and then report with as much additional detail as you can to the bug tracker. | 03:12 |
| leagris | persia, here is a extract from dmesg: http://pastebin.ca/1832949 | 03:14 |
| persia | leagris: Thanks, but I'm not someone who can understand the problem from that. Please do file a bug. IRC is a poor place for bug reports, because lots of folk sleep. | 03:16 |
| persia | (well, other reasons too, but that's a big one) | 03:16 |
| leagris | :) | 03:18 |
| leagris | thanks persia | 03:18 |
| ccheney | for some reason i can no longer ssh to my systems foo.local address, anyone know what could cause that? | 04:04 |
| ccheney | hmm it works after resetting the ethernet connection | 04:05 |
| emgent` | aloha jono | 04:35 |
| jono | hey emgent` | 04:37 |
| nonix4 | How can I use the *-dbg* packages with gdb? | 05:53 |
| persia | nonix4: Install the -dbg package. Start gdb. If you have to do something special, file a bug. | 05:54 |
| * nonix4 ponders (a bit offtopicly) which alternate browser to use since the buggy app in this case is firefox in infinite loop and gdb says "no debugging symbols found" | 05:59 | |
| micahg | nonix4: what's wrong with firefox? | 06:05 |
| nonix4 | It got to infinite loop switching mouse cursor between pointer and hand. Thoughts on how to analyze situation better? gdb backtrace doesn't tell much to untrained eyes with missing symbols | 06:06 |
| micahg | nonix4: what were you hovering over? | 06:08 |
| nonix4 | Not sure anymore... one of {a login input, submit button, help href, another tab}. But regarding the -dbg packages I was apparently just missing some of them (guess there're no dependancies between them) | 06:12 |
| nonix4b | oh great, X froze on attach to firefox... | 06:16 |
| * nonix4b makes a mental note of debugging X apps requiring remote connection for the control | 06:17 | |
| micahg | nonix4b: well, if you get enough info feel free to file a bug and I'll try to get to it at some point | 06:18 |
| micahg | pitti: could you please check on the lucid retracer (bug 533357 has been waiting 4 days) -- thanks | 06:22 |
| ubottu | Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/533357) | 06:22 |
| * nonix4b considers filing a bug on debug symbols of gdb itself missing | 06:43 | |
| pitti | Good morning | 06:45 |
| RAOF | pitti: Good morning. | 06:45 |
| nonix4 | 'k "kill -CONT $ff; kill -9 $gdb" got X back alive, so may actually be able to get some information out of it :) | 06:56 |
| pitti | ev: oh, nice! usb-creator has completed 140% :) | 07:17 |
| emgent | Riddell, ping. | 07:38 |
| emgent | morning pitti | 07:38 |
| emgent | apachelogger, ping too | 07:38 |
| dholbach | good morning | 07:47 |
| amitk | morning dholbach | 07:49 |
| emgent | hey dholbach ! how goes? | 07:50 |
| emgent | long time to saw you | 07:50 |
| dholbach | hey amitk, hi emgent | 07:50 |
| dholbach | how are you guys doing? | 07:50 |
| emgent | really busy with my job :-\ | 07:51 |
| emgent | and anyway i have a not good news for us.. | 07:51 |
| lifeless | ? | 07:51 |
| emgent | lifeless, ola, are you in involved in canonical webapps ? | 07:52 |
| lifeless | somewhat | 07:52 |
| lifeless | why? | 07:52 |
| emgent | i have some security hole to notify. | 07:53 |
| lifeless | so do so | 07:53 |
| lifeless | we use launchpad, it has support for that | 07:53 |
| emgent | are not ubuntu stuff bug.. are canonical webapps issue | 07:54 |
| emgent | but if you prefer.. i will notify in LP. | 07:54 |
| emgent | dholbach, when back query me | 07:55 |
| dholbach | I'm all here | 07:55 |
| spaetz | would opening a kernel bug with patch to support the Marvel 8431 (which is in newer netbooks) be appropriate? | 07:56 |
| persia | spaetz: You could, but I think they kernel team likes git-formatted patches to their mailing list (although I may be mistaken). | 07:58 |
| persia | spaetz: You ought get guidance in a bug if you file it though. | 07:59 |
| dholbach | spaetz: https://wiki.ubuntu.com/KernelTeam/KernelPatches | 07:59 |
| dholbach | spaetz: having the patch in a bug is good, but the kernel team prefers discussion on their mailing list | 08:00 |
| alkisg | I'm trying to use pam_ck_connector to make local LTSP sessions CK-aware, but I don't understand how I'm supposed to export the CKCON_X11_DISPLAY_DEVICE environment variable (i.e. export doesn't work). It does work if I put it in /etc/environment, but I want it to have different values per session, so I don't want it in a global file. Would someone care to give me some hint? | 08:00 |
| dholbach | https://wiki.ubuntu.com/MeetingLogs/devweek1001/KernelPatches has some good discussion about it too | 08:00 |
| spaetz | persia, dholbach thanks. I can point to the corresponding git commit for the opensuse kernel, hope that is fine. I will send a mail to the mailing list. | 08:01 |
| dholbach | awesome | 08:02 |
| lifeless | emgent: we have products in lp for many/most of our webapps | 08:09 |
| lifeless | emgent: which ones are affected? you can privmsg if you want | 08:09 |
| spaetz | dholbach: filed bug 537168. Thanks for your pointers. | 08:15 |
| ubottu | Launchpad bug 537168 in linux "[lucid] add support for Marvel 0x8431 (88E8059)" [Undecided,New] https://launchpad.net/bugs/537168 | 08:15 |
| dholbach | no worries :) | 08:15 |
| dugger5688 | Anyone got some tips on where to get started in bug fixing? I want to get into developing for ubuntu, but for obvious reasons don't want to dice into the deep end trying to start my own project. | 08:35 |
| dugger5688 | dive* | 08:37 |
| slangasek | bigon: gupnp-igd FTBFS in lucid because of a problem with the test suite, which I assume was enabled as an MIR requirement; there's a fix upstream for getting the test suite to *build*, but enabling 'make check' in debian/rules still causes the package to FTBFS even with version 0.1.6-1 - do you have any ideas on this? (bug #534311) | 08:37 |
| ubottu | Launchpad bug 534311 in gupnp-igd "gupnp-igd ftbfs on all archs in lucid" [Critical,Triaged] https://launchpad.net/bugs/534311 | 08:37 |
| dholbach | dugger5688: try https://wiki.ubuntu.com/MOTU/GettingStarted | 08:38 |
| slangasek | bigon: it looks like it might need dbus running for the testsuite | 08:38 |
| dugger5688 | Thanks, found my way there already :-) Will go through it in the morning. | 08:39 |
| bigon | slangasek: well there is the same bug in debian | 08:46 |
| slangasek | bigon: in Debian the testsuite isn't enabled - do you mean this is why it's not enabled? | 08:47 |
| bigon | wait I check | 08:47 |
| sabdfl | Keybuk: purple consoles, +1 ftw | 08:48 |
| bigon | slangasek: it could be related to nm support (and the fact that dbus-glib is not working properly when initialised inside a thread, dixit gupnp-igd upstream | 08:49 |
| bigon | slangasek: I'm planning to make a gupnp-igd without nm support in debian to fix a related FTBFS | 08:50 |
| directhex | seb128, moonlight 2.2 uploaded. good luck to whomever needs to clear that through NEW. | 08:51 |
| seb128 | directhex, thanks! | 08:51 |
| directhex | 1.0.1-3ubuntu0.xul191build2 to 2.2-0ubuntu1 (36.1 MiB) | 08:52 |
| slangasek | bigon: ok - if you decide to fix it in Ubuntu as well, please note that I've merged up to 0.1.3-4 (testing) already on the lp:ubuntu/gupnp-igd branch, so if we continue with 0.1.3+fixes, would be good to preserve that | 08:52 |
| cjwatson | maco2: did slangasek cover what you wanted, or was there something different you wanted to ask me about? | 08:53 |
| bigon | slangasek: do you have logs of gupnp-igd 0.1.6 FBTFS? | 08:55 |
| slangasek | bigon: posted to the bug | 08:56 |
| bigon | slangasek: oh it's not a crash (I thought so) well then It could be http://bugzilla.openedhand.com/show_bug.cgi?id=1979 then | 09:01 |
| ubottu | bugzilla.openedhand.com bug 1979 in gupnp "g_warning make gupnp-igd test fails" [Normal,New] | 09:01 |
| slangasek | bigon: ah, looks right, yes | 09:02 |
| Mikerhinos | hi | 09:03 |
| alkisg | Does /etc/security/pam_env.conf have access to the normal environment variables, or it can only access pam-environment? E.g. I'm trying to put MYVAR DEFAULT=${LANG} there, but it doesn't work for me... | 09:06 |
| spaetz | cjwatson: thanks for fixing ubiquity so fast. Glad I could help with my logs | 09:08 |
| pitti | apw: do you think there's a chance to fix bug 397734 for lucid? it still causes a lot of grief, and OEM team also has trouble | 09:09 |
| ubottu | Launchpad bug 397734 in devicekit-disks "can't eject cdrom with hardware button" [Medium,Fix released] https://launchpad.net/bugs/397734 | 09:09 |
| pitti | apw: (it's basically flipping the default value of /proc/sys/dev/cdrom/lock to 0) | 09:09 |
| pitti | apw: we could set it in /etc/sysctl.d somewhere, but first that's racy (doesn't get active if the cdrom module isn't loaded yet), and also means extra parsing during boot, etc. | 09:10 |
| pitti | apw: hm, I guess it could be a modprobe.d file, but it'd still feel cleaner to set the default right at the source | 09:11 |
| apw | pitti, i'll have a look | 09:12 |
| pitti | apw: thanks | 09:12 |
| seb128 | siretart`, hello | 09:15 |
| siretart` | hi seb128! how are you? | 09:15 |
| seb128 | siretart`, good, you? | 09:15 |
| seb128 | siretart`, I'm starting that gst-ffmpeg against ffmpeg discussion with pitti again | 09:15 |
| pitti | hey siretart`, wie gehts? | 09:15 |
| siretart` | thanks, fine. | 09:15 |
| siretart` | danke! :-) | 09:15 |
| seb128 | since he was not around the other day | 09:15 |
| seb128 | siretart`, can you summarize the issue between both? | 09:15 |
| seb128 | does gst-ffmpeg need a newer or older ffmpeg to work correctly? | 09:16 |
| siretart` | ah, another round in the gst-ffmpeg vs ffmpeg deathmatch :-) - okay, let the fun begin | 09:16 |
| seb128 | is downgrading or upgrading ffmpeg to that version an option? | 09:16 |
| pitti | siretart`: background is, ffmpeg is pretty prone to security flaws (and bugs, too, I suppose), so if we can avoid a copy, we should | 09:17 |
| siretart` | okay, short recap: ffmpeg 0.5 is now pretty exactly 12 months old, and has since then gained quite a lot of additional codecs | 09:17 |
| siretart` | gst-ffmpeg upstream has decided that these additional codecs are important for them and switched from tracking the 0.5 release branch (which we use as system ffmpeg) to ffmpeg trunk | 09:18 |
| pitti | seb128: 0.5+svn was in karmic as well, so I guess that had the same problem? | 09:18 |
| siretart` | naturally, some details have changed, and gst-ffmpeg has strongly advised me against compiling it against 0.5 | 09:18 |
| seb128 | pitti, ok, seems I got my version wrong, better to read what siretart` is writting | 09:18 |
| siretart` | slomo however has identified which parts don't work against 0.5, and patched them out | 09:18 |
| pitti | siretart`: ah, so the issue is that gst-ffmpeg has a _newer_ copy than our system ffmpeg? | 09:18 |
| siretart` | pitti: exactly. gst-ffmpeg will track the 0.6 branch as soon as it opens (maybe we'll create that branch this weekend, maybe next weekend, we'll see) | 09:19 |
| siretart` | pitti: regarding security issues, does the security team really care about the security patches in the ffmpeg package? I did write a mail to security, but they were rejected because "no testcase" | 09:20 |
| siretart` | in the mean time the patches I did for the debian package got integrated in 0.5.1 | 09:20 |
| pitti | hm, I had assumed they did; kees, jdstrand, mdeslaur ^ ? | 09:20 |
| siretart` | and are now in lucid. but for karmic the patches are still missing | 09:20 |
| seb128 | siretart`, should we understand from that using the system 0.5 ffmpeg will mean cutting or features and codecs which would work using the copy then? | 09:20 |
| pitti | siretart`: ah, so is there actually a problem in lucid then? | 09:20 |
| seb128 | or->on | 09:21 |
| kees | I really care about security patches. :P | 09:21 |
| kees | I'm not sure I understand the question, though. | 09:21 |
| siretart` | pitti: 0.5.1-1ubuntu is in lucid and has these patches. all sec related patches I'm aware of are included there | 09:21 |
| seb128 | kees, the question is "do you care if gst-ffmpeg uses a ffmpeg copy" ;-) | 09:21 |
| pitti | siretart`: I meant, you said that slomo patched out the bits of gst-ffmpeg which don't work with our 0.5.1 ffmpeg lib | 09:22 |
| siretart` | seb128: yes, trunk always has (almost per definition) more codecs then a release branch | 09:22 |
| pitti | siretart`: so it seems that in lucid it's actually fine? | 09:22 |
| kees | `I did write a mail to security, but they were rejected because "no testcase"` ? surely not security@ubuntu.com ? | 09:22 |
| siretart` | pitti: lucid should be fine | 09:22 |
| kees | seb128: yes, I care -- it absolutely should not use an embedded copy. | 09:22 |
| pitti | siretart`: *phew* great to hear | 09:22 |
| siretart` | kees: I'll fetch the message id | 09:22 |
| seb128 | siretart`, if lucid should be fine I'm getting confused about your ping from the other day | 09:22 |
| siretart` | seb128: security wise. gst-ffmpeg in lucid is compiled against 0.5, which upstream strongly opposes | 09:23 |
| seb128 | why, if it works fine? | 09:23 |
| seb128 | I had the impression you told me it was open door for crasher issues | 09:23 |
| seb128 | but now you say it's fine | 09:23 |
| siretart` | pitti: kees: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550442#35 this is the last message I got from the ubuntu security team, I think | 09:24 |
| ubottu | Debian bug 550442 in ffmpeg "ffmpeg: deluge of crashes due to missing input sanitization" [Serious,Fixed] | 09:24 |
| siretart` | I understood the last sentence as "we need an proof-of-concept exploit" for each crash | 09:24 |
| siretart` | which I really don't have the time for | 09:25 |
| pitti | that would be weird | 09:25 |
| pitti | most security issues we fix don't have one, AFAIK? | 09:25 |
| kees | siretart`: he meant "someone needs to analyze these crashes to see if they're really security issues." | 09:25 |
| siretart` | seb128: yes, and that is right. we are having two seperate discussions here | 09:25 |
| persia | I'd hope that we weren't writing test cases for every security hole. That code would be dangerous. | 09:26 |
| kees | persia: we do try -- how else to better validate a vulnerability has been fixed? | 09:26 |
| siretart` | kees: I've discussed each single patch with other ffmpeg developers, and I think only one or two were classified as 'not security relevant' | 09:26 |
| persia | Oh my! | 09:26 |
| lifeless | persia: kees has bee doing this for years :) | 09:27 |
| lifeless | s/ee/een/ | 09:27 |
| kees | persia: have you not see lp:~ubuntu-bugcontrol/qa-regression-testing/master ? | 09:27 |
| persia | kees: I've not looked in detail, no. | 09:27 |
| * persia wonders how the publication of that branch intersects with UEC images | 09:28 | |
| siretart` | seb128: I'm saying that *ffmpeg* itself should be fine security wise. I didn't say that about gst-ffmpeg! | 09:28 |
| seb128 | siretart`, I've to admit I'm confused about the discussion now | 09:28 |
| seb128 | siretart`, I though the discussion was about having something which is stable against something not tested and crashy | 09:29 |
| kees | siretart`: if there are open security issues in ffmpeg in releases of ubuntu, we need to track them. mdeslaur seemed to be identifying where various things were fixed already? this list needs to be clarified, etc. | 09:29 |
| seb128 | siretart`, and now it turns to be a discussion about ffmpeg security which I've no real clue about or interest in | 09:29 |
| siretart` | kees: pitti: anyway, in the mean time a DSA has been released about these issues, so the patches could be taken straigt from there. however, looking at the latest commits svn://ffmpeg.org/branches/0.5 might be helpful as well | 09:29 |
| seb128 | siretart`, so I will let you guys sort that one | 09:29 |
| siretart` | seb128: okay, let's discuss open security issues first and then return to gst-ffmpeg | 09:30 |
| seb128 | siretart`, thanks | 09:30 |
| siretart` | kees: I haven't heared anything back from mdeslaur since then, no idea if he continued to track that issue | 09:31 |
| kees | siretart`: okay, I'd like to get it clarified. specific what patches are missing for which ubuntu releases of ffmpeg. | 09:32 |
| siretart` | kees: for intrepid, I think taking the patches from the debian DSA would probably be easiest, although I didn't check if I haven't missed to backport some patched back then. I think there might be even some newer patches to check | 09:34 |
| kees | siretart`: can you perhaps open a new LP bug (tracking this in a debian bug probably isn't the clearest way to handle this)? | 09:35 |
| siretart` | kees: for jaunty and karmic (they are effectivly both 0.5), replaying the patches from the 0.5 release branch should be easiest | 09:35 |
| siretart` | okay, I can do that | 09:35 |
| siretart` | shall we return to the issue of gst-ffmpeg then? | 09:36 |
| kees | siretart`: cool thanks. when mdeslaur wakes up, he can poke at it more. I'm overdue for sleep. :) g'night! | 09:37 |
| ev | pitti: :) | 09:37 |
| pitti | siretart`: so now I'm confused; I thought it would work well in lucid now, with slomo's patches? | 09:37 |
| siretart` | kees: good night! :-) | 09:37 |
| pitti | kees: sleep well! | 09:37 |
| siretart` | pitti: well, it is the 'well' that upstream objects. They highly doubt that it works 'well' | 09:37 |
| siretart` | it builds, but nobody really tested that combination | 09:38 |
| siretart` | and I have to admit that I'm not going to look to deeply into crashers that come via that way | 09:38 |
| pitti | siretart`: if you feel too unsure about it, perhaps we could downgrade to an earlier gst-ffmpeg from a time when 0.5.1 was current? | 09:38 |
| siretart` | pitti: yes, sticking to the version of gst-ffmpeg from karmic seems to me a safe solution | 09:39 |
| pitti | siretart`: so we should go back from 0.10.10 to 0.10.9? | 09:39 |
| seb128 | or use the gst-ffmpeg copy? | 09:40 |
| seb128 | I don't fancy using year old code | 09:40 |
| seb128 | especially for multimedia, it often means lack of support for codecs, etc | 09:40 |
| pitti | well, we should either upgrade ffmpeg to trunk or downgrade gst-ffmpeg | 09:41 |
| siretart` | pitti: that would make us stick to a codebase that we know, but it also would make seb128 and many users sad because we're missing lots of codecs | 09:41 |
| pitti | having two copies of ffmpeg really doesn't make sense, either from security or maintenance POV | 09:41 |
| pitti | if we keep a newer ffmpeg in gst-ffmpeg, then we'd still have those codec/bugs problems in the system library | 09:41 |
| seb128 | pitti, it would make sense in the sense it would provide a decent multimedia experience to our user | 09:42 |
| pitti | seb128: how wouldn't that be provided by updating the system library? | 09:42 |
| siretart` | pitti: as for long term plans, I plan to work on the 0.6 release soon, and bilboed (gst-ffmpeg upstream) has indicated that they will start tracking that branch as soon as it opens | 09:42 |
| apw | pitti, this CDROM lock thing ... i just played with mine and i am unsure as to what the real issue here is... as far as i can tell the button works when you are allowed to eject the CD and not when you are not (its in use) ... are we saying we want to allow eject even on mounted FSs? | 09:42 |
| seb128 | pitti, you are trading distro work against user experience, ie arguing that we care about having less work and not about providing a good user experience there | 09:42 |
| pitti | seb128: but if it's not ready for release yet, then that's just bad luck and timing | 09:42 |
| siretart` | pitti: I didn't push 0.6 for lucid because I cannot commit to transition all package in ubuntu from 0.5 to 0.6. I have really no idea how much breakage that will cause | 09:43 |
| pitti | so | 09:43 |
| siretart` | for me, the plan was to go with 0.5 for both lucid and squeeze | 09:43 |
| seb128 | pitti, by experience upgrading system ffmpeg is not trivial | 09:43 |
| pitti | we are saying that ffmpeg 0.5 is stable, and 0.6 is not there yet | 09:43 |
| apw | pitti, also having just tried it, when you rip out the disk the fs remains mounted from there on ... and nautilus (i think) triggers 5 errors to syslog every few seconds until its reinserted or unmounted | 09:43 |
| seb128 | pitti, right | 09:43 |
| siretart` | bilboed was fully aware of that plan but decided to go for trunk anyways | 09:43 |
| pitti | apw: that's a separate bug indeed | 09:43 |
| siretart` | and I can udnerstand him in some ways. there are really very interesting new features in 0.6 | 09:44 |
| pitti | seb128: so either 0.6 is ready for release, then we can update to it, or it's not, then I don't see a major reason why we shouldn't stay with 0.5? | 09:44 |
| apw | pitti, i also can't see what would stop eject working in the middle of a disk burn ... | 09:44 |
| siretart` | but since we are way past feature freeze, I did considered upgrading as an option | 09:44 |
| pitti | seb128: do you really think 0.5 was so bad? video codecs have worked great in linux for at least a decade, after all | 09:44 |
| siretart` | upgrading gst-ffmpeg to use ffmpeg 0.6 would require a FFe anyway AFAIUI.. | 09:45 |
| pitti | seb128: do we have lots of bug reports which would be fixed with 0.6? | 09:45 |
| siretart` | pitti: well, we could also see it that way: | 09:45 |
| seb128 | pitti, I don't know enough about ffmpeg to say | 09:45 |
| siretart` | pitti: for lucid+1, I will very soon upload a ffmpeg 0.6 package as system ffmpeg | 09:46 |
| seb128 | pitti, I just know that a year is lot in multimedia things | 09:46 |
| pitti | seb128: but you just argued that we need 0.6 for good user experience? | 09:46 |
| seb128 | pitti, and sirestart said slomo had to turn codecs and things off since they didn't work with ffmpeg 0.5 | 09:46 |
| siretart` | pitti: so as soon as ffmpeg 0.6 is releasd, the security team would have to care for 0.6 as well anyways.. | 09:46 |
| seb128 | pitti, I'm just saying that based on siretart`s comment | 09:46 |
| seb128 | "users sad because we're missing lots of codecs" | 09:47 |
| pitti | siretart`: that's the natural flow of things, yes; but they'd have to care about it much longer if it's in lucid, too; | 09:47 |
| pitti | siretart`: and apart from the seucrity side, if 0.6 isn't stable yet, it sounds like we would introduce more problems than we solve | 09:47 |
| pitti | I mean seriously, how many video formats cause problems on recent linux? My feeling is "hardly any" | 09:48 |
| pitti | but we do have a lot of _bugs_ with playing back videos indeed | 09:48 |
| siretart` | pitti: seb128: http://paste.ubuntu.com/393150/ is the change log in ffmpeg trunk so far since the 0.5 release | 09:48 |
| pitti | (thinks like searching in totem, etc.) | 09:48 |
| kees | pitti: AVC HD is miserable currently. /me really goes to bed now | 09:48 |
| siretart` | I even had been presented a backport of wmapro for 0.5... | 09:49 |
| pitti | kees: in totem? | 09:49 |
| kees | pitti: right. and not even mplayer can play it right. the only thing that seems to get it right is mythtv's internal player. | 09:49 |
| siretart` | pitti: AVC HD playback is pretty bad shape in all ubuntu packages right now | 09:49 |
| pitti | seb128: so, I guess we can argue either way (for 0.5 or 0.6), but I really object to having _both_ as a rational answer | 09:49 |
| kees | there will always be new codecs. | 09:50 |
| * kees votes for 0.6 just because it'll be easier to get fixes for in 3 years. :) | 09:50 | |
| * kees really really goes to bed | 09:50 | |
| === yofel_ is now known as yofel | ||
| pitti | well, that's fair enough | 09:50 |
| seb128 | pitti, I've not spent enough time looking at bugs and I don't know enough about gst-ffmpeg and ffmpeg to have an argumented answer there | 09:50 |
| pitti | but that wouldn't help you at all if gst used 0.6 and everything else 0.5 | 09:51 |
| siretart` | pitti: there are no 'stable' releases. ffmpeg development is way to fast to even think about that. It took years to convince upstream to do at least snapshot releases. ATM, its mainly me who tries to identify security related changes in trunk and backports them to release branches | 09:51 |
| pitti | siretart`: so, what's your recommendation right now? | 09:51 |
| seb128 | pitti, I'm mainly trying to avoid us realizing in one month that we are flooded by totem gst-ffmpeg crash bugs because we use a non support ffmpeg and gst combinaison | 09:51 |
| ttx | asac: about bug 526480 -- you think you'll have time for it ? | 09:51 |
| ubottu | Launchpad bug 526480 in liblog-log4perl-perl "[MIR] liblog-log4perl-perl" [High,New] https://launchpad.net/bugs/526480 | 09:51 |
| ttx | otherwise may be best to assign it to someone else in MIR team | 09:51 |
| seb128 | pitti, and being stucked in a sucking position then for the lts because it's too late for changes | 09:51 |
| pitti | seb128: right, and I'm trying to avoid that flood by suddenly switching to a new upstream ffmpeg in gst which nobody tested yet.. | 09:52 |
| seb128 | well it's an internal copy | 09:52 |
| seb128 | it has been tested by upstream | 09:52 |
| seb128 | and switch the configure flag back is easy | 09:52 |
| siretart` | pitti: with following three options: A) compiling new gst-ffmpeg against 0.5 B) reverting to old gst-ffmpeg and C) new gst-ffmpeg with internal copy | 09:52 |
| siretart` | pitti: I'd probably vote C>B>A | 09:53 |
| seb128 | same here | 09:53 |
| pitti | siretart`: I'm interested why you favor C | 09:53 |
| seb128 | since the first one is unsupported and crashing | 09:53 |
| pitti | it seems like the least sensible option to me | 09:53 |
| siretart` | pitti: it is the only option blessed by upstream | 09:53 |
| seb128 | it's the one providing the best user experience | 09:53 |
| pitti | siretart`: like, "get twice the amount of bugs for double the price"? | 09:53 |
| seb128 | at a cost for us to fix issues in that copy | 09:53 |
| seb128 | pitti, well, we have to choice is we care about having less work or about having a better user experience | 09:54 |
| siretart` | let me ask in a different way | 09:54 |
| seb128 | since the less work solution will bring trouble and crashes | 09:54 |
| siretart` | who cares for gst-ffmpeg bugs these days? | 09:54 |
| pitti | so what about D) update system ffmpeg? | 09:54 |
| siretart` | in terms of crashers? | 09:54 |
| seb128 | care in which sense? | 09:54 |
| seb128 | nobody work on those | 09:54 |
| seb128 | but I would prefer not having crashers there | 09:55 |
| seb128 | I do care about what we ship to our users | 09:55 |
| pitti | seb128: you are sure that updating ffmpeg won't bring new problems? | 09:55 |
| seb128 | pitti, we would not update, we would use the gst-ffmpeg ffmpeg copy with is what upstream work on and test | 09:55 |
| seb128 | and which is the version which probably match best what gst-ffmpeg handle | 09:55 |
| pitti | seb128: sure we would | 09:55 |
| siretart` | pitti: D) would be an option as soon as we have an 0.6 release branch, or even better, the 0.6 release. I don't think that will happen in time for lucid | 09:56 |
| pitti | whether it's linked or internal, it's still a new version | 09:56 |
| persia | seb128: But why not take the ffmpeg gst-ffmpeg recommends and use that for system ffmpeg? | 09:56 |
| seb128 | D) would also mean a transition | 09:56 |
| seb128 | how much other things would that break? | 09:56 |
| siretart` | pitti: and I cannot commit for doing that transition in a couple of weeks. the last ffmpeg upgrade was pretty painful | 09:56 |
| seb128 | persia, because we are not sure how it would impact on everything else using ffmpe | 09:56 |
| seb128 | persia, ie xine, vlc, ... | 09:56 |
| seb128 | persia, what sirestart says | 09:57 |
| persia | And given schedule, urk. | 09:57 |
| pitti | siretart`: yes, I wasn't going to ask you to actually; (I favor neither C nor D, FWIW, but it seemed prudent to at least complete the option table) | 09:57 |
| siretart` | I can say for sure that our mplayer won't remotely compile against 0.6 | 09:57 |
| siretart` | but mplayer is special | 09:57 |
| siretart` | anyway | 09:57 |
| seb128 | pitti, well new version right, but with limited scope, it just needs to be tested on gst-ffmpeg, we don't risk stability issue for ie xine | 09:57 |
| seb128 | or mplayer or vlc or etc | 09:58 |
| pitti | so, I don't think I have any new arguments at this point; seems we just need to agree to disagree then :) | 09:58 |
| siretart` | I think the safest option would be to revert to lucid's gst-ffmpeg, and promote a PPA with a newer gst-ffmpeg | 09:59 |
| pitti | siretart`: s/lucid/karmic/ ? | 09:59 |
| siretart` | err, of course | 09:59 |
| siretart` | I think the safest option would be to revert to karmic's gst-ffmpeg, and promote a PPA with a newer gst-ffmpeg | 09:59 |
| siretart` | and upload a newer gst-ffmpeg to lucid-backports that uses the internal copy of ffmpeg | 10:00 |
| seb128 | how much drawback is that compared in format supports, bug fixed, etc? | 10:00 |
| pitti | (we should probably go to 0.10.9-3, not -1, but details..) | 10:00 |
| seb128 | siretart`, do you know what slomo plans to do for debian? | 10:00 |
| siretart` | seb128: no idea, I havn't seen him on irc for quite some time now | 10:01 |
| siretart` | I think he is going with newer gst-ffmpeg compiled against 0.5 | 10:01 |
| siretart` | read: option A | 10:01 |
| seb128 | so it seems pitti and security team stand strongly against C | 10:01 |
| seb128 | so we have choice between downgrade or stay with that unsupposed binaison | 10:02 |
| seb128 | how can we get feedback on well or not gst-ffmpeg + ffmpeg 0.5 is working or crashing or...? | 10:02 |
| seb128 | on *how* well | 10:02 |
| pitti | my personal gut feeling is A>B>D>C, but since it seems that D) is not practical, it reduces to A>B>C | 10:03 |
| siretart` | I'm told that gst-ffmpeg comes with an extensive testsuite | 10:03 |
| pitti | seb128: hm, we could look at gstreamer/totem/gst-ffmpeg bugs since lucid? | 10:03 |
| RAOF | I guess we could run totem over a test-suite of video files; I know they exist. | 10:03 |
| siretart` | perhaps running that would give us more insight? | 10:03 |
| pitti | siretart`: sounds like a good idea | 10:03 |
| pitti | everyone watch pr0n for a week and report the results! | 10:04 |
| seb128 | ok, so let's stay on A and try to do some testing with it? | 10:04 |
| seb128 | maybe talk to the qa team about organizing some testing on that? | 10:04 |
| seb128 | just to know where we stand | 10:04 |
| siretart` | seb128: perhaps you could try talking to upstream about that issue? | 10:05 |
| siretart` | I mean with your ubuntu gnome guy hat on? | 10:05 |
| pitti | looks like http://live.gnome.org/GStreamerMediaTest | 10:05 |
| seb128 | what issue? how to test? | 10:05 |
| siretart` | about option A) anyway despite their explicit disapproval | 10:05 |
| siretart` | this choice is not going to please them | 10:05 |
| seb128 | siretart`, who did you talk to upstream about that before? | 10:06 |
| seb128 | I will get in touch with them | 10:06 |
| siretart` | seb128: to bilboed | 10:06 |
| seb128 | ok thanks | 10:06 |
| siretart` | seb128: he approached me in #ffmpeg-devel | 10:06 |
| siretart` | not sure if there is an gst-ffmpeg specific dev channel | 10:07 |
| seb128 | siretart`, #gstreamer will do | 10:07 |
| siretart` | I'll lurk | 10:07 |
| Keybuk | well, I can replicate the press-ENTER-to-kill-X bug | 10:07 |
| pitti | Keybuk: ah, when you see the mouse cursor on a VT? | 10:08 |
| siretart` | anyway, need to return to work now, will file the sec bug later | 10:08 |
| pitti | siretart`: thanks a lot for the heads-up! | 10:08 |
| Keybuk | pitti: no, fixed those bugs - now you see full X with gnome panels | 10:08 |
| ogra | funny, that bug vanished for me exactly today | 10:08 |
| pitti | yay | 10:08 |
| pitti | ogra: oh, how? nothing changed in that regard, except perhaps the moon phase to influence the chances? | 10:09 |
| sladen | I got the mouse-on text vt... it even changes cursor when you hover over the GDM login box | 10:09 |
| sladen | (not that you can see it) | 10:09 |
| ogra | pitti, well, then its the moon phase :) for the first time i could hit enter in the keyring dialog without ending up at gdm | 10:09 |
| pitti | ogra: I suppose it's just because your CPU now starts slightly warmer with the winter end, so the booting is 0.01 s faster | 10:10 |
| ogra | hmm, its actually slower | 10:10 |
| ogra | but i think thats due to ureadahead reprofiling, i didnt reboot twice | 10:11 |
| ogra | 11s | 10:11 |
| apw | Keybuk, as some additioanl data i think that the die on return is occurs every time if you use nomodeset ... seemed to on my mini10 | 10:12 |
| apw | pitti, ok this new behaviour is already being complained about ... that you can eject and it stays mounted ... which it would | 10:12 |
| apw | pitti, presumably due to the devkit-disks cahnge which makes it work for some types of mount | 10:13 |
| apw | bug #476654 | 10:13 |
| ubottu | Launchpad bug 476654 in udisks "CD eject but not unmount when using drive button" [Medium,Triaged] https://launchpad.net/bugs/476654 | 10:13 |
| pitti | apw: right, it's that bug | 10:13 |
| pitti | apw: it's not clear yet whether that's a kernel bug or feature | 10:13 |
| pitti | apw: the kernel already cleans up stale mounts for e. g. USB sticks, if you yank them out | 10:14 |
| pitti | apw: if it's a feature that this isn't done for CD-ROMs, then we need to add userspace code to listen to remove events and call umount -l | 10:14 |
| apw | pitti, its not at all clear to me letting you take it out is good at all | 10:14 |
| pitti | apw: I talked to cooloney-Beijing, and he was going to look into it | 10:14 |
| ogra | pitti, but as you explained to me yesterday the kernel also powers down the device | 10:14 |
| ogra | (in the usb case) | 10:14 |
| apw | pitti, seems we are chaniging good behaviour just because people don't know what their eject button means | 10:15 |
| pitti | apw: there's no other way for e. g. DVDs | 10:15 |
| pitti | apw: udisks unlocks the door after mounting | 10:15 |
| pitti | apw: but if totem open()s it again, it again triggers the lock, and there's nothing we can do to unlock it again | 10:15 |
| apw | pitti, yep and i personally think thats a mistake | 10:15 |
| apw | pitti, its locked cause its in use | 10:15 |
| pitti | well, it's one interpretation; but it basically renders the eject button useless | 10:16 |
| pitti | and it seems people are used to it | 10:16 |
| pitti | and taking out a readonly medium like a DVD is pretty harmless, at least compared to yanking out USB sticks | 10:16 |
| apw | well in reality people don't think generally thats why we have to handle them just pulling out USB disks when we know its something you should never do | 10:16 |
| * apw grumbles ... yes but what about non-read only media | 10:17 | |
| apw | like in the middle of a burn | 10:17 |
| ogra | wouldnt that lock ? | 10:17 |
| pitti | apw: just passing the message here.. OEM team currently adds a sysctl.d file to set the flag.. | 10:17 |
| apw | ogra, not with the requested change to the kernel to turn off the lock | 10:17 |
| pitti | ogra: we can probably make it to lock (not sure if it does right now) | 10:17 |
| ogra | we should | 10:18 |
| cooloney | apw: we found all the eject button do not work | 10:18 |
| pitti | not locking by default doesn't mean that we can't lock manually, surely? | 10:18 |
| ogra | pulling out in the middle of a burn seems bad | 10:18 |
| cooloney | so we have to add sysctl.d trick to make it works | 10:18 |
| apw | cooloney, they don't work till you unmount the media in software right? | 10:18 |
| pitti | ogra: well, YAFIYGI.. :) | 10:18 |
| cooloney | apw: exactly | 10:18 |
| pitti | apw: (in which case you'd just use the eject button in nautilus to get it ejected) | 10:18 |
| cooloney | if the data disc is mounted, eject button does not work | 10:19 |
| apw | and now you tell the kernel to allow you do something stupid, and complain when it does something stupid? | 10:19 |
| pitti | ogra: but yes, we should lock during burn | 10:19 |
| ogra | pitti, i didnt ask :) | 10:19 |
| apw | cooloney, that is as designed though | 10:19 |
| pitti | apw: why is taking out a mounted CD-ROM stupid? | 10:19 |
| apw | its stupid if you didn't unmount it cause you didn't tell me it wasn't needed (me == kernel) | 10:19 |
| cooloney | apw: actually, 99% normal users will press that button | 10:19 |
| apw | yep, and does it work in windows? | 10:20 |
| cooloney | instead of umounting it in the GUI | 10:20 |
| pitti | apw: yes, it does | 10:20 |
| cooloney | apw: right | 10:20 |
| pitti | windows doesn't lock the tray door | 10:20 |
| apw | bah ... | 10:20 |
| cooloney | windows does not do that | 10:20 |
| ogra | apw, but but .... there is a button on the device and i pressed it ... must be broken if the Cd doesnt come out | 10:20 |
| * apw cuts off one of ogra's fingers ... and now? | 10:20 | |
| * ogra takes a toe | 10:20 | |
| cooloney | ogra: exactly, user will think that is a hardware problem | 10:20 |
| pitti | ouch | 10:20 |
| cooloney | button does not work | 10:21 |
| pitti | apw: so, I agree that both bugs (locking and unmounting of stale mounts) should be fixed together; if the latter requires an userspace monitor, I'm happy to look into that | 10:21 |
| apw | hrm you won't convince me that ill informed users are right | 10:21 |
| apw | but i seem to be in the minority here | 10:21 |
| ogra | doesnt have to do with being informed | 10:21 |
| ogra | just with natural expectations | 10:22 |
| persia | I'm confused. Will pressing the button just eject, or tell the kernel to force-umount and then eject? | 10:22 |
| apw | changing the default in the kernel is 'easy' but there will be two instant issues: 1) burn will be vunerable, 2) the errors will puke till it gets unmounted | 10:22 |
| pitti | persia: it will just eject, and kernel/userspace have to tidy up after it | 10:22 |
| smb | Well sort of yes. I would expect the button not to work when the cdrom is mounted because its in use | 10:22 |
| apw | persia, the button doesn't go to the kernel | 10:22 |
| apw | the kernel doesn't find out till the tray has opened and the media is gone | 10:22 |
| ogra | smb, whats mounting ? can you explain to my mother ? | 10:22 |
| cooloney | apw: actually burning issue is the same issue as you yanking a usb stick when you are writting something into the usb stick | 10:23 |
| ogra | she popped that CD in and played some music ... now she pressed the button ... | 10:23 |
| apw | ogra, no i can't but then i can explain 'click here' ... and thats what i do | 10:23 |
| smb | ogra, Thats about ill informed users. Linux != Windows != Mac | 10:23 |
| Keybuk | reading documentation on Linux terminal devices, while working for this company, is confusing | 10:23 |
| ogra | smb, i would agree if there were only slot-in CD roms | 10:23 |
| ogra | as soon as you have a button the button should just work | 10:24 |
| apw | but ogra the button does just work, the error is that you think its an eject button | 10:24 |
| ogra | Keybuk, stop reading ! we dont want you to resign to understand the prob ! | 10:24 |
| apw | when its actually an eject the media if its not being used, button | 10:24 |
| apw | always was | 10:24 |
| ogra | apw, there is a eject logo on it | 10:24 |
| apw | you think thast what the logo is, thats not my fault | 10:25 |
| ogra | (bar with a little triangle above) | 10:25 |
| cooloney | but the problem is the data disc is auto mounted defautly | 10:25 |
| apw | yep, but thats a design issue, i can't help they have used the wrong logo | 10:25 |
| cooloney | if you insert the data disc, the eject button won't work | 10:25 |
| ogra | cooloney, right and the button should properly unmount it | 10:25 |
| apw | and by design the button _cannot_ do that | 10:25 |
| ogra | and then eject the CD | 10:25 |
| apw | as it does not have a channel to tell the kernel it has been pressed | 10:26 |
| ogra | apw, why ? userspace surely gets a button event | 10:26 |
| apw | why do you assume that, cause it has an eject logo? | 10:26 |
| ogra | yes :) | 10:26 |
| apw | the button is a physical eject, it tell the drive to open if its not locked | 10:26 |
| cooloney | apw: yeah, since I use my cd player, we think that button means open the tray | 10:27 |
| ogra | ok, thats a hardware flaw | 10:27 |
| apw | the drive if unlocked will open and send a 'i just opened and your media went away' event | 10:27 |
| ogra | still ... user expectations are differently and we should apply | 10:27 |
| apw | its far too late by then to cope | 10:27 |
| * apw goes back into his troll cave, and erects his anti-user force field | 10:27 | |
| pitti | why? you unmount, and userspace copes just fine | 10:28 |
| ogra | why is it to late ? you can still unmount then | 10:28 |
| smb | In theory maybe you could. But question would be is it done | 10:28 |
| pitti | udisks and friends get the removal events, nautilus switches away from it, etc. | 10:28 |
| apw | you can't unmount a r/w device then ... if yo uhave any data to write | 10:28 |
| ogra | its not like you write to a readonly media | 10:28 |
| pitti | the fun thing is that the kernel unmounts the r/w usb stick just fine | 10:28 |
| smb | ogra, And my cd burner? | 10:28 |
| pitti | but doesn't for a read-only CD-ROM mount | 10:28 |
| ogra | smb, your CD burner software should acre for locking | 10:28 |
| ogra | *care | 10:29 |
| ogra | and remove the lock when its done | 10:29 |
| apw | pitti, 'just fine' is a little unfair | 10:29 |
| smb | ogra, Agreed, do we know it does :) | 10:29 |
| apw | ogra, it doesn't need to ... cause its locked on use ... currently | 10:29 |
| ogra | smb, if it doesnt its a bug :) | 10:29 |
| apw | anyhow ... i'll go change the default, you can handle the fallout :) | 10:29 |
| ogra | its not like there are millions of linux CD write apps | 10:29 |
| apw | pitti, i think ogra just volunteered to fix all apps which _write_ to cd media | 10:30 |
| ogra | its a handfull of patches in max if burning SW really misses here | 10:30 |
| pitti | sweet ;) | 10:30 |
| ogra | what ? | 10:30 |
| * ogra glares at apw | 10:30 | |
| apw | ogra, note that that includes things which mount r/w disks for instance | 10:30 |
| * apw heard you | 10:30 | |
| pitti | ogra: I can look at brasero | 10:30 |
| soren | I could have sworn that it used to work that way. | 10:30 |
| ogra | pitti, well, arent there only two low level tools atm ? we should fix the backend | 10:31 |
| pitti | soren: in the hal era, hal polled the CD-ROM for button presses and did a lazy unmount/eject | 10:31 |
| soren | pitti: Back in the hal days, didn't we somehow detect that the user had pressed the eject button=? | 10:31 |
| soren | Right, exactly. | 10:31 |
| soren | There's and SG_IO ioctl thingamabob to do that. | 10:31 |
| cooloney | that is funny, because the button works very well in jaunty | 10:31 |
| pitti | ogra: yes, probably | 10:31 |
| cooloney | but we failed since karmic | 10:32 |
| pitti | cooloney: that was still the hal polling | 10:32 |
| Keybuk | \o/ | 10:32 |
| cooloney | pitti: i understand | 10:32 |
| Keybuk | I fixed the enter-kills-X bug | 10:32 |
| pitti | but it causes an awful amount of wakeups, etc. | 10:32 |
| * pitti hugs Keybuk | 10:32 | |
| * seb128 hugs Keybuk | 10:32 | |
| soren | Keybuk: Oh, no! | 10:32 |
| apw | Keybuk, sounds good ... what the heck was it | 10:32 |
| ogra | grouphug ! | 10:32 |
| Keybuk | apw: plymouth was setting the VT back into Canonical Mode | 10:32 |
| soren | Keybuk: I rely on that bug to get to gdm occasionally. :) | 10:32 |
| pitti | does that prove that Canonical is bad then? | 10:32 |
| apw | oh no time for a name change | 10:33 |
| pitti | apw: is that "oh, no time" or "oh no, time"? :) | 10:33 |
| Keybuk | since Raw Mode is better, let's call ourselves RAW Ltd | 10:33 |
| apw | oh no, | 10:33 |
| cooloney | apw: actually, i wanna talk about the second cdrom issue | 10:33 |
| soren | Every now an again when I boot, I will have a console login prompt and a mouse cursor(!). Typing yields nonsense on the console. Pressing return kills X, it restarts, and yay, I have gdm. | 10:34 |
| cooloney | apw: https://bugs.launchpad.net/ubuntu/+source/udisks/+bug/476654 | 10:34 |
| ubottu | Launchpad bug 476654 in udisks "CD eject but not unmount when using drive button" [Medium,Triaged] | 10:34 |
| Keybuk | soren: I fixed that one last week ;) | 10:34 |
| apw | i am assuming someone else will look after that one cooloney | 10:34 |
| pitti | soren: that's bug 523788 which Keybuk supposedly fixed in his local branch | 10:34 |
| ubottu | Launchpad bug 523788 in plymouth "Only see X mouse cursor on VT during boot" [High,Confirmed] https://launchpad.net/bugs/523788 | 10:34 |
| Keybuk | "supposedly" ... what, you don't trust me? :p | 10:34 |
| soren | Keybuk: I'm /almost/ sure I've seen it this week. I'll keep an eye out to make sure. | 10:34 |
| pitti | soren: yes, it's in today's lucid | 10:34 |
| pitti | Keybuk: upload it! upload it! | 10:35 |
| Keybuk | soren: I haven't uploaded fixed plymouth yet | 10:35 |
| soren | Keybuk: Fixed and uploaded last week? | 10:35 |
| soren | Ah, ok. | 10:35 |
| soren | that explains :) | 10:35 |
| Keybuk | on the basis that if I don't fix all of the known bugs, I'll get lynched | 10:35 |
| seb128 | Keybuk doesn't like to share fixes apparently ;-) | 10:35 |
| smb | Keybuk, Just doit :) | 10:35 |
| cooloney | apw: i am working on this. heh | 10:35 |
| apw | cooloney, ok what you thinking | 10:35 |
| Keybuk | plus am testing to make sure I don't introduce new ones | 10:35 |
| Keybuk | like right now, the text renderer is broken again | 10:35 |
| Keybuk | :'( | 10:35 |
| pitti | Keybuk: does it render Klingon now? | 10:36 |
| cooloney | apw: i failed to find where does kernel umount or cleanup the removed usb stick | 10:36 |
| Keybuk | pitti: you could write a klingon plugin if you like | 10:36 |
| cooloney | when you yanking a usb stick from a machine | 10:36 |
| apw | cooloney, are we sure the kernel even does that? | 10:36 |
| cooloney | it should be similar to press button eject t a file system | 10:36 |
| Keybuk | cooloney: the kernel doesn't | 10:36 |
| apw | Keybuk, who _does_ do that | 10:37 |
| cooloney | apw: i am not sure | 10:37 |
| Keybuk | apw: userspace | 10:37 |
| cooloney | i guess is user app | 10:37 |
| smb | Keybuk, udev? | 10:37 |
| cooloney | but pitti told me that kernel does that | 10:37 |
| Keybuk | kernel gives us a "device removed" uevent | 10:37 |
| cooloney | right Keybuk | 10:37 |
| Keybuk | udev tells udisks tells session, tells udisks to unmount | 10:37 |
| pitti | hm, didn't it use to? | 10:37 |
| apw | Keybuk, do we know who in userspace, and why cdroms don't ? | 10:37 |
| apw | hrm | 10:37 |
| Keybuk | pitti: don't think so - it'd be pretty strange for the kernel to just vanish half the filesystem without userspace doing it | 10:37 |
| * pitti tries | 10:37 | |
| cooloney | right, why cdrom fails | 10:37 |
| pitti | Keybuk: ok, then we need to teach udisks about that | 10:38 |
| apw | cooloney, cause the 'drive' isn't gone like is in usb i assume | 10:38 |
| cooloney | i monitors the udisks in lucid | 10:38 |
| Keybuk | but I don't know for ausre | 10:38 |
| Keybuk | apw: right, that's what I suspect | 10:38 |
| cooloney | and devicekit-disk in karmic | 10:38 |
| Keybuk | apw: which would fit what I believe to be true | 10:38 |
| cooloney | it will get cd remove event as usb stick | 10:38 |
| Keybuk | usb key removed => remove event for device => userspace cleans up | 10:38 |
| Keybuk | cdrom ejected => device is still there => userspace unaware | 10:39 |
| Keybuk | I thought we locked the CD tray ? :) | 10:39 |
| smb | apw, So the "media gone away" probably not produce a uevent? | 10:39 |
| davmor2 | Keybuk: I have the enter to get gdm issue on une this morning and last night | 10:39 |
| apw | Keybuk, i wish :) | 10:39 |
| Keybuk | in fact, I'm pretty sure this is *why* we locked the CD tray :p | 10:39 |
| Keybuk | davmor2: I had it 10 minutes ago, before I fixed it :p | 10:39 |
| cooloney | ok, remove usb key | 10:39 |
| pitti | Keybuk, apw: so, if I yank out a mounted usb key, it gets unmounted | 10:39 |
| davmor2 | Keybuk: so the fix should be in for tomorrow then? | 10:40 |
| pitti | but I guess it's not the kernel then | 10:40 |
| ogra | davmor2, you need the secret sources.list entry to pull directly from Keybuks laptop and then dist-upgrade | 10:40 |
| cooloney | got 2 uevent, one is sdb, the other is sdb1 | 10:40 |
| Keybuk | davmor2: should be | 10:40 |
| Keybuk | ogra: sources.list?! | 10:40 |
| ogra | davmor2, or wait :) | 10:40 |
| pitti | Keybuk, apw: ah, if I kill udisks-daemon, it doesn't, so I guess we need to fix udisks to lazy-unmount CD-ROMs then | 10:40 |
| cooloney | remove cd disc, a one remove event | 10:40 |
| Keybuk | you need to cd into co/plymouth, then run "make install", then move bits around a bit to match :p | 10:40 |
| apw | pitti, how would it know to do it | 10:40 |
| ogra | details :) | 10:40 |
| davmor2 | ogra: no I just need to travel over to keybuks hand him all my lucid boxes and say fix these ;) | 10:40 |
| cooloney | pitti: agree | 10:40 |
| Keybuk | pitti: as apw said, I suspect the problem here is that we don't know the CD-ROM has been ejected :p | 10:40 |
| apw | pitti, without polling ... when you might as well do what hal did | 10:41 |
| cooloney | so is there any event from cdrom.c driver for ejecting? | 10:41 |
| pitti | we do get an uevent with CD-rom eject | 10:41 |
| Keybuk | cooloney: no | 10:41 |
| Keybuk | pitti: no! | 10:41 |
| cooloney | Keybuk: too bad | 10:41 |
| pitti | UDEV [1268304083.700451] change /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8.4/1-8.4:1.0/host2/target2:0:0/2:0:0:0 (scsi) | 10:41 |
| Keybuk | pitti: the drive is *still there* :) | 10:41 |
| Keybuk | right, there might be a change event | 10:41 |
| pitti | Keybuk: not a remove, a change | 10:41 |
| Keybuk | that would be worth investigating | 10:41 |
| pitti | which is just fine | 10:41 |
| pitti | I just tried it here | 10:41 |
| apw | pitti, so you could use that ... excellent | 10:42 |
| Keybuk | change => check for media => media gone => unmount | 10:42 |
| pitti | 'zactly | 10:42 |
| Keybuk | I was building up to that | 10:42 |
| apw | ok so that sounds like a plan ... | 10:42 |
| cooloney | how about add a new uevent in cdrom.c driver to do that | 10:42 |
| pitti | apw, Keybuk, cooloney: ok, I'll look into fixing the cdrom unmount in udisks | 10:42 |
| apw | pitti, thanks | 10:42 |
| pitti | cooloney: uevents are all fine | 10:42 |
| apw | cooloney, sounds like we have what we need ... | 10:42 |
| matti | Hi apw | 10:42 |
| * cooloney hugs pitti | 10:42 | |
| cooloney | apw: thanks, | 10:42 |
| cooloney | Keybuk: thanks | 10:42 |
| pitti | bug 476654 targetted to lucid adn assigned to me | 10:43 |
| ubottu | Launchpad bug 476654 in udisks "CD eject but not unmount when using drive button" [Medium,Triaged] https://launchpad.net/bugs/476654 | 10:43 |
| cooloney | i will let those guys know this issue | 10:43 |
| Keybuk | slangasek: I guess you're not up? | 10:44 |
| apw | pitti, do we need to track the 'fix burners' side of this issue? | 10:44 |
| apw | get a nice bug assigned to ogra | 10:45 |
| pitti | apw: I'll add a task to bug 397734 for checking this | 10:45 |
| ubottu | Launchpad bug 397734 in devicekit-disks "can't eject cdrom with hardware button" [Medium,Fix released] https://launchpad.net/bugs/397734 | 10:45 |
| cooloney | apw: you scared ogra away, heh | 10:47 |
| pitti | done | 10:47 |
| ogra | ah, back to normal ... http://people.canonical.com/~ogra/osiris-lucid-20100311-3.png | 10:50 |
| pitti | *envy* | 10:50 |
| apw | pitti, where will i fine the usdisks changes you made which unlock the drive? i need to disable them to test this change | 10:57 |
| pitti | apw: sudo python, open("/dev/sr0") should lock it again | 10:58 |
| pitti | apw: but the thing you asked for is http://cgit.freedesktop.org/udisks/commit/?id=1064be64a7398b9b5dec4ece39b738ff15073d56 | 10:59 |
| directhex | so does anyone know what would cause an ntfs entry in /etc/fstab to lock up lucid during boot? | 11:07 |
| asac | cjwatson: thanks for klibc fix | 11:09 |
| apw | directhex, what does it say? waiting for it? | 11:10 |
| directhex | apw, yeah, i think that was it | 11:10 |
| apw | smb, you had something about mount lines needing a new option (that they should always have had) to make boot work | 11:11 |
| smb | right | 11:11 |
| smb | nobootwait or so... | 11:11 |
| smb | directhex, Right, try "nobootwait" in fstab as one of the options | 11:13 |
| directhex | i'll give it a shot when i'm feeling brave enough to go potentially unbootable again | 11:14 |
| directhex | how about the switch to nouveau? totally killed my x, with no obvious way to go back to nvidia-glx (ended up dropping to a terminal & installing things manually) | 11:15 |
| smb | directhex, It worked well for me as I had entries in there with "user" for usb sticks which was not enough anymore | 11:15 |
| directhex | smb, if the lack of nobootwait, which i'd never heard of until today, is enough to make the system unbootable, even in recovery mode, perhaps something needs to behave better? | 11:16 |
| * matti seconds directhex | 11:16 | |
| apw | directhex, see if thats the fix, i think that someone was meant to be making the prompt easier to understand | 11:17 |
| smb | directhex, Actually it gives you some "imo cryptic" hint. Though I am not sure its carried over to plymouth. Was it displaying some text waiting for xxx [SM]? | 11:17 |
| apw | directhex, it did prompt you to tell you there was an issue right? | 11:17 |
| directhex | smb, yes | 11:17 |
| smb | At that point you can press 's' to skip | 11:18 |
| apw | pitti, was it you who said that those messages were on the list to fix? | 11:18 |
| directhex | smb, really? THAT wasn't made clear | 11:18 |
| * smb is not even sure what 'm' would do. But 's' was going on | 11:19 | |
| * ogra always thought SM was something that involves whips | 11:20 | |
| directhex | wait, [sm] is a prompt? | 11:20 |
| smb | Waiting indefinitely for a mount really counts as "sm" to me | 11:21 |
| ogra | it tells you the keys you can press | 11:21 |
| smb | directhex, yep | 11:21 |
| directhex | son of a... | 11:21 |
| ogra | on fsck there is also C | 11:21 |
| ogra | (for cancel) | 11:21 |
| ogra | if the theme doesnt handle that now though | 11:21 |
| pitti | apw: "those messages"? | 11:22 |
| apw | pitti, sorry, the plymouth mesages when it wants you to skip a mount and says /boot [SM] | 11:23 |
| pitti | apw: oh, I'm afraid I have no idea about that one | 11:23 |
| apw | someone was saying they were under review, and wanted to make sure that i was correct | 11:23 |
| apw | may have been slangasek | 11:23 |
| cjwatson | asac: upstream backports are the easy ones ;-) | 11:37 |
| Keybuk | that's interesting | 11:43 |
| Keybuk | a bug is fixed by a random line of code that slangasek added, without any reference to a bug number, and that he didn't send upstream | 11:43 |
| Keybuk | and I can't find any reason for him adding that other than "he noticed it was probably needed" | 11:44 |
| siretart` | pitti: mdeslaur: ffmpeg bug as discussed earlier today filed as bug #537297 | 12:09 |
| ubottu | Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/537297) | 12:09 |
| === MacSlow is now known as MacSlow|lunch | ||
| === tkamppeter_ is now known as tkamppeter | ||
| sabdfl | is anyone here particularly focused on chromium? | 13:06 |
| persia | fta seems to spend the most time on it (dailies, etc.) | 13:07 |
| persia | (assuming you mean chromium-browser rather than chromium-bsu) | 13:07 |
| ogra | or chromium OS :) | 13:08 |
| persia | That's "Chrome OS" | 13:08 |
| ogra | i thought there was a chromium branch of it as well ? | 13:08 |
| cjwatson | Chromium OS is the open-source bit of Chrome OS | 13:09 |
| * persia isn't 100% sure | 13:09 | |
| persia | Aha! | 13:09 |
| cjwatson | analogously to Chromium/Chrome | 13:09 |
| ogra | yeah | 13:09 |
| sabdfl | yup | 13:11 |
| sabdfl | to see if we can add http://www.ubuntugeek.com/ambiance-theme-for-google-chromechromium.html to the package | 13:11 |
| sabdfl | or maybe it needs to be in the light-themes package? | 13:12 |
| sabdfl | seems odd to have bits there for a Universe app | 13:12 |
| sabdfl | but it's a *popular* universe app :-) | 13:12 |
| persia | Could do a light-chromium-theme package. | 13:12 |
| ogra | asac, ^^^ | 13:12 |
| persia | (or chromium-theme-light) | 13:12 |
| cjwatson | lamont: is it feasible to update util-linux to 2.17.1? see bug 530071 | 13:16 |
| ubottu | Launchpad bug 530071 in ubiquity "Lucid Default live-cd install fails with 4K sector / Advanced Format drives" [High,Triaged] https://launchpad.net/bugs/530071 | 13:16 |
| asac | fta: ^^ | 13:23 |
| asac | fta: (see a few lines above for chromium theming) | 13:23 |
| * ogra thinks we should just set them as defaults in the package | 13:24 | |
| ogra | (both, the scrollbar and the theme) | 13:25 |
| persia | How does that play with xubuntu/kubuntu? (I'm not sure folks using mythbuntu, ubuntustudio, or ubuntu-server will run chromium-browser so much) | 13:26 |
| superm1 | ogra, the scrollbar is an extension, so i doubt it can be set up by default like that | 13:26 |
| superm1 | and it doesn't work on internal pages (chrome://) | 13:27 |
| ogra | hrm | 13:27 |
| \sh | moins | 13:38 |
| cjwatson | pitti: so, you removed libjpeg7 from the archive saying "not needed in lucid", but libjpeg-progs still depends on it | 13:45 |
| cjwatson | pitti: what's up with that?/ | 13:45 |
| pitti | uh? I ran checkrdepends on it | 13:45 |
| cjwatson | it has a bunch of rdepends, and we don't have libjpeg8 in lucid | 13:45 |
| cjwatson | (and I'm a bit sceptical about upgrading to it at this point) | 13:46 |
| cjwatson | you apparently left the libjpeg-progs binary in there, even though it's in the same source package, and libjpeg7 wasn't NBS | 13:46 |
| cjwatson | so I'm confused about what was going on :) | 13:46 |
| pitti | I spotted libjpeg7 while reviewing duplicated libraries | 13:47 |
| pitti | so I ran checkrdepends on those, and it seemed to have none | 13:47 |
| pitti | apparently I screwed up on that one then | 13:47 |
| cjwatson | pitti: shall I just reupload libjpeg7 to put it back? | 13:48 |
| cjwatson | pitti: what was the other duplicate, though? | 13:48 |
| pitti | cjwatson: I'd rather build it from 6b again | 13:48 |
| cjwatson | I wouldn't | 13:48 |
| cjwatson | 6b's build system sucked | 13:48 |
| cjwatson | IIRC it wasn't cross-buildable | 13:48 |
| pitti | hm, having a second implementation just because of that? it was built from 6b in karmic as well | 13:49 |
| cjwatson | plus libjpeg-progs was already bumped to 7, so going backward would be hard | 13:49 |
| cjwatson | can we just transition to 7? | 13:49 |
| pitti | $ apt-cache rdepends libjpeg62|wc -l | 13:49 |
| pitti | 555 | 13:49 |
| cjwatson | hm | 13:50 |
| pitti | that's what I wanted to avoid | 13:50 |
| yofel | hey, will there be 64bit installation media for ubuntu-netbook? as there are 64bit atom cpu's out there now | 13:50 |
| cjwatson | Debian's libjpeg-progs is built from 8 | 13:50 |
| cjwatson | so we could do 7+really6b-1 as the version for just the libjpeg-progs binary | 13:50 |
| pitti | right, I just thought the same | 13:51 |
| pitti | and in manic we can just sync it again | 13:51 |
| pitti | cjwatson: ok, I'll get that fixed ASAP, thanks for pointing out | 13:51 |
| cjwatson | pitti: oh, ok, thanks, I can do it if you're busy | 13:51 |
| pitti | I am, but since I broke it.. | 13:52 |
| cjwatson | heh | 13:52 |
| cjwatson | who isn't busy at the moment I guess | 13:52 |
| pitti | cjwatson: I created bug 537370 as a reminder | 13:55 |
| ubottu | Launchpad bug 537370 in libjpeg6b "build libjpeg-progs again" [High,In progress] https://launchpad.net/bugs/537370 | 13:55 |
| cjwatson | pitti: thanks | 13:55 |
| mr_pouit | there was already bug 535629 opened | 13:55 |
| ubottu | Launchpad bug 535629 in libjpeg6b "package libjpeg-progs is not built from any source package but several packages in lucid depend on it (dup-of: 537370)" [High,New] https://launchpad.net/bugs/535629 | 13:55 |
| mr_pouit | erf, ok | 13:55 |
| pitti | mr_pouit: sorry, noticed too late; duped | 13:56 |
| \sh | pitti: does that mean, for lucid+1 total transition to 7 or 8 ? hopefully mostly done by debian at some point? | 13:56 |
| pitti | \sh: to 8 presumably | 13:57 |
| pitti | I guess we'll get a lot through autosyncs | 13:57 |
| === MacSlow|lunch is now known as MacSlow | ||
| \sh | well...I get some new hardware for an additional buildserver in the next 2 months...it should be ready for lucid+1 ;) | 14:01 |
| lamont | cjwatson: Keybuk is the better one to ask about 2.17.1 though I think he might poke me about it, istr | 14:07 |
| zul | asac: ping | 14:15 |
| === Chex_ is now known as Chex | ||
| asac | zul: hi | 14:15 |
| asac | on MIR? | 14:15 |
| zul | asac: you read my mind ;) | 14:15 |
| asac | i approved the log thing (with a few comments) | 14:15 |
| zul | asac: cool thanks | 14:15 |
| asac | anything else i havent checked that is on your list? | 14:15 |
| zul | asac: not that I know of | 14:16 |
| asac | ok great | 14:16 |
| zul | thanks | 14:16 |
| tumbleweed | fr43ed | 14:39 |
| === dmart_ is now known as dmart | ||
| tumbleweed | garr, excues that, lag-- | 14:40 |
| pitti | tumbleweed: better change your password now :) | 14:44 |
| tumbleweed | pitti: that wasn't a password, thankfully | 14:44 |
| === jamie is now known as Guest19337 | ||
| maco2 | cjwatson: slangasek got it | 15:25 |
| === mcasadevall is now known as NCommander | ||
| === plars` is now known as plars | ||
| === deryck is now known as deryck[lunch] | ||
| === yofel_ is now known as yfoel | ||
| === yfoel is now known as yofel | ||
| === binarylooks_ is now known as binarylooks | ||
| fta | asac, ogra, persia, cjwatson: i don't think chromium has a system wide location for extensions like firefox, but i can sure check | 16:53 |
| persia | fta: Look a little higher up in the scrollback :) But good luck. | 16:54 |
| asac | fta: thanks | 16:54 |
| fta | persia, how far? | 16:56 |
| ogra | fta, up to the person who requested it i guess :) | 16:59 |
| fta | sabdfl, ^^ + i've been working on chromium since day one. I'll have a look at what's possible for that theme but i think we need a scheme for chromium extensions in general | 17:00 |
| === MacSlow is now known as MacSlow|capoeira | ||
| stefanlsd | Anyone else have an issue running /usr on a seperate partition on lucid? Trying to debug why. 1/2 times mountall doesnt mount /usr and need to hard reboot. Having an issue now where noveua drivers wont blacklist either | 17:06 |
| \sh | stefanlsd: last night I booted lucid with /usr on a separate partition successfully | 17:10 |
| stefanlsd | \sh: any issues since? my first boot always fails, then reboot works... | 17:12 |
| \sh | stefanlsd: nope...even my problem with LVMs disappeared yesterday | 17:13 |
| sabdfl | fta: yes. i don't know if they allow both system-level and per-user extensions | 17:13 |
| sabdfl | took ff years to get extensions working well | 17:13 |
| stefanlsd | \sh: kk. thanks. maybe i just need to re-install and start fresh :) | 17:14 |
| fta | sabdfl, i still have to push the ffmpeg codecs to lucid (currently only in the 3 chromium PPAs). the package is ready but i'm unsure about the redistribution license of some of those codecs (h264, aac..). I wouldn't mind some help here | 17:17 |
| fta | (this is needed for the HTML5 audio/video tags) | 17:18 |
| sabdfl | if they are open source, go ahead | 17:18 |
| fta | it's basically ffmpeg, which we already have, but configured/packaged differently | 17:19 |
| \sh | fta: talk to siretart` ;) | 17:30 |
| === deryck[lunch] is now known as deryck | ||
| siretart` | I got hilighted? | 17:34 |
| persia | siretart`: You were highlighted as a contact for fta to discuss ffmpeg packaging for the chromium-browser ffmpeg stuff | 17:35 |
| siretart` | fta: what do you mean with 'push ffmpeg codecs to lucid'? | 17:35 |
| siretart` | AFAIUI, chromium tracks astrange's ffmpeg-mt branch, is that right? | 17:36 |
| siretart` | fta? | 17:39 |
| fta | siretart`, http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-codecs-ffmpeg.head/files/head:/debian/ | 17:55 |
| * Keybuk teaches popey about = | 17:58 | |
| popey | ruhroh | 17:59 |
| fta | siretart`, yes, it's the -mt branch, with a bunch of patches and a build system from the chromium devs, and different flavors of codecs depending on the branding (chrome vs chromium) | 17:59 |
| Keybuk | shells used by Real Men have a neat =thingy shortcut ;) | 17:59 |
| Keybuk | it's basically `which thingy` | 17:59 |
| Keybuk | so I just do dpkg -S =skype | 17:59 |
| Keybuk | :p | 17:59 |
| mathiaz | Could an archive admin promote vlan-modules-2.6.32-16-generic-di and vlan-udeb to main? | 17:59 |
| popey | ahhh neato! | 17:59 |
| popey | thanks :) | 17:59 |
| mathiaz | These are binary packages only | 17:59 |
| Keybuk | doesn't work in bash though | 17:59 |
| popey | bah | 17:59 |
| popey | do I have to use keybuksh | 18:00 |
| davmor2 | popey: emacs ;) | 18:00 |
| ogra | Keybuk, now whats a real mans shell ? | 18:00 |
| Keybuk | zsh! | 18:00 |
| ogra | pfft | 18:00 |
| Keybuk | I resisted the urge to make a \sh! joke | 18:00 |
| ogra | lol | 18:00 |
| zyga | has anyone seen mvo recently? | 18:05 |
| Keybuk | he's on holiday I believe | 18:08 |
| blueyed | zyga: just wanted to ping him also, about bug 502641 | 18:08 |
| ubottu | Launchpad bug 502641 in apt "[Lucid] apt-get source always selects highest available version instead of the specified one" [Unknown,Fix released] https://launchpad.net/bugs/502641 | 18:08 |
| blueyed | it should be fixed, but does not appear so.. | 18:08 |
| blueyed | the proposed fix (http://bazaar.launchpad.net/~mvo/apt/mvo/revision/1693) appears to be in Ubuntu. | 18:10 |
| blueyed | Nobody affected by this? Even the "--only-source" workaround mentioned in the Debian bug does not work for me.. have to resort to using dget.. | 18:11 |
| kamusin | pitti, thanks for patching tzdata at time, you are our hero | 18:11 |
| zyga | Keybuk: I see | 18:13 |
| fta | siretart`, persia: i guess i should just send chromium-codecs-ffmpeg to lucid and wait for the NEW to be reviewed, unless you already have comments i should address | 18:15 |
| * persia is just passing messages | 18:16 | |
| mathiaz | lamont: re bug 532587 - is it important/mandatory that system users/groups are removed when the package is removed/purged? | 18:17 |
| ubottu | Launchpad bug 532587 in puppet "removal of package does not stop daemon" [Medium,Fix released] https://launchpad.net/bugs/532587 | 18:17 |
| cjwatson | zyga,blueyed: I think he's off ill | 18:18 |
| Keybuk | PITTI! | 18:19 |
| \sh | Keybuk: please do...I need to laugh today ;) | 18:19 |
| lamont | mathiaz: uh... see policy? | 18:21 |
| lamont | but stopping the daemon is kinda critical | 18:21 |
| mathiaz | lamont: right - that is fixed in lucid now | 18:21 |
| mathiaz | lamont: hm - where in the policy is the user/group remove on package removal documented? | 18:24 |
| mathiaz | lamont: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2 deals with system users/groups | 18:24 |
| mathiaz | lamont: but doesn't refer to what should be done on package removal | 18:25 |
| persia | mathiaz: I'll suggest not removing the users/groups on package removal (which I've seen in a number of packages): this avoids the problem of potentially chowning files that are to be preserved, etc. | 18:26 |
| lamont | yeah - and I don't see it anywhere either | 18:26 |
| lamont | not removing is a good answer | 18:26 |
| persia | (plus it means end-users get the *same* uid/gid if they reinstall later) | 18:27 |
| lamont | postfix package removes the users and groups it created, many other packages don't | 18:27 |
| mathiaz | persia: right - not removing the user/group seems to safest option to me as well | 18:27 |
| mathiaz | lamont: do you need an SRU for karmic on the puppet bug? | 18:28 |
| persia | lamont: Do you happen to know why postfix does it that way? | 18:28 |
| mathiaz | lamont: or lucid is fine? | 18:28 |
| lamont | mathiaz: romantic notions of cleaning up after myself? | 18:28 |
| persia | OK. As long as there's a good reason :) | 18:29 |
| lamont | bind9 likewise - most likely I copied the bind behavior into postfix | 18:29 |
| lamont | mathiaz: ultimately, I'm certain it was "the standard reason": it seemed like a good idea, at the time | 18:29 |
| persia | Being tidy seems more defensible. | 18:30 |
| persia | lamont: On a completely different note: did my last comment to bug #67544 contain enough information, or is more useful? | 18:31 |
| ubottu | Launchpad bug 67544 in fpc "PPC build of fpc fails" [Unknown,Fix released] https://launchpad.net/bugs/67544 | 18:31 |
| persia | (not really Fix Released) | 18:32 |
| Keybuk | <grin> at bug #537248 | 18:37 |
| ubottu | Launchpad bug 537248 in plymouth "does not format usb flash" [Undecided,New] https://launchpad.net/bugs/537248 | 18:37 |
| Keybuk | most people think that Plymouth not formatting usb flash devices is a feature | 18:38 |
| Keybuk | filesystem corruption is about the only bad thing it *doesn't* do :p | 18:38 |
| mdeslaur | lol | 18:49 |
| zyga | does anyone know if it's possible to link PPA with a launchpad project somehow? | 18:59 |
| jpds | zyga: Try asking #launchpad. | 19:00 |
| slangasek | Keybuk: the line in src/main.c? | 19:20 |
| slangasek | Keybuk: that was: after fixing the proximate cause of bug #506717, plymouth would helpfully segfault | 19:20 |
| ubottu | Launchpad bug 506717 in plymouth "[Lucid] plymouth does not display when using nvidia drivers" [High,Fix released] https://launchpad.net/bugs/506717 | 19:21 |
| Keybuk | was the fix for 506717 the declining to show the script plugin thing? | 19:21 |
| alexmoldovan | Hello guys, I have a q: I am running apport and it asks me "Has this issue been confirmed to exist with the upstream kernel?". I don't know what this means, so I don't know what to answer. I would like to help, so I need to understand this. | 19:27 |
| bdrung | a package FTBFS in the archive, because a network test failed. i tried to reproduce it locally by disabling the network, but the package still builds. how can i reconstruct the buildd environment? | 19:30 |
| bdrung | i am talking about bug #521204 | 19:37 |
| ubottu | Launchpad bug 521204 in lucene2 "lucene2 2.9.1+ds1-5 fails to build from source" [Undecided,New] https://launchpad.net/bugs/521204 | 19:37 |
| kkszysiu | hello | 19:38 |
| kkszysiu | well anyone working to integrate somerhing like http://www.omgubuntu.co.uk/2010/03/easy-gui-window-button-switcher-for.html into gnome-appearance-properties ? | 19:39 |
| johnsgruber | Is there anything afoot to get plymouth to start gdm on a tty >=7 ? | 19:40 |
| slangasek | Keybuk: 506717> well, what I was fixing was that plymouth wouldn't fall back to the text plugin when script was selected | 19:49 |
| Keybuk | right | 19:51 |
| Keybuk | that's ok, it fits what I thought | 19:51 |
| === MacSlow|capoeira is now known as MacSlow | ||
| viyyer | hi kirkland there? | 19:56 |
| YokoZar | What component do I file this against? I've noticed that when I change from noveau to proprietary nvidia drivers my laptop stops working well with my docking station / monitor (have to manually tell it to switch displays and then manually change resolution) | 19:58 |
| YokoZar | Somehow it seems to me that's not entirely an nvidia mode setting thing, but I don't know too much about it | 19:58 |
| Keybuk | YokoZar: file it with your NVIDIA support contact? | 19:59 |
| YokoZar | so is it all a proprietary drivers thing? | 19:59 |
| YokoZar | *s/package/component, been filing too many bugs upstream lately | 20:00 |
| Keybuk | well, if it works with nouveau, and doesn't with nvidia-glx - it's a binary driver problem, no? | 20:00 |
| persia | Could file a bug against the nvidia-glx package, but it won't get fixed there unless it's fixed upstream. | 20:01 |
| YokoZar | Keybuk: Not necessarily, no. | 20:01 |
| YokoZar | In my experience usually X is involved in all unwanted resolution changes | 20:01 |
| viyyer | I wanted to try out testdrive . While installing apt-get gives an error. viyyer@Atri:~/Desktop/panel$ sudo apt-get install testdrive | 20:02 |
| viyyer | [sudo] password for viyyer: | 20:02 |
| viyyer | Reading package lists... Done | 20:02 |
| viyyer | Building dependency tree | 20:02 |
| viyyer | Reading state information... Done | 20:02 |
| viyyer | Some packages could not be installed. This may mean that you have | 20:02 |
| viyyer | requested an impossible situation or if you are using the unstable | 20:02 |
| viyyer | distribution that some required packages have not yet been created | 20:02 |
| viyyer | or been moved out of Incoming. | 20:02 |
| viyyer | The following information may help to resolve the situation: | 20:02 |
| YokoZar | spam | 20:02 |
| viyyer | The following packages have unmet dependencies: | 20:02 |
| viyyer | testdrive: Depends: cpu-checker but it is not installable | 20:02 |
| viyyer | E: Broken packages | 20:02 |
| viyyer | oops | 20:02 |
| persia | !paste | viyyer | 20:03 |
| ubottu | viyyer: For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. | 20:03 |
| tesuki | If I make a proprietary program could I get it into the standard repos? (a program that needs a license file and accepting of a license) | 20:03 |
| Keybuk | YokoZar: X *is* whatever driver you're using | 20:03 |
| Keybuk | there isn't much more to it than that, really | 20:03 |
| persia | tesuki: Depends on the license. If it can be distributed freely, but needs a license to use, it can be in multiverse, but you may have a hard time interesting developers in uploading it. | 20:04 |
| YokoZar | Keybuk: But X has multiple components, and not all are the drivers, hence the questions. I remember specifically having a resolution problem in the past that was an XRandR issue, for instance. | 20:05 |
| tesuki | If I make a deb (that I can install with dpkg -i name.deb) would it still be hard? Could money help? | 20:06 |
| YokoZar | If it's packaged right | 20:06 |
| persia | tesuki: making a .deb makes it impossible. It needs to be a source package. The sun-java6 package in jaunty is a good example of how that works. | 20:06 |
| YokoZar | ^^ what persia said | 20:07 |
| persia | tesuki: I believe Cannical offers a program where you can pay to have proprietary appls inthe partner archive. No idea on costs. | 20:07 |
| viyyer | kirkland, http://pastebin.ca/1834309 what package is cpu-checker ? | 20:07 |
| Keybuk | YokoZar: I don't think nvidia-glx *does* xrandr | 20:07 |
| Keybuk | YokoZar: it does mad TwinView crap | 20:07 |
| YokoZar | Keybuk: ahh ok, hence the problem. You've sated me. | 20:08 |
| YokoZar | viyyer: packages.ubuntu.com can answer that for you | 20:08 |
| viyyer | YokoZar, there is none | 20:09 |
| YokoZar | viyyer: change "karmic" to "lucid", it seems it's a new package | 20:10 |
| tesuki | persia: that program is namned? | 20:10 |
| YokoZar | regardless ubuntu-bug packagename will work even if it's a binary package name and not a source package name | 20:11 |
| \sh | tesuki: http://www.canonical.com/services/packaging <- canonical packaging service for partner apps | 20:11 |
| tesuki | \sh, persia thank you. | 20:12 |
| viyyer | YokoZar, the purpose of installing testdrive is to test out lucid. I don't want to install lucid right now | 20:13 |
| viyyer | YokoZar, testdrive allows one to test lucid on a VM | 20:13 |
| === Caesar_ is now known as Caesar | ||
| debfx | Adri2000: hi, I just noticed you filed a FFe to get blobby into lucid | 20:30 |
| debfx | I'm the debian maintainer and wanted to make it build-depend on the (just accepted) tinyxml package (instead of building its own copy) for the next upload | 20:31 |
| Adri2000 | debfx: hi | 20:34 |
| Adri2000 | debfx: hmm then in this case maybe we're going to sync the current blobby and not wait for your next upload... | 20:36 |
| Adri2000 | otherwise it would require another FFe for tinyxml | 20:36 |
| debfx | Adri2000: yes, I guess that's the best way as these architectures aren't supported by ubuntu anyway and chances that someone wants to play blobby on them are pretty low :) | 20:41 |
| === blueyed_ is now known as blueyed | ||
| === viyyer_ is now known as viyyer | ||
| Adri2000 | debfx: I've just added a comment about this in the FFe bug. thanks for notifying me of this. do you think you could wait a bit before uploading the new version in debian, until we've decided for sure what version we sync? (so if we choose -1, it will still be possible to "sync") | 20:55 |
| ccheney | what util does line ending conversion from dos to unix? | 20:58 |
| * ccheney can't find it with apropos | 20:58 | |
| cjwatson | fromdos | 20:58 |
| ccheney | cjwatson: thanks | 20:59 |
| genii | cjwatson: Isn't also dostou ? | 21:07 |
| kirkland | viyyer: hi, sorry about that ... I'm uploading cpu-checker to the ppa now | 21:13 |
| kirkland | viyyer: that was a recent change for lucid, forgot to backport until you reminded me :-) | 21:14 |
| viyyer | kirkland, thanks .. I think test drive is great idea. | 21:14 |
| viyyer | kirkland, when would you be able to upload the same ? | 21:15 |
| kirkland | viyyer: what do you mean? | 21:16 |
| kirkland | viyyer: https://edge.launchpad.net/~testdrive/+archive/ppa/+packages | 21:16 |
| kirkland | viyyer: the builds are queued, should be done in ~45 minutes | 21:16 |
| viyyer | kirkland, thanks :) | 21:16 |
| kirkland | viyyer: i'm also looking at the code, trying to remove (soften) the cpu-checker dependency | 21:17 |
| \sh | why does sun-java6-bin need libnss-mdns and therefore avahi-daemon? | 21:26 |
| kirkland | viyyer: okay, cool ... I just modified the code to use cpu-checker if there, but not depend on it; this should solve the issue much better :-) | 21:35 |
| kirkland | viyyer: i'm uploading to the PPA now | 21:36 |
| kirkland | viyyer: again, will build in a bit | 21:36 |
| mathiaz | kirkland: what is responsible for creating /dev/kvm? | 21:36 |
| kirkland | mathiaz: in lucid? /etc/init/qemu-kvm.conf | 21:36 |
| kirkland | mathiaz: <lucid, the init script | 21:37 |
| mathiaz | kirkland: on lucid, on an NC I get this: http://paste.ubuntu.com/393565/ | 21:37 |
| mathiaz | kirkland: that was *after* installing eucalyptus-nc as a package | 21:37 |
| kirkland | mathiaz: does /dev/kvm exist? | 21:37 |
| kirkland | mathiaz: lsmod | grep kvm | 21:37 |
| mathiaz | kirkland: hm - now yest | 21:38 |
| kirkland | mathiaz: ? | 21:38 |
| mathiaz | kirkland: because I manually modprobed kvm_intl | 21:38 |
| kirkland | mathiaz: pastebin your /etc/init/qemu-kvm.conf | 21:38 |
| kirkland | mathiaz: status qemu-kvm | 21:38 |
| slangasek | Keybuk: any idea what's causing these "plymouth not stopping at shutdown" bugs suddenly? | 21:38 |
| mathiaz | kirkland: http://paste.ubuntu.com/393569/ | 21:39 |
| kirkland | mathiaz: modprobe -r those two kvm modules | 21:40 |
| kirkland | mathiaz: and sudo start qemu-kvm | 21:40 |
| kirkland | mathiaz: make sure that that get's the module loaded correctly | 21:40 |
| mathiaz | kirkland: is qemu-kvm started by the postinst? | 21:40 |
| kirkland | mathiaz: hmm | 21:40 |
| mathiaz | kirkland: I haven't rebooted the NC after the eucalyptus-nc package has been installed | 21:41 |
| kirkland | mathiaz: i'm not sure, actually | 21:41 |
| kirkland | mathiaz: let me check | 21:41 |
| slangasek | Keybuk: ah, an apport change | 21:41 |
| kirkland | mathiaz: oh, one more thing ... dpkg -S /etc/init/qemu-kvm.conf | 21:41 |
| slangasek | pitti: this new "unkillable_shutdown" hook is broken | 21:42 |
| mathiaz | kirkland: according to /var/lib/dpkg/info/qemu-kvm.postinst there is nothing that start qemu-kvm in there | 21:42 |
| kirkland | mathiaz: yeah, i agree | 21:42 |
| mathiaz | kirkland: qemu-kvm is the package shipping /etc/init/qemu-kvm.conf | 21:42 |
| kirkland | mathiaz: cool ... so just a "start qemu-kvm | true" toward the end of that? | 21:43 |
| mathiaz | kirkland: how do you install the qemu-kvm upstart job? | 21:43 |
| mathiaz | kirkland: with dh_installinit? | 21:43 |
| kirkland | dh_installinit -s --no-restart-on-upgrade --error-handler=true --noscripts | 21:43 |
| kirkland | hmm | 21:43 |
| kirkland | mathiaz: oh, i think the --noscripts is breaking me | 21:44 |
| mathiaz | kirkland: yeah - probably | 21:45 |
| mathiaz | kirkland: should I report a bug? | 21:45 |
| slangasek | pitti: specifically, it's reporting plymouth as unkillable (bug #537248 et al.) | 21:46 |
| ubottu | Launchpad bug 537248 in plymouth "does not format usb flash" [Undecided,New] https://launchpad.net/bugs/537248 | 21:46 |
| kirkland | mathiaz: yes, please | 21:46 |
| kirkland | mathiaz: i'm fixing it now | 21:46 |
| kirkland | mathiaz: i'd like a bug to reference | 21:46 |
| mathiaz | kirkland: bug 537682 | 21:47 |
| ubottu | Launchpad bug 537682 in qemu-kvm "qemu/kvm not started after package install" [Undecided,New] https://launchpad.net/bugs/537682 | 21:47 |
| kirkland | mathiaz: thanks | 21:47 |
| cjwatson | genii: it's the sort of thing that is sufficiently easy to write that many people have written it. I don't know that enumerating all the versions of it is useful :-) | 21:55 |
| mdz | say, why does my system slow to a crawl with disk I/O whenever apparmor is upgraded and reloads its profiles? | 21:55 |
| cjwatson | hey, I noticed that too, had been meaning to report it | 21:55 |
| jdstrand | it regenerating its cached files | 21:56 |
| jdstrand | cached profiles | 21:56 |
| jdstrand | we now have binary blobs that load super fast on boot rather than having to generate them on the fly | 21:57 |
| jdstrand | that helps with boot times, but slows down install a bit | 21:57 |
| cjwatson | it absolutely hammers my laptop on upgrade | 21:57 |
| jdstrand | the system shouldn't slow to a crawl though... | 21:58 |
| cjwatson | is it trying to massively parallelise the caching or something? | 21:58 |
| jdstrand | I'm not sure-- jjohansen is the one to ask | 21:58 |
| jdstrand | (or possibly kees, if he did something in packaging that would affec it) | 21:58 |
| jjohansen | cjwatson: no | 21:59 |
| * sebner waves at jdstrand and reminds him of moin | 21:59 | |
| jjohansen | cjwatson: its single threaded, compiling the policy can hit the cpu pretty hard though | 21:59 |
| cjwatson | from what I very vaguely recall, the load seemed to be in a kernel thread, but I couldn't look closely because I couldn't do very much :-) | 21:59 |
| cjwatson | so that might be bogus data | 21:59 |
| jdstrand | sebner: don't need to remind-- I've pretty much only been working on it this week :) | 22:00 |
| cjwatson | jjohansen: if it's just that, then maybe nice(1) would be in order | 22:00 |
| jdstrand | sebner: I need to get the stable releases out, then I'll review your debdiff | 22:00 |
| jjohansen | cjwatson: sure that could be done | 22:00 |
| sebner | jdstrand: aye aye, just thought you might have forgotten it :) | 22:00 |
| kees | cjwatson: yes, it uses all available CPUs when generating the caches | 22:02 |
| kees | cjwatson: using "nice" would defeat the purpose of loading it as fast as possible, though? | 22:03 |
| jjohansen | hrmmm, thats right kees parallelized it launch multiple compiles | 22:03 |
| jjohansen | I had forgotten that | 22:03 |
| * kees nods | 22:03 | |
| jjohansen | the compile is itself single threaded | 22:04 |
| kees | right | 22:04 |
| micahg | didrocks: could I get you to test your firefox LP bug in the upstream build as well? | 22:05 |
| jdstrand | maybe 1 - N-1 would be the way to go | 22:05 |
| jdstrand | kees: ^ | 22:05 |
| kees | well, the actual issue was mdz claiming heavy disk I/O, which is unrelated to the parallelization, I would imagine. | 22:05 |
| jdstrand | true | 22:06 |
| jjohansen | it does very little disk I/O | 22:06 |
| mdz | jdstrand, it really hammers my system, to the point where the desktop is unresponsive | 22:07 |
| cjwatson | kees: ^- indeed, I'm seeing the same thing as mdz. "as fast as possible" becomes counterproductive at that point | 22:08 |
| cjwatson | it wasn't directly clear to me whether it was disk I/O or something else - unresponsiveness was the main symptom | 22:08 |
| mdz | xargs -n1 -P$(getconf _NPROCESSORS_ONLN) "$PARSER" "$@" -- | 22:08 |
| mdz | kees, is that what you're referring to? | 22:09 |
| cjwatson | I think I may have been getting some kind of disk thrashing as a second-order effect | 22:09 |
| directhex | okay, am i the only one experiencing weirdness when gdb appears? if i hit enter to select myself from the user list, gdm seems to die & restart | 22:09 |
| directhex | the second time, it's fine. just buggered post-boot | 22:09 |
| RAOF | directhex: No, you're far from the only one. | 22:10 |
| mdz | /etc/init.d/apparmor reload with a hot cache is reasonably sane | 22:11 |
| RAOF | directhex: That's plymouth being evil. | 22:11 |
| kees | mdz: yup, that's the parallelization | 22:11 |
| sbeattie | mdz|cjwatson: are you guys near memory limits where non-trivial amounts of memory consumption might cause swapping to occur? | 22:12 |
| cjwatson | sbeattie: nowhere close | 22:12 |
| kees | mdz: seb128 has been complaining about how long some of the reloads were taking when doing package installs, so we pulled out the stops to speed it up. | 22:12 |
| mdz | sbeattie, nope | 22:12 |
| kees | I guess we could nice it. | 22:13 |
| cjwatson | even with two kvm instances running (which I didn't at the time), I have over 1GB free | 22:13 |
| kees | seems weird to me. | 22:13 |
| mdz | 4.72user 0.15system 0:03.63elapsed 133%CPU (0avgtext+0avgdata 141552maxresident)k | 22:13 |
| mdz | 0inputs+1528outputs (0major+40010minor)pagefaults 0swaps | 22:13 |
| cjwatson | kees: or use only up to n-1 processors if n > 1 | 22:13 |
| cjwatson | perhaps | 22:13 |
| mdz | kees, what does apparmor_parser do? | 22:14 |
| kees | I wonder if xargs correctly handles -P0 ... | 22:14 |
| cjwatson | -P0 means "run as many as possible" per the man page | 22:14 |
| cjwatson | equivalent of make -j | 22:14 |
| kees | cjwatson: eek | 22:14 |
| ion | mdz, cjwatson: I take it it’s not bug #458299 you’re encountering, though? | 22:14 |
| ubottu | Launchpad bug 458299 in linux "apparmor_parser: page allocation failure. order:5" [Medium,Confirmed] https://launchpad.net/bugs/458299 | 22:14 |
| kees | mdz: it builds the kernel rules for apparmor from the text file rules | 22:14 |
| mdz | ion, I don't see that message, no | 22:14 |
| mdz | kees, right, but what sort of system calls does that involve? | 22:15 |
| kees | mdz: i.e. parses them into the binary DFA that the kernel uses for following AA rules | 22:15 |
| mdz | why should it be so I/O intensive? | 22:15 |
| cjwatson | ion: hmm, I do have one of those in my logs | 22:15 |
| cjwatson | so perhaps mdz and I have different problems | 22:15 |
| kees | mdz: it just uses open read write. the files are relatively small. | 22:15 |
| mdz | kees, something else is going on here, then | 22:15 |
| kees | mdz: what does du -sh /etc/apparmor.d/cache say ? | 22:15 |
| mdz | kees, there are only 1.1MB of files in /etc/apparmor.d in total | 22:16 |
| mdz | that doesn't even come close to explaining the behavior I' see | 22:16 |
| kees | mdz: yup, sounds about right | 22:16 |
| ion | cjwatson: The symptoms of that issue seem be something in kernel space constantly allocating all free memory in an infinite loop, making the system unusably slow. | 22:16 |
| mdz | kees, what happens to running processes when those are reloaded? | 22:16 |
| cjwatson | ion: that sounds plausible | 22:16 |
| mdz | kees, is it possible that it's paging in a lot of stuff? | 22:17 |
| kees | mdz: do you mean "how are the AA protections for the processes handled?" they are atomically swapped for the new profiles once they're loaded. | 22:17 |
| kees | jjohansen: ^^ is it possible the kernel is hauling in lots of memory to attach/swap the profiles? | 22:18 |
| mdz | kees, does that involve touching more than a trivial amount of process memory? | 22:18 |
| kees | mdz: if that were the case, I would assume a standard hot-cache "sudo service apparmor reload" would show the same problem. | 22:18 |
| mdz | kees, except that it's all paged in | 22:18 |
| mdz | I have plenty of RAM | 22:19 |
| jjohansen | well it pulls in some memory dependent on what the policy is but trivial on todays machines 2-4 MB | 22:19 |
| kees | mdz: the blobs in /etc/apparmor.d/cache are what is being loaded in the kernel, so that's the extent of the kernel memory. the userspace parser uses more memory than that when parsing, but it's not huge. | 22:19 |
| ion | Cache in /etc? Eww. :-) | 22:19 |
| jjohansen | userspace compilation does get large | 22:19 |
| kees | ion: :) | 22:20 |
| mdz | jjohansen, so you think it's apparmor_parser itself which is the likely culprit? | 22:20 |
| jjohansen | yes | 22:20 |
| jjohansen | mdz: we can experiment with running this without doing the actual kernel load | 22:21 |
| jjohansen | vs. just loading from prebuilt cache | 22:22 |
| === jono_ is now known as jono | ||
| slangasek | Keybuk: so I'm getting casper-md5check to talk to plymouth; is there any sort of distinction in plymouth between displaying errors vs. high-prio text vs. normal text? I don't see anything along those lines in the API | 22:38 |
| Keybuk | no | 22:39 |
| slangasek | ok | 22:39 |
| Keybuk | we can add things like that | 22:40 |
| Keybuk | there are two types of message our theme supports | 22:40 |
| Keybuk | generic blah blah types like "Checking your disks" | 22:40 |
| Keybuk | and beneath that, a message about what keys you can press | 22:40 |
| Keybuk | "Press C to cancel" etc. | 22:40 |
| slangasek | well, this certainly doesn't seem like something that should be added into a theme if there's no protocol-level distinction | 22:41 |
| Keybuk | I think you misunderstand me | 22:42 |
| Keybuk | this kind of thing, in plymouth, is deliberately left up to the theme | 22:42 |
| Keybuk | plymouth provides basic ways to communicate with the theme | 22:42 |
| Keybuk | and you build from there | 22:42 |
| Keybuk | that's how our fsck progress works, for example | 22:42 |
| slangasek | I don't think I misunderstand you, I think I disagree with you that this is a reasonable design :) | 22:43 |
| Keybuk | really, why? | 22:44 |
| Keybuk | plymouth is just a plugin architecture for dealing with displays really | 22:44 |
| Keybuk | where the most common use is to make splash screens | 22:44 |
| persia | Keybuk: So if I get text overlaying an entry box during boot, that's a plymouth bug, or a theme bug? | 22:44 |
| Keybuk | persia: theme bug | 22:44 |
| persia | Thanks. | 22:44 |
| Keybuk | relevant aside: there's new gdm, mountall + plymouth packages in my PPA | 22:45 |
| Keybuk | would appreciate testing | 22:45 |
| slangasek | Keybuk: that the client and the theme have a private agreement for the meaning of the text strings? Yes, I think that's a bad design | 22:45 |
| slangasek | it means anyone who wants to use a different theme gets weird handling of the annotated strings the client is sending | 22:47 |
| Keybuk | though that being said, I never really got how some text can be "urgent" and some can't be | 22:47 |
| Keybuk | slangasek: but in plymouth, switching a plugin can be switching from a splash screen to a login screen to an OS switcher, etc. | 22:48 |
| slangasek | plugin, or theme? | 22:48 |
| slangasek | none of the themes shipped here seem to be login screens or OS switchers | 22:49 |
| Keybuk | plugins and themes are the same thing | 22:49 |
| Keybuk | slangasek: half the themes in plymouth don't even support message ;-) | 22:49 |
| slangasek | well - that's better than having them support it and wind up with "keys:" prepended? :) | 22:50 |
| Keybuk | *shrug* | 22:50 |
| Keybuk | the alternative is that you put a massive burden on theme authors to support dozens of commands that they might not care about | 22:50 |
| slangasek | I half think that if a theme isn't going to behave sensibly with mountall, we shouldn't ship that theme by default | 22:51 |
| slangasek | dump it in plymouth-bad-for-ubuntu or something :) | 22:51 |
| Keybuk | I don't disagree :p | 22:51 |
| Keybuk | splitting the themes out is on the todo | 22:51 |
| Keybuk | that being said, I did make the text theme work with mountall ;) | 22:51 |
| slangasek | ok | 22:52 |
| ion | Nice | 22:52 |
| === jono_ is now known as jono | ||
| ion | (add-apt-repository ppa:scott) | 22:53 |
| === robbiew is now known as robbiew_ | ||
| === sconklin is now known as sconklin-gone | ||
| ion | keybuk: Worksforme™ | 23:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
