| === beuno_ is now known as beuno | ||
| Viper550 | I know this has to do more with Ark and RPM than Debian, but bero did a write-up on package management. http://arklinux.wordpress.com/2009/06/02/another-look-at-linux-packaging-systems/ | 00:44 |
|---|---|---|
| YokoZar | slangasek: I recall you taking notes during this spec: https://blueprints.launchpad.net/ubuntu/+spec/desktop-mime-execution-policy -- did you paste them somewhere? there's no link at that page | 01:02 |
| bluefoxicy | holy crap | 01:39 |
| bluefoxicy | a kernelu pdate fixed busted GTK file picker? | 01:39 |
| YokoZar | bluefoxicy: what kind of busted? | 01:45 |
| YokoZar | GTK file picker was busted for other reasons... | 01:46 |
| === cody-somerville_ is now known as cody-somerville | ||
| slangasek | YokoZar: they're still in gobby | 02:57 |
| YokoZar | slangasek: ahh good, thanks | 02:58 |
| YokoZar | I'll make a wiki page | 02:58 |
| === mcasadevall is now known as NCommander | ||
| === fabbione is now known as fabb-rome | ||
| dholbach | good morning | 06:57 |
| pitti | Good morning | 07:10 |
| pitti | bryce: get well soon! didn't hit me too hard, just a cold, but fortunately it was Pentecost yesterday anyway :) | 07:11 |
| TheMuso | Hey pitti. | 07:16 |
| pitti | hey TheMuso, made it back in one piece? | 07:26 |
| TheMuso | pitti: Indeed. Long flight, but after a good night sleep, I feel much better. | 07:27 |
| === asac_ is now known as asac | ||
| soren | How do I find the version of the running system from a python script? Parsing /etc/lsb-release? | 08:24 |
| dholbach | soren: run "lsb_release -rs" and parse the output? :) | 08:26 |
| geofft | hm, /usr/bin/lsb_release is Python, and looks to do if __name__=='__main__' correctly. You could import it! | 08:26 |
| soren | I don't think I'll be adding /usr/bin to my sys.path, though. :) | 08:27 |
| soren | That seems like a recipe for disaster. | 08:27 |
| ajmitch | "perfectly safe" | 08:28 |
| juanje | soren: why don't you just use the function get_lsb_information() from the lsb_release? It's small and give you all you need | 08:34 |
| === azeem_ is now known as azeem | ||
| === tkamppeter_ is now known as tkamppeter | ||
| juanje | soren: I meant to copy the function, instead of import the script | 08:37 |
| pitti | copying code would defeat the idea of lsb_release | 08:39 |
| pitti | e. g. it wouldn't work on Debian | 08:39 |
| soren | pitti: How do you do it from apport? Parse the output from lsb_release? | 08:39 |
| pitti | lsb_release is supposed to be executed, not sourced/copied/imported, so the only safe way is to call it | 08:39 |
| pitti | soren: yes | 08:39 |
| soren | Cool, thanks. | 08:40 |
| pitti | soren: so if you care for portability, run lsb_release; if you don't, just read /etc/lsb-release | 08:40 |
| pitti | (the latter is magnitudes faster, of course) | 08:40 |
| soren | Portability isn't a great concern, but speed even less so :) | 08:41 |
| Lutin | Riddell: ping about eet | 08:44 |
| jamesh | soren: if you want speed, reimplement lsb-release in C :) | 08:49 |
| jamesh | lsb_release, even | 08:49 |
| * soren passes on that opportunity | 08:49 | |
| juanje | pitti: maybe, but probably the best is not to have to run the lsb_release, but have it as a lib, so you can use from python easily | 08:50 |
| pitti | smb: jaunty-proposed queue has l-r-m which "Bump ABI to 13 for proposed kernel"; however, there is no -13 in jaunty-proposed | 08:51 |
| smb | pitti, Let me check. I thought I had uploaded all three during uds | 08:51 |
| pitti | juanje: agreed, but that needs to be defined in LSB then | 08:51 |
| pitti | smb: there was a linux upload which reverts a previous change which introduced a regression | 08:51 |
| pitti | smb: ah, indeed: http://launchpadlibrarian.net/27192879/linux_2.6.28-13.44_source.changes | 08:52 |
| pitti | smb: that bumps the ABI | 08:52 |
| pitti | smb: (ugh) | 08:52 |
| smb | pitti, yeah that bump the abi again for the remove | 08:52 |
| pitti | smb: ok, nevermind then | 08:52 |
| jamesh | soren: feel free to pick another language that results in a fast to load binary | 08:52 |
| smb | pitti, Ok, yeah sorry about that. The sound changes required another one | 08:53 |
| smb | pitti, I'll follow up with meta in a bit | 08:54 |
| pitti | smb: ok, thanks | 08:54 |
| Riddell | Lutin: hi | 09:01 |
| Lutin | heya Riddell | 09:02 |
| Lutin | Riddell: I was curious about why you reverted eet to an older version with a 'new upstream version" changelog entry | 09:02 |
| Riddell | Lutin: let me work out where I got that from | 09:06 |
| Riddell | Lutin: it's from http://dev.openbossa.org/trac/qedje/ | 09:08 |
| Lutin | Riddell: well, qedje uses eet 1.1.0 in Debian and I haven't seen any bugreport so far | 09:10 |
| Riddell | mm, and I'm pretty sure that page is out of date | 09:10 |
| Lutin | (sure, the version in ubuntu was rev365xx) | 09:11 |
| Lutin | Riddell: anyway, no big deal, just wanted to point it out | 09:15 |
| Riddell | it's also linked on http://code.openbossa.org/projects/qedje/pages/Home | 09:15 |
| Riddell | which is the new qedje page | 09:15 |
| Lutin | Riddell: maybe they needed some bugfixe that happened right before, ot they just picked whatever SVN rev was at that time | 09:21 |
| Lutin | anyway the interface sure didn't change | 09:21 |
| Riddell | Lutin: there's also an eet 1.2 | 09:26 |
| Lutin | Riddell: I know, I actually uploaded it to experimental | 09:27 |
| Lutin | but it depends on libeina, and I'd rather not have it in ubuntu unless there's a very valid reason for it | 09:28 |
| Riddell | oh aye, I remember that now | 09:28 |
| Riddell | now I just need to remember why I thought the 1.1 wasn't good enough :) | 09:28 |
| Lutin | Riddell: you know you uploaded an /older/ version than 1.1, don't you ? | 09:29 |
| Riddell | Lutin: well presumably I didn't at the time and I must have thought it was newer | 09:36 |
| === korn_ is now known as c_korn | ||
| Riddell | Lutin: where can I find the svn revision of 1.1? | 09:53 |
| Keybuk | thought of the day: PPAs have killed Backports | 09:53 |
| lifeless | hallelujah? | 09:53 |
| directhex | PPAs don't require paperwork | 09:54 |
| Riddell | PPAs don't have a build score of 0 | 09:54 |
| directhex | build scores of 0 don't require paperwork | 09:54 |
| Lutin | Riddell: by checking out the svn and having with svn log, or you can look at the git-svn-id associated to the upstream-vcs/1.1.0 tag here: http://git.debian.org/?p=pkg-e/libs/eet.git;a=tags | 10:05 |
| === masACC is now known as maswan | ||
| === agateau_ is now known as agateau | ||
| lifeless | anyone up for some sponsoring?https://bugs.edge.launchpad.net/ubuntu/+source/pyrex/+bug/379754 | 10:33 |
| ubottu | Ubuntu bug 379754 in pyrex "deprecation warning in Errors.py" [Undecided,In progress] | 10:33 |
| StevenK | lifeless: I'd rather a debdiff | 10:39 |
| lifeless | StevenK: done | 10:40 |
| === emgent_ is now known as emgent | ||
| Riddell | Lutin: I uploaded 1.1.0 again | 10:56 |
| Lutin | Riddell: cool, thanks | 10:58 |
| ogra | cjwatson, poke, could you merge https://code.launchpad.net/~ogra/debian-cd/ubuntu so we get armel images again ? | 11:11 |
| cjwatson | ogra: done, and rolled out | 11:14 |
| ogra | thanks | 11:14 |
| ogra | do we really need the version check in there ? | 11:14 |
| ogra | i would think we can just trust what lies in /srv/cdimage.ubuntu.com/ftp-ports/dists/karmic/main/installer-armel/current/images/imx51/cdrom/ | 11:15 |
| cjwatson | needs to be fixed properly with a kernel change | 11:15 |
| cjwatson | it's not about trust | 11:15 |
| ogra | indeed, but until thats there we'll have to bump the version for every ABI change | 11:16 |
| cjwatson | yes. | 11:16 |
| ogra | and given that the babbage2 patches will take some time to be sorted that might be a longer period | 11:16 |
| cjwatson | incentive to get it fixed properly ... | 11:16 |
| loic-m | ogra: hi | 11:17 |
| seb128 | does anybody known an easy way to replace a new line by a space? ie to change a file having a name by line to a "name1 name2 name3" etc, cat file | something | 11:18 |
| seb128 | tr -d '\n' deletes the new line but it lacks space between words | 11:18 |
| StevenK | seb128: tr '\n' ' ' | 11:18 |
| ogra | loic-m, hey, the ubuntu-gettext domain changes in tuxtype were to please the langpack generation, i think they are still needed | 11:18 |
| seb128 | StevenK: ok, I was not far, thanks | 11:18 |
| cjwatson | seb128: xargs | 11:19 |
| loic-m | ogra: which langpack generation? I thought it was because the package was in main, and thus translated in Launchpad? | 11:19 |
| cjwatson | (slightly creative option, but it's what I usually do for that task) | 11:19 |
| cjwatson | though it does go wrong if the file has too many lines | 11:19 |
| ogra | loic-m, right and it gets automatically picked up for langpacks through being in main | 11:19 |
| loic-m | ogra: then what about tuxmath, who's also in main? | 11:20 |
| ogra | same thing ... if that setting is missing thats a bug | 11:20 |
| loic-m | ogra: I'm in touch with upstream, so I can ask them to put it (they already do something for Suse) | 11:20 |
| ogra | good, make them do it and we can sync | 11:21 |
| loic-m | ogra: Ok, now I can tell them about both .desktop files and we can sync | 11:21 |
| ogra | when i maintained it the package had only a debian .menu file iirc (its quite a while ago) | 11:21 |
| seb128 | StevenK, cjwatson: thanks | 11:21 |
| loic-m | ogra: we'll have to wait for tuxtype > 1.7.4 though, Debian still isn't using upstream .desktop file | 11:21 |
| ogra | right, that was the prob i had back then as well | 11:22 |
| loic-m | ogra: yes, I fixed the bug in U and contacted the DD | 11:22 |
| loic-m | ogra: (before they didn't have a .desktop file) | 11:22 |
| ogra | thanks for getting it sorted :) | 11:22 |
| loic-m | ogra: thanks a lot | 11:22 |
| ogra | the edubuntu guys will be happy to have less work | 11:23 |
| loic-m | ogra: you're welcome. I was afraid you'd have forgotten about it, since nobody on #u-edu could tell me about the string | 11:23 |
| loic-m | ogra: so direct contacting you was a good thing ;) | 11:23 |
| ogra | to be honest i *had* forgotten about it ... | 11:23 |
| ogra | its 1.5 years ago that i touched my last edu package actively | 11:24 |
| ogra | though i probably did a dumb merge inbetween when LaserJock had no time | 11:24 |
| StevenK | pitti: http://people.ubuntu.com/~ubuntu-archive/NBS/ is empty, and I don't believe it, could you check? | 11:34 |
| pitti | StevenK: I wish! | 11:36 |
| pitti | give me a minute | 11:36 |
| lifeless | StevenK: so, was the debdiff ok? | 11:38 |
| StevenK | lifeless: *cough* Got distracted | 11:38 |
| Hobbsee | kirkland: in my "what was known as screen profiles", i've got a "49m". What does it stand for? :) | 11:45 |
| Hobbsee | is it hte remaining time of my dist-upgrade, or something? | 11:45 |
| Hobbsee | oh, uptime. never mind. | 11:46 |
| pitti | StevenK: archive-cruft-check.py -n /srv/launchpad.net/ubuntu-archive/ | 11:46 |
| pitti | ImportError: No module named ftpmaster | 11:46 |
| pitti | cprov: ^ can you please look at this? | 11:46 |
| StevenK | \o/ | 11:46 |
| lifeless | StevenK: so, how do I go about undistracting you? | 11:51 |
| === ScriptRipper_ is now known as ScriptRipper | ||
| StevenK | lifeless: Visit? | 11:51 |
| lifeless | mm, not still I'm less sinusy | 11:51 |
| lifeless | I'll settle for nagging | 11:51 |
| * lifeless nags StevenK | 11:52 | |
| pitti | asac: shall I drop the modem fdi from hal-info for karmic, for better testing of the prober? | 11:54 |
| asac | pitti: i would say no. the prober is always used anyway and there are other things like modemmanager and wader that still rely on that info. i will talk to dan if we can drop the code pieces that do something with hal | 11:56 |
| asac | (to get even more testing of prober) | 11:57 |
| pitti | asac: ah, I see; so it's not necessary for NM? | 11:57 |
| pitti | asac: roger, thanks | 11:57 |
| slytherin | if a package was in depwait in jaunty on a particular arch (hppa) and the depwait is now cleared in karmic, what is the best way to make the buildd try the package again? | 12:11 |
| pitti | slytherin: hppa is no more in karmic | 12:13 |
| slytherin | pitti: I thought since FTBFS page shows hppa, it was still a community supported architecture. Also doko made some hppa specific uploads to java tool chain. | 12:14 |
| pitti | slytherin, doko: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-May/000571.html | 12:15 |
| slytherin | pitti: thanks | 12:17 |
| StevenK | pitti: Except it is still building stuff | 12:23 |
| slytherin | One more question. Is there any problem with powerpc buildd? I am trying to analyse FTBFS of tuxguitar - http://launchpadlibrarian.net/27258462/buildlog_ubuntu-karmic-powerpc.tuxguitar_1.1-1_FAILEDTOBUILD.txt.gz | 12:34 |
| cjwatson | slytherin: that does seem to be powerpc-specific but the cause is very unclear. I was just getting started on looking at that one ... | 12:37 |
| cjwatson | (bug 372243; please don't add any more tasks to that bug!) | 12:38 |
| ubottu | Launchpad bug 372243 in texlive-base "FTBFS of other packages due to dpkg-trigger bug in texlive-base" [Undecided,Confirmed] https://launchpad.net/bugs/372243 | 12:38 |
| cjwatson | I don't think texlive-base itself is likely to be the buggy thing, but it's hard to tell at the moment | 12:38 |
| slytherin | cjwatson: Thanks. I am subscribing myself to that bug. | 12:39 |
| cjwatson | I also find that in general betting *against* a bug being buildd-specific is wise | 12:40 |
| slytherin | cjwatson: I will try to build tuxguitar locally on a powerpc machine and will see if that still fails for same reason. | 12:41 |
| cjwatson | oh, I'm not asserting that it will necessarily fail in all cases; just that people are typically too quick to think "oh, must be a buildd bug" | 12:42 |
| slytherin | cjwatson: right. I will make sure first. | 12:43 |
| cjwatson | the code in both texlive-base and dpkg looks correct on the face of it | 12:43 |
| cjwatson | dpkg's source has not changed relevantly since jaunty, and I believe this bug is new in karmic | 12:44 |
| cjwatson | it might well be one of those things you can only reproduce if you're running an old kernel (say, dapper's) | 12:44 |
| cprov | pitti: yes, I'm on it. | 12:45 |
| pitti | cprov: cool, thanks | 12:45 |
| kirkland | Hobbsee: uptime :-) | 12:47 |
| kirkland | Hobbsee: cheers ;-) | 12:47 |
| cprov | pitti: fixed. | 12:50 |
| pitti | cprov: you rock | 12:50 |
| infinity | cjwatson: Seems like an odd thing to be triggered by kernel/userspace skew, but certainly possible, given that PPC is the only arch still running dapper kernels. :/ | 12:51 |
| pitti | StevenK: cron.NBS running | 12:51 |
| cprov | pitti: I wish ;) | 12:51 |
| StevenK | pitti: Danke | 12:51 |
| infinity | cjwatson: (And that's my two cents before I go back to not being here) | 12:51 |
| * ogra shakes his head | 12:53 | |
| ogra | infinity, go away ! | 12:53 |
| cjwatson | infinity: yeah, I don't get it yet | 12:55 |
| siretart | TB meeting today? | 13:04 |
| Hobbsee | karmic doesn't explode after dist-upgrade. Please fix it! | 13:13 |
| ogra | Hobbsee, i noticed that too yesterday ... | 13:15 |
| ogra | we should do some broken uploads | 13:15 |
| Hobbsee | heh :) | 13:15 |
| Hobbsee | the only thing i'm not liking so much is that konversation has a new version, which is kde4-based. That's not good enough! | 13:16 |
| ogra | bump it to kde5 and break it heavily :) | 13:16 |
| Hobbsee | haha | 13:16 |
| Riddell | what's wrong with it? | 13:16 |
| Hobbsee | nothing, apart from me not being sold on the aesthetics of it. (how does one change kde4 themes, without having the rest of it installed?) | 13:17 |
| Hobbsee | and the artefacts | 13:17 |
| lifeless | Hobbsee: willpower | 13:17 |
| ogra | lifeless, dont you need persia's cool brain input device for that ? | 13:18 |
| tkamppeter | pitti, hi | 13:19 |
| Hobbsee | lifeless: heh :) | 13:20 |
| cjwatson | siretart: yes, 1400 UTC | 13:21 |
| kirkland | Keybuk: ping | 13:22 |
| ion_ | ogra: OCZ NIA? :-) | 13:23 |
| ogra | something similar, yes | 13:24 |
| siretart` | cjwatson: ok. btw, I'm a bit unsure why ffmpeg is again on the meeting agenda. If I remember the meeting logs correctly, mdz wanted to confirm the course of action with sabdfl, but either that didn't happen or there were no objections. Do you know if there is actually something to discuss on that topic? | 13:24 |
| ogra | he had it with him at UDS and demoed it | 13:24 |
| ion_ | ogra: Is there Linux support for such devices? | 13:25 |
| ogra | i think it did something with plain xinput | 13:25 |
| cjwatson | siretart`: it's on the agenda because we don't typically remove things from the agenda until they're actually done | 13:25 |
| cjwatson | otherwise we forget about them entirely | 13:26 |
| siretart` | ah, I see | 13:26 |
| Keybuk | kirkland: hi | 13:26 |
| siretart` | mdz: did you catch sabdfl to confirm the course of action wrt ffmpeg? | 13:26 |
| cjwatson | siretart`: I haven't heard of any concrete progress but it would do no harm to poke people again; unless you're going to be around anyway, I don't know that you need to make any special effort to be there | 13:26 |
| siretart` | okay, because I'd need to leave around 14 UTC here :-/ | 13:27 |
| kirkland | Keybuk: hey, just filed a wishlist bug against upstart, inotify dir watching | 13:34 |
| kirkland | Keybuk: ideally, i'll get bugmail from LP when that gets fixed :-) | 13:35 |
| Daviey | Bug Status, "You wish it, you fix it" :) | 13:36 |
| mdz | siretart`: I haven't spoken to him about it recently, but he is here and will be at the meeting | 13:36 |
| mdz | siretart`: if there's nothing to discuss, we can skip it. is it resolved? | 13:37 |
| siretart` | mdz: IIRC, you wanted to check with sabdfl if what we discussed (not munging the ffmpeg source anymore) was OK and if yes, to proceed so in karmic | 13:37 |
| siretart` | I'm unsure if we discussed enabling the encoders, but TBH, the more interesting ones are in the multiverse package anyways.. | 13:38 |
| mdz | siretart`: I was pretty sure we resolved that in a meeting, that munging the source was unnecessary | 13:38 |
| siretart` | though h263 would certainly be interesting to users of ekiga | 13:38 |
| StevenK | pitti: Is cron.NBS running still, or did it die a horrid death? | 13:40 |
| lifeless | StevenK: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-doc-utils/+bug/336882 too :) | 13:41 |
| ubottu | Ubuntu bug 336882 in gnome-doc-utils "Deprecated module md5 with python 2.6" [Low,In progress] | 13:41 |
| lifeless | StevenK: just upload, you know you want to | 13:41 |
| StevenK | lifeless: Maybe applying for core-dev would be quicker | 13:42 |
| * StevenK hides | 13:42 | |
| lifeless | StevenK: when people start whinging at me to do that, sure. | 13:42 |
| StevenK | lifeless: I'll upload pyrex, subscribe the relevant sponsor team for the gnome-doc-utils bug | 13:46 |
| lifeless | StevenK: isn't it just ubuntu-main-sponsors? its what I already subscribed | 13:46 |
| StevenK | lifeless: It is, yes. I haven't looked. | 13:47 |
| mterry | james_w: Is --install-layout=deb still needed for python packages? Building a deb without it seems to do the right thing in Karmic. | 13:52 |
| lifeless | mterry: check closely, site-packages != dist-packages, and also python-support does evil magic that can in principle break | 13:53 |
| mterry | lifeless: Modules get installed to /usr/lib/python2.6/dist-packages | 13:53 |
| mterry | lifeless: I believe that's correct | 13:53 |
| lifeless | mterry: I suspect python-support is moving from site->dist, I may be wrong. | 13:54 |
| lifeless | but I certainly saw something like that in pyrex | 13:54 |
| mterry | lifeless: So you're saying that python-support will shortly (or apparently already does) do the right thing without --install-layout=deb? | 13:54 |
| mterry | lifeless: i.e. what I'm seeing is expected and good and loverly? | 13:55 |
| lifeless | mterry: If I am remembering what I observed. | 13:55 |
| mterry | lifeless: Alright, I love it | 13:55 |
| lifeless | mterry: I think its wrong, because if the build process is encoding paths into the output files, python-support will be breaking things. | 13:55 |
| lifeless | admittedly thats a corner case ;) | 13:56 |
| pitti | StevenK: still running, seems to be a lot | 14:03 |
| pitti | StevenK: hah, just finished | 14:03 |
| pitti | StevenK: http://people.ubuntu.com/~ubuntu-archive/NBS/ looks good now, enjoy | 14:04 |
| StevenK | pitti: Right, so I just needed to be slightly more patient. | 14:04 |
| pitti | Riddell, seb128: any chance I could cajole one of you to binary-NEW udev-extras? It's blocking a hal upload I'm about to do, and I'd like to get it into alpha-2 | 14:04 |
| StevenK | pitti: I think I prefered it when NBS was empty, just looking at the list | 14:04 |
| pitti | seb128, Riddell: (oh, alpha-2 is next week, nevermind; but it's still a small blocker) | 14:05 |
| seb128 | pitti: I can do that, but you can do that yourself directly too no? | 14:05 |
| Riddell | pitti: ok (I'm doing new queue now) | 14:05 |
| pitti | seb128: well, I'm the uploader | 14:05 |
| pitti | and I packaged the new binaries | 14:05 |
| seb128 | I tend to no bother finding somebody else for binary new-ing | 14:06 |
| seb128 | but usually I need those for soname changes and there is not a lot to verify in such cases | 14:06 |
| al-maisan | mterry: I believe james_w is on vacation this week. | 14:06 |
| mterry | al-maisan: Ah, kthx | 14:07 |
| Riddell | pitti (seb128): accepted | 14:08 |
| pitti | Riddell: cheers! | 14:08 |
| === sconklin-gone is now known as sconklin | ||
| === BenC1 is now known as BenC | ||
| tkamppeter | pitti, the CUPS BZR is OK now, the two wrong files I have reverted. | 14:34 |
| pitti | tkamppeter: I saw, thank yuo! | 14:34 |
| persia | ion_, There's kernel support, and userspace hiddev drivers, but nothing for X yet. | 14:34 |
| ion_ | persia: Which device is it you were demonstrating? | 14:34 |
| persia | OCZ NIA | 14:35 |
| ion_ | Ah, right | 14:35 |
| tkamppeter | For the filters in general I will return to Poppler for pdftops, GS is a good PS/PDF interpreter, but is not very good in creating PostScript. | 14:35 |
| ion_ | persia: I’d love to type using NIA controlling Dasher. :-) | 14:35 |
| pitti | tkamppeter: right, makes sense; poppler upstream didn't seem entirely averse to the patch either, so that should be okay | 14:35 |
| tkamppeter | pitti: Is there already a reaction from upstream to the patch? | 14:36 |
| pitti | tkamppeter: I just saw the initial followup | 14:36 |
| persia | ion_, That's the idea :) More hands welcome if you want to hack on stuff. I should get some packages into Karmic for basic toying about sometime this month. | 14:36 |
| ion_ | persia: Perhaps i’ll purchase one when i have extra money. | 14:37 |
| persia | At least they are about 8% of the cost of the brainfingers devices :) | 14:37 |
| tkamppeter | Problem is that we create a new dependency of CUPS on the patched Poppler, which will need that we have to wait for the patch to hit Debian. | 14:37 |
| ion_ | persia: Does the device provide the data for all the inputs the Windows™ software provides, or does the software do heavy analysis on the data? | 14:38 |
| tkamppeter | pitti: And depending on the maintainer of Poppler it can take long. The Ghostscript maintainer for example did not answer yet to my fixes. | 14:39 |
| persia | ion_, It needs analysis. The device provides raw frequency data. There is extant software that does the analysis. | 14:39 |
| tkamppeter | pitti, fortunately, we will not need my last Ghostscript fixes for CUPS any more when we revert to Poppler. | 14:41 |
| bryce | pitti: good to hear, yeah I'm feeling a lot better today, just a lingering cough | 14:53 |
| joaopinto | will karmic be using packagekit-gnome as the default app installer ? | 15:21 |
| pitti | joaopinto: no, it's too limited | 15:26 |
| pitti | PK still has fundamental design problems with dpkg | 15:26 |
| pitti | such as conffiles or debconf | 15:26 |
| joaopinto | pitti, tks | 15:36 |
| tkamppeter | pitti, WDYT, will the Debian maintianer of Poppler accept our patch quickly so that we can proceed with CUPS? | 15:42 |
| pitti | tkamppeter: I don't know, but even if not, we'll just reintroduce the original "different papersizes" bug, right? | 15:42 |
| pitti | tkamppeter: or do you introduce a new pdftops command line option which doesn't exist in current poppler? | 15:42 |
| ogra | Riddell, you rejected ldm ? | 15:43 |
| tkamppeter | There is a new pdftops command line option, "-origpagesizes" as I did not want to modify the behavior of Poppler for other programs. | 15:44 |
| tkamppeter | pitt, see https://bugs.freedesktop.org/show_bug.cgi?id=19777 | 15:44 |
| ubottu | Freedesktop bug 19777 in general "pdftops command line utility does not convert multiple-page-size documents correctly" [Normal,New] | 15:44 |
| tkamppeter | pitti: ^^ | 15:45 |
| tkamppeter | I can also modify the patch to not use this option, but this can break other programs which use pdftops of Poppler. | 15:46 |
| pitti | tkamppeter: eww, I see | 15:46 |
| pitti | tkamppeter: yes, in this case this would block on the patch being accepted | 15:46 |
| pitti | tkamppeter: however, is the current behaviour really a feature? | 15:46 |
| pitti | it sounds a bit like --unbreak | 15:46 |
| Riddell | ogra: the themes stuff I did | 15:46 |
| ogra | Riddell, they were in the archive for several years now | 15:47 |
| ogra | its three plain colored rectangles | 15:47 |
| tkamppeter | pitti, I do not know. Currently one supplies a paper size on the pdftops command line and all pages get fit into that given size. | 15:47 |
| ogra | they were just split out from the main package | 15:47 |
| pitti | tkamppeter: what happens if you don't submit a paper size? | 15:47 |
| pitti | tkamppeter: I don't understand why pdftops needs a paper size at all; after all, a PDF file should already have a proper size? | 15:48 |
| wip | any update on the rt-kernel for ubuntu 9.04? | 15:49 |
| wip | when to expect a new release? anyone working on it? | 15:50 |
| Riddell | ogra: ah, you want me to remove the old packages from the archive until you can get in a SRU with the copyright notice fixed? :) | 15:53 |
| ogra | huh ? | 15:54 |
| ogra | i doubt its even possible to copyright a color | 15:54 |
| tkamppeter | pitti, if I do not supply a size I get all pages fit into the size of the first page. | 15:54 |
| === pochu_ is now known as pochu | ||
| tkamppeter | So one-page documents always worked with Poppler's pdftops also documents with all pages having the same size, as long as the wrapper from CUPS does not supply the default size given in the PPD. | 15:55 |
| tkamppeter | The default paper size in the PPD is also intended to give a paper size default for a document without paper size, like a JPG or a PostScript file without size definition (the CUPS test page for example). | 15:57 |
| tkamppeter | pitti: A document defining a paper size is supposed to be printed in that size. | 15:58 |
| pitti | tkamppeter: that behaviour sounds like a bug to me, not a feature | 15:58 |
| tkamppeter | The user should supply the "fitplot" option if he wants to resize a PDF document to a given paper size. | 15:59 |
| tkamppeter | pitti, according to upstream developer Albert Astals Cid's comment #1 in gs.freedesktop.org/show_bug.cgi?id=19777 it seems to be a feature ... | 16:01 |
| tkamppeter | pitti, https://bugs.freedesktop.org/show_bug.cgi?id=19777 | 16:01 |
| ubottu | Freedesktop bug 19777 in general "pdftops command line utility does not convert multiple-page-size documents correctly" [Normal,New] | 16:01 |
| directhex | cjwatson, so, um..... do those of us without access to secret cabal mailing lists get to find out what the "mono (open discussion)" thing was actually meant to be about? | 16:07 |
| cjwatson | directhex: at the TB review at UDS (which was videotaped, I believe), various folks expressed a desire for the TB to hold free discussion on issues of the day, partly as agenda-fillers and partly to build up its profile | 16:10 |
| cjwatson | not necessarily with the aim of issuing anything binding but just as part of a general TB aim of having good oversight of the project | 16:10 |
| cjwatson | I think Mono (by which I assume he meant the patent position) was simply something Mark suggested off-the-cuff as something people frequently ask about and that it would be sensible to have a position on | 16:11 |
| Riddell | stgraber: what channel are we talking on? | 16:12 |
| stgraber | Riddell: the release one (probably not the best though) | 16:12 |
| directhex | cjwatson, am i allowed to be a little concerned about said discussion being moved to ubuntu-secret-cabal@lists, where people who can actually answer the TB's queries, well, aren't allowed? | 16:13 |
| Keybuk | directhex: I meant a public ML | 16:23 |
| cjwatson | I'm actually a little concerned about starting YA mono discussion on a public list given the amount of heat that has been generated on the subject in the past; personally I had been planning to hold a discussion on technical-board@ and CC the maintainers | 16:24 |
| cjwatson | there's nothing actually secret, since after all we were going to hold it on IRC, I'd just like to keep the noise down | 16:25 |
| Keybuk | we could hold it on ubuntu-devel | 16:25 |
| Keybuk | the noise doesn't go up to 11 there | 16:25 |
| directhex | although it WILL go to 11 if certain sites catch wind and link to it. FYI. | 16:28 |
| directhex | cross-posting between technical-board and debian-cli might work as another option? | 16:29 |
| directhex | in the end i'm not fussy as long as people in a position to put forward rational points of view aren't excluded | 16:29 |
| directhex | whatever those points of view may be | 16:29 |
| directhex | (oh, and nutcases are in short supply) | 16:29 |
| cjwatson | directhex: is debian-cli high-profile? | 16:34 |
| cjwatson | I don't want to exclude people, but I also don't want to try to construct something resembling a project position in the teeth of a howling gale | 16:34 |
| directhex | cjwatson, it's not particularly high profile, no. but it's the new official list for cli (.net if you're ignoring trademarks) related topics in debian. which generally means pnet and mono. | 16:35 |
| evand | Riddell: I am afraid I don't agree with your rejection of parti-all on account of it containing two gzipped pdf files in the source tree. The files are not part of any resulting binaries, they're MIT licensed, and they're not generated from an available source document. | 16:37 |
| Elbrus | Can I see the logs of this channel somewhere? | 16:37 |
| * Elbrus wonders if infinity responded to my ping last time | 16:37 | |
| Riddell | evand: how do you modify them? | 16:37 |
| directhex | Elbrus, i think there's an irclogs.ubuntu.com | 16:37 |
| directhex | Riddell, a hex editor, what else? | 16:38 |
| Elbrus | directhex: thanks | 16:38 |
| persia | Riddel: Is the preferred form for modification a requirement for MIT licensed material? | 16:40 |
| evand | Riddell: They're X11 licensed, it doesn't have that clause. | 16:40 |
| Riddell | evand: we're a free software distro, we require files to modifiable | 16:41 |
| Riddell | at least for main and universe we do | 16:41 |
| Riddell | persia: no it's a requirement for main and universe | 16:41 |
| Elbrus | infinity: ping, you seem to be the one that could help with bug 67544 | 16:42 |
| ubottu | Launchpad bug 67544 in fpc "PPC build of fpc fails" [Undecided,Confirmed] https://launchpad.net/bugs/67544 | 16:42 |
| persia | Well, there's always pdfedit, but hrm. | 16:42 |
| Riddell | and "I saw sladen do it once" isn't a reasonable definition of editable :) | 16:42 |
| Elbrus | fpc needs bootstrapping on ppc | 16:43 |
| cjwatson | directhex: I meant high-profile enough for anything posted there to turn into a firestorm | 16:43 |
| cjwatson | Riddell: PDFs are modifiable with a PDF editor; the things that require a *transparent* file format are the GPL/GFDL and friends, not our general principles | 16:44 |
| ion_ | It seems they’ve managed to make screen rotation work a bit better in the radeon driver. | 16:44 |
| pitti | s/transparent/preferred form of modification/ | 16:44 |
| cjwatson | I think that's just wording; the GPL says "preferred form for modification" while the GFDL says "transparent", but the effect is similar | 16:45 |
| pitti | well, I disagree | 16:45 |
| === smb_tp is now known as smb | ||
| cjwatson | our main/universe licensing policy says that the licence must permit modification, but says *nothing* about how | 16:45 |
| pitti | if I produce a html file from a docbooc xml file, shipping only the html file would violate the GPL | 16:46 |
| cjwatson | if you disagree, could you point me to where it says how? | 16:46 |
| pitti | but if a html file is written from scratch, then this _is_ the source and preferred form of modification | 16:46 |
| cjwatson | pitti: hm, ok, but nevertheless none of that is at issue here | 16:46 |
| persia | I think we do have some restrictions though: we don't allow pq in universe, for example. | 16:46 |
| cjwatson | persia: pq? | 16:46 |
| pitti | cjwatson: right, just pointing out that transparency is not the main point of the GPL, as far as I understand it | 16:46 |
| persia | cjwatson, Yes. It's a windows binary that permits free redistribution and modification *of the binary*, for which we don't have source. | 16:46 |
| cjwatson | persia: that arises from "The main and universe categories have a strict and non-negotiable requirement that application software included in them must come with full source code." | 16:47 |
| cjwatson | "application software" does not include PDFs | 16:47 |
| directhex | cjwatson, to the best of my knowledge that's unlikely to happen - however, an argument could be made that it's not an ideal place to post as it's "not neutral enough" as a list. in the end it's your call. i just want to avoid being talked about again without knowing after that time on debian-legal | 16:47 |
| persia | Ah. I understand the distinction at this point. Thank you. | 16:47 |
| evand | Riddell: So given the preceding discussion, are you comfortable with accepting that upload? | 16:49 |
| === DrKranz is now known as DktrKranz | ||
| sladen | cjwatson: interesting, what about a PDF with the non-edit bits set? | 16:50 |
| Riddell | evand: I must admit I'm not confortable with accepting files which are not in preferred modifiable form into universe | 16:50 |
| Keybuk | Riddell: do you ship any png files anywhere? | 16:51 |
| Keybuk | or any ttf files? | 16:51 |
| Keybuk | etc. | 16:51 |
| Keybuk | in the parti-all case, common sense should prevail anyway | 16:51 |
| Keybuk | since the files are not part of any resulting binary package, they aren't interesting | 16:51 |
| cjwatson | Riddell: I don't believe there is any justification for this from the licensing policy, TBH | 16:52 |
| Riddell | Keybuk: PNG files often are preferred modifiable form. where they're not they should be accompanied by the files which are | 16:52 |
| persia | Keybuk, arguably, for some applications, .png *is* the preferred form for modification. | 16:52 |
| Keybuk | indeed, I'm pretty sure we specifically encoded into the licencing policy a get-out clause for documentation, graphics, fonts, etc. | 16:52 |
| directhex | +dfsg ! | 16:52 |
| persia | (although your argument stands for .ttf) | 16:52 |
| cjwatson | since the very beginning we've said that we'll decide on data case-by-case | 16:52 |
| Keybuk | Riddell: PDF are often the preferred modifiable form | 16:52 |
| cjwatson | if evand says that these files are actually edited as PDFs ... | 16:52 |
| Keybuk | and in this case, these documents are in the source package simply because they're specifications that the author followed | 16:53 |
| cjwatson | (and even if they aren't, I don't see a huge problem TBH) | 16:53 |
| Keybuk | repackaging the source package just to remove them would be a ridiculous PITA | 16:53 |
| cjwatson | sladen: #include <flamewar.h> | 16:53 |
| Keybuk | especially since they aren't placed into a binary | 16:53 |
| Riddell | ooh, New queue is empty | 16:54 |
| Riddell | only took all day | 16:54 |
| * pitti hugs Riddell | 16:55 | |
| pitti | Keybuk: right now the i915 module is loaded very late, even after mounting the root fs; this makes it quite impossible to do anything sensible with usplash | 16:56 |
| pitti | Keybuk: do you think there is a chance to move modprobing to a much earlier point in the boot process? | 16:56 |
| Keybuk | no | 16:57 |
| pitti | s/i915 module/any video module providing KMS/ | 16:57 |
| pitti | right now it takes more time _before_ KMS gets enabled than between KMS and gdm | 16:57 |
| Keybuk | I'd rather we simply got there faster | 16:57 |
| pitti | readahead alone blocks for 5 seconds or more | 16:57 |
| pitti | and I don't think we can significantly speed up this | 16:57 |
| pitti | at most we can move it to a different time | 16:58 |
| Keybuk | we can significantly speed up the time it takes to load drivers | 16:58 |
| Keybuk | my every waking moment is currently consumed by that task | 16:58 |
| Keybuk | I fully expect that we will have the KMS driver loaded at the same time after boot that we currently start usplash | 16:58 |
| Keybuk | so chill out, relax, and let me worry about boot speed ;) | 16:58 |
| pitti | Keybuk: I was just curious :) | 16:59 |
| pitti | Keybuk: erm, don't we start usplash in the initramfs? | 16:59 |
| Keybuk | yes | 16:59 |
| pitti | you said that we wouldn't move the drivers into the initrd last week | 16:59 |
| Keybuk | but I don't want to put the kms drivers in there | 16:59 |
| Keybuk | in fact, I'm going to start ripping things *out* of the initramfs | 16:59 |
| pitti | right, understandably | 16:59 |
| Keybuk | we should spend as little time in there as possible | 16:59 |
| Keybuk | budget looks a bit like | 17:00 |
| Keybuk | kernel: 1.2s | 17:00 |
| Keybuk | initramfs: 0.8s | 17:00 |
| Keybuk | udev: 1s | 17:00 |
| evand | Riddell: Are we at an impasse? And if so, shall we take this to the TB for a formal clarification? | 17:00 |
| Keybuk | that'll mean the kms driver is loaded *by* 3s | 17:00 |
| ion_ | keybuk: Will karmic have Upstart in initramfs? | 17:00 |
| Keybuk | ion_: unlikely | 17:00 |
| cjwatson | Keybuk: oh, you mentioned that you had a console-setup patch to make it use udev - if you can toss that over to me, I could push it up the hill towards upload | 17:00 |
| Keybuk | evand: (TB hat) I don't see that it needs a formal clarification; the current licensing documentation is clear | 17:00 |
| pitti | Keybuk: I just feel that we should do something to unbreak usplash for alpha-2 | 17:00 |
| pitti | right now it just turns into a black screen after KMS gets active | 17:01 |
| Keybuk | pitti: *shrug* I'm not worried about it | 17:01 |
| pitti | hm, I forget that we don't have that enabled by default yet | 17:01 |
| Keybuk | if you're looking for something to do to help boot speed, that GNOME login really needs some work ;) | 17:01 |
| Riddell | evand: I'm done archive admin for the day, if you upload maybe tomorrows archive admin will accept the tyranny of non-preferred modifiable forms, or you can repack without PDFs and I'll accept it | 17:01 |
| evand | Keybuk: I just don't want to force anything. If it's not clear, then perhaps it's worthwhile for the TB to make a statement? But I defer to higher powers. | 17:01 |
| pitti | Keybuk: that's on our plate already :-) | 17:01 |
| evand | Riddell: okay | 17:01 |
| Keybuk | Riddell: did you have any other objection other than the PDF? | 17:02 |
| Keybuk | Riddell: was the source otherwise clear? | 17:02 |
| evand | Riddell: I do appreciate you looking it over, and I do appreciate your concerns. | 17:02 |
| Riddell | Keybuk: seemed ok, I didn't look at it in detail | 17:02 |
| pitti | Keybuk: in particular, seb128 will look at nautilus, I'll look at gnome-panel, and I'll talk to mvo or Robert about some go-faster stripes for compiz startup | 17:02 |
| Keybuk | pitti: remember that my plan is to only start usplash if we need a filesystem check or a passphrase | 17:03 |
| Keybuk | and that in the normal case, it won't be | 17:03 |
| pitti | yep | 17:03 |
| pitti | Keybuk: passphrase, too? | 17:03 |
| pitti | I don't think that's possible | 17:03 |
| pitti | in your design usplash starts after mounting the root fs, I thought? | 17:03 |
| seb128 | Keybuk: I don't think the "no splash" idea is a good one | 17:03 |
| Keybuk | pitti: no | 17:03 |
| pitti | i. e. crytpsetup -> passphrase -> root fs -> big modprobe -> KMS gets active | 17:04 |
| Keybuk | seb128: I'm not suggesting "no splash", I'm suggesting we start X where we currently start usplash and do the splash as an X window | 17:04 |
| Keybuk | pitti: passphrase for root fs is a very special case that requires deliberately activation | 17:04 |
| ion_ | So, karmic will have usplash and not plymouth? | 17:05 |
| Keybuk | pitti: that means we can repack the initramfs for it | 17:05 |
| Keybuk | pitti: and put usplash and KMS modules and the whole world into the initramfs | 17:05 |
| Keybuk | and inherently not care about boot speed because most of the time will be waiting for passphrases and decryption time | 17:05 |
| seb128 | Keybuk: I'm waiting to see how long it takes to start xorg on my 6 years old desktop with a slow disk | 17:05 |
| seb128 | Keybuk: I doubt it will be 3 seconds though | 17:05 |
| Keybuk | seb128: it should be roughly the same time it currently takes you to start usplash | 17:05 |
| seb128 | Keybuk: xorg itself takes longer than 3 seconds to start on this box ... | 17:06 |
| Keybuk | seb128: with KMS? | 17:06 |
| Keybuk | and are you sure? | 17:06 |
| pitti | Keybuk: ah | 17:06 |
| Keybuk | because I bet X starts really fast | 17:06 |
| seb128 | no, normal xorg | 17:06 |
| seb128 | Keybuk: well bootchart have xorg ressource busy for at least 3 seconds | 17:07 |
| seb128 | Keybuk: in any case I will try on karmic to see how it works | 17:07 |
| * pitti pats ecryptfs | 17:08 | |
| pitti | seb128: that's surprising | 17:08 |
| pitti | X itself starts in no time here | 17:08 |
| pitti | it's all background, gdm, etc. which takes time | 17:08 |
| pitti | KMS helps a lot there, yes | 17:08 |
| seb128 | pitti: well that's a normal boot and I've several seconds on the bootchart between Xorg and gdmgreeter but it could be gdm before the greater or something | 17:10 |
| Keybuk | eep | 17:10 |
| Keybuk | brownout | 17:10 |
| Keybuk | seb128: was just saying | 17:10 |
| Keybuk | that I bet X starts pretty fast with KMS | 17:10 |
| Keybuk | and instead gdm isn't noticing | 17:10 |
| ion_ | keybuk: UPS? :-) | 17:10 |
| Keybuk | ion_: DSL lost sync, so I guess the exchange got knocked out too | 17:10 |
| ion_ | Ah | 17:10 |
| Keybuk | seb128: new gdm appears to fix this bug | 17:11 |
| Keybuk | indeed there are git commits which say that they directly fixed this exact bug I was looking for ;) | 17:11 |
| Keybuk | though they don't backport to old gdm sadly | 17:11 |
| Keybuk | I had a go myself for the stig image, and appeared to fix it | 17:11 |
| hyperair | pitti: thanks for sponsoring =) | 17:12 |
| pitti | Keybuk: we'll use the new gdm in karmic anyway | 17:13 |
| pitti | meh, seems my DSL just got a hangover as well | 17:13 |
| pitti | hyperair: thanks for the fix! | 17:13 |
| seb128 | Keybuk: good, we intend to switch to new gdm this cycle | 17:13 |
| hyperair | pitti: no problem. it was bugging me. on the other hand, i don't get to enjoy my fix now because gpm doesn't seem to work well with KMS =( | 17:13 |
| Keybuk | so we have two options really | 17:13 |
| pitti | hyperair: ugh, what does gpm have to do with KMS? | 17:14 |
| Keybuk | a) spend time and effort getting KMS and usplash up early, just to have a throbber until X starts | 17:14 |
| Keybuk | b) spend time and effort getting X up just as early | 17:14 |
| hyperair | pitti: brightness control things. | 17:14 |
| pitti | hyperair: ah | 17:14 |
| pitti | Keybuk: b) | 17:14 |
| hyperair | pitti: the main reason i did that fix was to get the brightness thing working. but now my brightness keys are completely dead with KMS on | 17:14 |
| hyperair | i can't exactly report a bug either; i'm running xorg-edgers' packages | 17:14 |
| Keybuk | and when you think about it, what are X's dependencies? | 17:15 |
| Keybuk | X depends on a mounted filesystem | 17:15 |
| Keybuk | X depends on KMS driver | 17:15 |
| Keybuk | mounted filesystem depends on drivers | 17:15 |
| seb128 | you need usb drivers to be loaded | 17:15 |
| Keybuk | so really, X depends on udev | 17:15 |
| pitti | seb128: not with input hotplugging any more, I think? | 17:15 |
| Keybuk | udev depends on kernel | 17:15 |
| pitti | Keybuk: in the past, X.org needed the hostname to be set as well | 17:15 |
| Keybuk | pitti: probably still true, but that's a single syscall | 17:16 |
| Keybuk | so boot looks like | 17:16 |
| persia | pitti, What about output hotplugging: one might have the display on USB. | 17:16 |
| Keybuk | 1) start kernel | 17:16 |
| Keybuk | 2) find and mount root filesystem | 17:16 |
| Keybuk | 3) set hostname | 17:16 |
| seb128 | pitti: well you don't want to get gdm there and mouse and keyboard not working for a while ... | 17:16 |
| Keybuk | 4) load drivers | 17:16 |
| Keybuk | 5) start X | 17:16 |
| Keybuk | doing hardware clock sync, console setup, filesystem checks and mounting all under 4 | 17:16 |
| pitti | seb128: I think they will get loaded together with the video driver in the big udev modprobe call? | 17:16 |
| Keybuk | seb128: you'll get them at the same time as the video driver modulo bus issues | 17:17 |
| pitti | seb128: also, there should be a throbber between X and gdm, while the remaining boot stuff happens, AFAIUI | 17:17 |
| cjwatson | if we can set the keyboard layout after X itself starts, then console-setup and dbus/hal/blah can move later | 17:17 |
| seb128 | pitti: could be, I'm not the expert there, just saying we need to get usb input devices working | 17:17 |
| Keybuk | seb128: but they're dependencies of *gdm* | 17:17 |
| Keybuk | not of X | 17:17 |
| pitti | killall hal | 17:17 |
| Keybuk | we can have X up earlier | 17:17 |
| Keybuk | with an X window throbber | 17:17 |
| Keybuk | while we wait for gdm's deps | 17:17 |
| seb128 | right | 17:17 |
| cjwatson | pitti: pedant :-) | 17:17 |
| cjwatson | YKWIM | 17:17 |
| pitti | cjwatson: wasn't meant as correction, just as a plan :) | 17:18 |
| Keybuk | kernel is up in 1.2s right now | 17:18 |
| Keybuk | my minimal initramfs is 0.5s | 17:18 |
| Keybuk | we have udev doing its thing in just 0.8s now | 17:18 |
| pitti | in fact I don't have a clear idea yet how the future hal-less X.org will get the keyboard layout | 17:18 |
| Keybuk | that leaves us a whole 0.5s to set the hostname ;) | 17:18 |
| Keybuk | pitti: probably a udev rule instead of an fdi? | 17:18 |
| pitti | maybe through udev device properties | 17:19 |
| pitti | Keybuk: that would just transform /etc/default/console-setup into udev properties | 17:19 |
| pitti | if /etc/default/console-setup is "less standard" than udev, that would work | 17:19 |
| Keybuk | pitti: bit of luck it's in a form that udev can read already then ;) | 17:19 |
| Keybuk | IMPORT{file}="/etc/default/console-setup" | 17:20 |
| ion_ | Btw, exactly how does e.g. magic sysrq’s text output behave with KMS+X? Paint in some point in the video memory, until X happens to paint over the same spot again? | 17:20 |
| cjwatson | Keybuk: cunning | 17:20 |
| seb128 | do you do tests on slow disks too? | 17:20 |
| Keybuk | ion_: it doesn't pain | 17:20 |
| Keybuk | +t | 17:20 |
| Keybuk | seb128: yes, I mostly test on my laptop | 17:20 |
| Keybuk | which has the slow disk of death | 17:20 |
| Keybuk | I'm hoping for faster results when I test on a mini9 | 17:20 |
| ion_ | keybuk: Is there any hope of that changing? | 17:20 |
| Keybuk | this stuff is mostly not disk though | 17:20 |
| seb128 | the d420 you mean, not the mini9 right? | 17:20 |
| Keybuk | ion_: not really | 17:20 |
| Keybuk | seb128: the d420, right | 17:21 |
| seb128 | ok | 17:21 |
| seb128 | because I always find my bootchart very different of you mini9 ones | 17:21 |
| seb128 | ie my disk seems much slower | 17:21 |
| seb128 | but cpu is faster | 17:21 |
| Keybuk | seb128: the mini9 has an SSD | 17:21 |
| Keybuk | that makes a massive difference | 17:21 |
| Keybuk | the slow CPU though kills it in other ways | 17:21 |
| Keybuk | for a truly awesome experience, steal jcastro's laptop | 17:21 |
| seb128 | right, which is why I'm trying to make sure slow disk owner will have something nice too ;-) | 17:22 |
| Keybuk | X200+Intel SSD ... 12s boot to full logged-in desktop on jaunty | 17:22 |
| * Keybuk wishes his next laptop refresh would hurry up | 17:22 | |
| pitti | Keybuk: *wow* | 17:22 |
| Keybuk | seb128: sure | 17:22 |
| Keybuk | seb128: which is why I'm putting the usplash option where I am ;) | 17:22 |
| tormod | apropos Xorg startup try: time xinit -e '' (actually adds the shutdown time too) | 17:22 |
| Keybuk | having it optional at the point we check disks means that we can also, maybe, start it if the disk is not SSD | 17:23 |
| Keybuk | I'm hoping we don't have to | 17:23 |
| Keybuk | but it's an option | 17:23 |
| pitti | Keybuk: so it seems that the 5 second readahead block is really the biggest remaining chunk before KMS/X start? | 17:23 |
| cjwatson | we could split up readahead to prioritise X | 17:24 |
| Keybuk | right, there's a few options here | 17:24 |
| hyperair | pitti: o noes. gpm ftbfs on hppa. | 17:25 |
| pitti | hyperair: *shrug* | 17:26 |
| Keybuk | hyperair: hppa EOL kthxbye ;) | 17:26 |
| pitti | not that it ever had much of a life in the first place | 17:26 |
| slangasek | everything ftbfs on hppa now, if I'm not mistaken | 17:27 |
| slangasek | (due to aforementioned EOL) | 17:27 |
| Keybuk | slangasek: buildd repurposed as a doorstop? | 17:27 |
| cjwatson | re? | 17:27 |
| slangasek | mterry: seen that quodlibet FTBFS on all !i386? I guess there's a binary-indep/binary-arch mismatch in debian/rules somewhere | 18:10 |
| mterry | slangasek: Ah yes. I made a mental note to check that out. I'll look into it | 18:10 |
| highvoltage | where is ubuntu's calender these days? I heard it's in google somewhere? | 18:12 |
| LaserJock | highvoltage: I think the fridge has a link | 18:13 |
| slangasek | so, does anyone know where my gpg agent went on upgrade to karmic? | 18:16 |
| ogra | it probably became a secret agent :P | 18:16 |
| highvoltage | heh | 18:17 |
| === DreamThi1f is now known as DreamThief | ||
| * slangasek grins | 18:18 | |
| slangasek | are others seeing the same issue? | 18:18 |
| ogra | processlist here has nothing about gpg | 18:20 |
| mterry | slangasek: I'm on karmic, and I still get the little dialog asking for my gpg passphrase | 18:20 |
| highvoltage | who maintains the ubuntu google calender? I have some trouble adding an event | 18:22 |
| slangasek | mterry: do you know which process is running it? seahorse, or something else? | 18:30 |
| mterry | slangasek: Nope. seahorse is a good guess though | 18:31 |
| * ogra would guess gnome-keyring-daemon | 18:31 | |
| slangasek | well, g-k-d doesn't appear to be handling gpg here | 18:32 |
| slangasek | it does handle ssh | 18:32 |
| slangasek | bryce: 382390> mutter, why doesn't ubuntu-bug xserver-xorg-video-intel dtrt there? | 18:33 |
| bryce | slangasek: weird | 18:35 |
| bryce | slangasek: near as I can tell if you filed it like that it should have pulled everything in | 18:36 |
| slangasek | bryce: well, bah | 18:37 |
| bryce | maybe a pitti question? | 18:38 |
| slangasek | hmm, I think I got an LP error message around the time I filed that bug, maybe that's why it broke | 18:38 |
| bryce | ah | 18:38 |
| slangasek | well, time to try to reproduce the bug, then break everything with KMS | 18:38 |
| bryce | kewl | 18:39 |
| bryce | I'm working on the 2.7.99.1 update presently | 18:39 |
| slangasek | of course now the bug is unreproducible | 18:41 |
| slangasek | I probably need to have a projector on hand or something to reproduce it | 18:41 |
| YokoZar | Do we have a daily USB stick image for Karmic? Or was that just an idea... | 18:42 |
| bryce | YokoZar: working on it. | 18:42 |
| bryce | YokoZar: what we have so far is a livecd image with xorg-edgers here - http://people.ubuntu.com/~bryce/xorg-edgers-0.1-i386.iso | 18:43 |
| YokoZar | bryce: I guess I can write that to the stick using the same tools and boot/install karmic from that right? | 18:44 |
| bryce | YokoZar: presumably yes | 18:44 |
| === evanrmurphy_ is now known as evanrmurphy | ||
| slangasek | bryce: another successful KMS test for you | 19:03 |
| bryce | sweetness | 19:03 |
| bryce | slangasek: any improvement in boot speed? | 19:04 |
| slangasek | oh, pitti reports problems with external monitor on 945, hmm... guess I should check that myself | 19:04 |
| slangasek | bryce: no, looked pretty much the same to me | 19:05 |
| bryce | ok | 19:05 |
| slangasek | OTOH, I have root on crypt-lvm, and it always seems like there's an unnecessary delay after decrypting... I should figure out what that is | 19:05 |
| bryce | btw, what is your boot time total? | 19:06 |
| slangasek | eh, haven't timed it, and as per above it wouldn't be representative :) | 19:06 |
| bryce | my laptop takes 55s to boot, my ati box takes 25s | 19:06 |
| * slangasek mutters at the shorter cable on his replacement AC adapter | 19:07 | |
| YokoZar | Is CPU time a limiting factor anywhere in the boot process? | 19:07 |
| YokoZar | or is it mostly I/O stuff | 19:07 |
| directhex | moar cores. it's the only option. | 19:08 |
| slangasek | bryce: hmm, I do have a regression in the set of video output configurations that Fn+F7 cycles through for me | 19:08 |
| bryce | YokoZar: looks like mostly I/O to me. usplash is the only thing that seems to take significant cpu | 19:08 |
| slangasek | I get "both on, high res", "internal on", "both on, low res"; missing is "VGA on, LVDS off" | 19:09 |
| bryce | hmm | 19:10 |
| bryce | slangasek: not sure if that is X, or whatever handles Fn+F7 now | 19:11 |
| bryce | worth filing a bug in any case | 19:12 |
| * slangasek nods | 19:12 | |
| slangasek | the only thing I changed was turning on KMS, so | 19:12 |
| ion_ | So, how does one test KMS and where to post results? | 19:13 |
| slangasek | https://wiki.ubuntu.com/X/KernelModeSetting | 19:14 |
| ion_ | Thanks, was just about to click that search result. :-) | 19:14 |
| slangasek | bryce: oh - in Settings -> Preferences -> Display, both outputs are now listed as 'unknown' instead of having names... | 19:16 |
| ion_ | Ah, ATI KMS is not available yet. I was under the impression the new Fedora release had it. | 19:16 |
| slangasek | bryce: though that may be unrelated to turning on KMS | 19:16 |
| bryce | slangasek: there's a lookup table local to gnome-display-properties that should have it | 19:17 |
| bryce | you could doublecheck that xrandr --verbose lists your monitor's model code | 19:17 |
| bryce | if it does, then gnome-display-properties may be bugged. If it doesn't, then something's wrong with the edid stuff in X | 19:18 |
| slangasek | what does a "model code" look like? | 19:18 |
| bryce | like AUO, BNQ, SNY | 19:19 |
| slangasek | hmm, I don't seem to have anything like that | 19:19 |
| bryce | hmm actually it appears xrandr doesn't print that | 19:21 |
| bryce | get-edid | parse-edid | grep ModelName | 19:22 |
| bryce | assuming you're on x86 | 19:22 |
| slangasek | what package is get-edid in? | 19:23 |
| bryce | read-edid | 19:23 |
| slangasek | by x86 do you mean i386? | 19:23 |
| bryce | slangasek: yeah | 19:24 |
| slangasek | yeah, no help there | 19:24 |
| persia | Also works on powerpc and lpia :) | 19:25 |
| slangasek | clearly we need to get multiarch on its feet so that I can run get-edid | 19:25 |
| bryce | :-D | 19:25 |
| bryce | slangasek: alternatively, it may be displayed in your /var/log/Xorg.0.log | 19:26 |
| bryce | (II) RADEON(0): EDID vendor "BNQ", prod id 30427 | 19:26 |
| persia | Erm, will that help? Can one access real-mode x86 on x86_64? If so, it's probably just a matter of recompilation. If not, multiarch won't help. | 19:26 |
| slangasek | EDID vendor "LEN"; so it at least knows the vendor for the LVDS | 19:27 |
| bryce | ok, so X seems to be ok, now to check gnome... | 19:28 |
| bryce | { "LEN", "Lenovo" }, | 19:29 |
| bryce | that is 2.26, let me check latest too | 19:29 |
| bryce | yep, there in 2.26.1 too | 19:30 |
| bryce | (libgnome-desktop, display-name.c, vendors[]) | 19:30 |
| YokoZar | quick question: is it possible to add a tab to a Gnome right click->properties dialog with a separate package, or does that require modifying something inside gnome? | 19:31 |
| YokoZar | (writing the spec for Wine integration) | 19:31 |
| bryce | slangasek: best guess is that the API for getting monitor info has changed with the modesetting stuff moved to the kernel | 19:31 |
| slangasek | bryce: yeah, that was my guess too. Where should that bug get filed? | 19:35 |
| bryce | gnome-display-properties probably | 19:35 |
| slangasek | ok | 19:35 |
| persia | YokoZar, #ubuntu-desktop may have more information, but I think you can do it with nautilus extensions. | 19:37 |
| YokoZar | persia: If nautilus is extendable in a sane way, that should be enough | 19:38 |
| * persia doesn't claim "sane", but doesn't have enough information to claim otherwise either | 19:39 | |
| persia | YokoZar, One package I know to create context is nautilus-open-terminal | 19:39 |
| YokoZar | I'll put in the spec that it should be doable through an extension (and thus Gnome should be more extensible if it isn't), since this is exactly the kind of code that doesn't need to go in by default | 19:39 |
| highvoltage | cjwatson, slangasek: are you around, LaserJock and myself would like to speak to you about Edubuntu releases | 19:44 |
| slangasek | highvoltage: I'm around | 19:44 |
| highvoltage | slangasek: great. I understand that there are limitations on hosting currently in the canonical datacenter, and that this is affecting how much we can ship in an iso? | 19:45 |
| LaserJock | the basic thing is that Edubuntu would like to ship a full DVD or USB image | 19:46 |
| LaserJock | the Addon thing just doesn't seem to work all that well | 19:46 |
| highvoltage | slangasek: based on feedback from our users, we would very much like to expand our offering somewhat for karmic, and for karmic+1 we aim to be a full installation disc again, based on feedback from our users. | 19:46 |
| slangasek | bryce: once again, ubuntu-bug only attached Dependencies.txt to my report (bug #382864), not anything else | 19:46 |
| ubottu | Launchpad bug 382864 in xorg "xrandr cycling is all messed up with KMS" [Undecided,New] https://launchpad.net/bugs/382864 | 19:46 |
| LaserJock | but since our .iso got dropped off releases.ubuntu.com we were wondering if there is some way to get back on for Karmic or Karmic+1 with a DVD | 19:47 |
| highvoltage | in short, we need to know that the infrustructure can support our images before we can commit to our users on this | 19:47 |
| slangasek | LaserJock, highvoltage: limitations on hosting> not explicitly, that I'm aware of; though changes to the image type we're building for edubuntu would have to get blessed by someone above me in the chain, I believe | 19:47 |
| slangasek | "get back on" - on releases.ubuntu.com? | 19:47 |
| highvoltage | slangasek: such as the TB? | 19:48 |
| LaserJock | slangasek: yep | 19:48 |
| highvoltage | slangasek: edubuntu used to be hosted on releases.ubuntu.com | 19:48 |
| slangasek | highvoltage: yes | 19:48 |
| slangasek | LaserJock: I think there's zero chance of us shipping an Edubuntu DVD on releases.ubuntu.com | 19:49 |
| LaserJock | ok | 19:49 |
| highvoltage | slangasek: what's the limiting factors? if there's something we can do to help fix it we would want to do so | 19:49 |
| slangasek | no, it's not a limit within the Canonical data center - it's that releases.ubuntu.com is the basis for all of the CD mirrors, and the more images we ship there the fewer mirrors we can get | 19:50 |
| bryce | slangasek: does running 'apport-collect' cause them to be attached? | 19:50 |
| bryce | slangasek: also check if 'ubuntu-bug xorg' produces the same behavior | 19:50 |
| LaserJock | slangasek: so would it be possible to have it on cdimage.ubuntu.com and then come up with our own mirrors? | 19:51 |
| slangasek | bryce: this time, I did run 'ubuntu-bug xorg' | 19:51 |
| bryce | slangasek: ok really weird | 19:51 |
| bryce | slangasek: let me try | 19:52 |
| slangasek | LaserJock: I would still want to get that change blessed by the TB before making the change to the image building, but at least in theory that should be fine | 19:52 |
| highvoltage | slangasek: thanks for your input, we'll add it to the agenda for the next TB meeting | 19:52 |
| bryce | slangasek: broke for me too (lp: 382868) | 19:53 |
| slangasek | bryce: ah, apport-collect also fails, with a traceback | 19:56 |
| slangasek | oh, the same one you just reported | 19:56 |
| slangasek | :) | 19:56 |
| mterry | slangasek: I'm having a bit of trouble with quodlibet. It seems that quodlibet-ext wants to install all the files from all 3 binary packages, not just the files in its .install file... Let me know if/when you have a sec to talk about it | 20:09 |
| slangasek | mterry: ok, let's take a crack at it | 20:11 |
| slangasek | hmm, I still need to upload python-defaults to prune python 2.5, don't I | 20:13 |
| slangasek | mterry: isn't the problem that it's looking for site-packages instead of dist-packages? | 20:15 |
| mterry | slangasek: So that's the white rabbit that led me into a hole | 20:15 |
| slangasek | can you post me a debdiff of what you currently have? | 20:16 |
| mterry | slangasek: When I packaged that merge, I changed it back from dist-packages to site-packages, because that seemed to be what i386 needed (I assumed it was part of the general python changes to use site-packages and then rename it to dist-packages automatically) | 20:17 |
| mterry | slangasek: But I assume that's not the case for other archs apparently | 20:17 |
| mterry | slangasek: But this got me looking at the quodlibet-ext package and I noticed that it has way too many files | 20:17 |
| slangasek | mterry: ah, heh, so it does | 20:18 |
| mterry | slangasek: So, there may be two issues here | 20:18 |
| mterry | slangasek: (I'm trying to find merge bug with debdiffs) | 20:18 |
| mterry | slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/quodlibet/+bug/373827 has debdiffs | 20:19 |
| ubottu | Ubuntu bug 373827 in quodlibet "Please merge quodlibet 2.0-3 (universe) from Debian unstable" [Wishlist,Fix released] | 20:19 |
| slangasek | mterry: a debuild -B seems to DTRT, after fixing quodlibet-ext.install | 20:22 |
| mterry | slangasek: Interesting... I wasn't getting that | 20:23 |
| mterry | slangasek: Let me start with a fresh source checkout | 20:23 |
| slangasek | well, it may *not* DTRT with debuild -b | 20:23 |
| mterry | slangasek: ah, yes, I've been doing -b | 20:24 |
| slangasek | the difference between the two is very salient here, since the package FTBFS only on !i386 :) | 20:24 |
| === beuno_ is now known as beuno | ||
| elmo | cjwatson: hey | 20:47 |
| elmo | cjwatson: can we fix our filesystems to have remount-ro in the FS by default? | 20:47 |
| cjwatson | elmo: err, YM in the kernel or something? | 20:48 |
| elmo | cjwatson: well, I was thinking mkfs, but I notice it doesn't have an option for that | 20:48 |
| elmo | which is annoying | 20:48 |
| cjwatson | elmo: well, you can tune2fs it, but yes | 20:56 |
| cjwatson | elmo: you could ask Ted ... | 20:57 |
| elmo | cjwatson: I was thinking a bug report ;-) I suppose I could do both | 20:57 |
| elmo | 'continue' is just such an insane default | 20:57 |
| elmo | "errors? oh well, LET'S TRY HARDER" | 20:57 |
| cjwatson | elmo: odd given http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg254037.html | 21:01 |
| elmo | cjwatson: ah, ok, super | 21:01 |
| elmo | I'm still in ext3 world | 21:01 |
| cjwatson | elmo: but mke2fs's default still seems to be continue anyway | 21:01 |
| cjwatson | elmo: I believe the installer always uses remount-ro for ext* though? | 21:02 |
| elmo | cjwatson: yeah, it does | 21:02 |
| elmo | cjwatson: I'm just in the position of adding a new drive, post install | 21:02 |
| cjwatson | ah | 21:02 |
| slangasek | which package should be bugged about the gnome-power-manager icons defaulting to the stock GNOME ones? | 21:12 |
| === beuno_ is now known as beuno | ||
| === Snova_ is now known as Snova | ||
| themuse | hi, anybody with some Boost (dev libs) packaging experience here? | 22:00 |
| persia | themuse, You might try #ubuntu-motu for that. | 22:13 |
| themuse | persia: ok, thx for the hint | 22:13 |
| calc | hmm win7 releases one week before karmic | 22:21 |
| Tm_T | calc: perfect, so people get in the "this sucks lets try Ubuntu" mood just in time (;) | 22:24 |
| === dyfet__ is now known as dyfet | ||
| calc | Tm_T: heh | 22:28 |
| NCommander | slangasek, (or any other archive admin who's awake), am I correct in the assumption that for any package to enter the archive, it needs to contain the full text of its license in the tarball (in COPYING or another similar file; a link to a file outside the tarball isn't acceptable) | 22:35 |
| slangasek | NCommander: there's no particular reason that the license has to be in the upstream tarball | 22:36 |
| slangasek | unless that violates the terms *of* the license in question, rendering the tarball undistributable | 22:37 |
| NCommander | slangasek, hrm, I vaguely remember getting a REJECT over this for a package under the GPL, but maybe my memory gone faulty :-/ | 22:39 |
| * soren is very confused.. | 22:41 | |
| soren | Scripts in /usr/share/initramfs-tools/scripts/init-bottom should all unconditionally be copied to the initramfs, shouldn't they? | 22:41 |
| === sabdfl1 is now known as sabdfl | ||
| * soren wonders if there's restrictions on the names of those scripts.. | 22:42 | |
| slangasek | NCommander: in the case of the GPL, it's a condition of the license itself that the source be accompanied by the license; but that's not "for any package", that's "for packages whose license requires it" | 22:42 |
| NCommander | slangasek, the license says "should", not "must", but that's a nitpick from my prelaw days | 22:43 |
| slangasek | NCommander: which license? | 22:43 |
| slangasek | GPLv2, §1 requires it as a condition of distribution | 22:44 |
| NCommander | sladen, argh,y eah, sorry, I'm an idiot, I was reading something else, and my brain got a wired crossed | 22:44 |
| NCommander | (and I found a goof on the FSF page on how to apply the GPL to your packages :-)) | 22:45 |
| dholbach | Mez: http://daniel.holba.ch/blog/?p=78 | 22:49 |
| Mez | what have I done now ? :P | 22:51 |
| dholbach | Mez: 4000 mails in moderation | 22:52 |
| Mez | :D | 22:52 |
| NCommander | o___________o; | 22:56 |
| ajmitch | dholbach: is that for the dholbach fanclub list? | 22:58 |
| dholbach | ajmitch: no, just people not using listadmin :) | 22:59 |
| cjwatson | mathiaz: could you deal with the openldap merge? although I'm TIL, that's only due to a no-change rebuild and I don't claim to know the package at all well | 23:09 |
| * slangasek looks in amazement at bug #379537. Why in the world is that on acpi-support? | 23:11 | |
| ubottu | Launchpad bug 379537 in acpi-support "Closing lid does not lock screen" [Undecided,New] https://launchpad.net/bugs/379537 | 23:11 |
| persia | Someone thought lid closure was an ACPI event, and picked a package with a likely name? | 23:12 |
| Mez | dholbach: thank gods for "action discard" :D | 23:17 |
| geofft | re-asking when more people are around... is there an MD5SUMS.gpg for the netboot installer? | 23:19 |
| geofft | I only seem to be able to find GPG signatures for the ISOs | 23:19 |
| cjwatson | geofft: no, sorry, no remotely straightforward way to arrange that AFAICS | 23:25 |
| cjwatson | we'd have to special-case it in LP or something ... | 23:26 |
| geofft | aww. Is there a reasonable way for me to get a trust path to the kernel/initrd? | 23:27 |
| geofft | archive.ubuntu.com doesn't seem to do HTTPS. (Hm, how do mirrors get a trustworthy connection anyway?) | 23:28 |
| cjwatson | the kernel is a copy of that stored in the archive | 23:28 |
| cjwatson | the initrd ... hmm. you could fish the .changes file out of LP | 23:28 |
| cjwatson | pain in the arse I realise | 23:28 |
| elmo | geofft: the integrity is assured within the archive itself (signed indices that describe the packages and their expected contents) | 23:29 |
| cjwatson | mirrors generally just use rsync and rely on the archive contents being authenticated, so this is a bit of a problem | 23:29 |
| cjwatson | annoyingly the contents of custom uploads aren't accessible via the LP UI | 23:30 |
| === sconklin is now known as sconklin-afk | ||
| === Mez_ is now known as Mez | ||
| cjwatson | geofft: please do file a bug about this, BTW (on Soyuz, I suppose) - I don't think we can fix it very easily but it is a real problem IMO | 23:46 |
| geofft | cjwatson: yup, will do soon-ish | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!