| crimsun | TheMuso: i'm thinking more along the lines of providing it as a non-default but available stanza so that users can choose it | 00:36 |
|---|---|---|
| TheMuso | crimsun: Right, I have thought that since you proposed it. | 00:36 |
| TheMuso | crimsun: Were you thinking of tweaking the original snippet in any way? | 00:37 |
| TheMuso | If not, I can drop it in, and we may even be able to SRU it for intrepid. | 00:37 |
| crimsun | TheMuso: yeah, need to investigate what max db should be set to (some "sane value", which means lots of feedback required) | 00:38 |
| TheMuso | crimsun: Right. | 00:39 |
| maxb | Is there any standard python parser for debian control files that's faster that debian_bundle.deb822 ? | 00:56 |
| Adri2000 | elmo: I updated my branch of merge-o-matic (and asked Scott to review). it would be cool if you could, with your canonical sysadmin hat on, take a look at it, as I've made changes to address the potential security issues. see #192972 and my latest comment there. thanks | 00:56 |
| slangasek | asac: no ubufox upload yet for bug #308397? | 01:25 |
| ubottu | Launchpad bug 308397 in ubufox "localizable general.useragent.locale pref shipped by ubufox breaks mozilla OS usage stats (ubuntu not counted)" [Critical,Fix committed] https://launchpad.net/bugs/308397 | 01:25 |
| slangasek | calc: there are a number of OOo bugs targeted for 8.04.2, but there haven't been any uploads, or indications in the bug logs that most of these are even in progress - should I simply untarget these? it's certainly too late for a general-purpose OOo SRU to land in time for 8.04.2 | 01:33 |
| === hyperair1 is now known as hyperair | ||
| kirkland | Riddell: hi there, i pushed another revision of screen-profiles, this one with a COPYING file in the tarball | 02:13 |
| calc | slangasek: yea just untarget them is fine | 02:34 |
| === racarr_ is now known as racarr | ||
| === jono_ is now known as jono | ||
| slangasek | calc: ok. are you planning to make time for an OOo SRU at some later time? | 03:33 |
| calc | slangasek: perhaps, but i will be very busy at least for the next 1.5 months | 03:38 |
| * slangasek nods | 03:38 | |
| calc | got a 3.0.1 release coming up to get into jaunty this month then sprint and a week in hamburg at sun | 03:39 |
| === hyperair1 is now known as hyperair | ||
| === emgent_ is now known as emgent | ||
| === emgent_ is now known as emgent | ||
| dholbach | good morning | 06:46 |
| kees | james_w: where's your ppamadison living? I'm curious to see the lplib bits | 07:07 |
| pitti | Good morning | 07:19 |
| directhex | morning, dholbach. i've pencilled in meebey & myself for a session for developer week | 07:20 |
| dholbach | directhex: rock and roll! | 07:21 |
| dholbach | you guys are heroes! | 07:21 |
| directhex | well poopy. looks like another total aircon failure in my machine room | 07:21 |
| directhex | that's a couple of million quid of kit offline | 07:21 |
| ion_ | Hi all | 07:26 |
| === tkamppeter_ is now known as tkamppeter | ||
| === hyperair1 is now known as hyperair | ||
| dholbach | there was a request for having a session about merging at Ubuntu Developer Week - who would like to give it? we still have a few open slots at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep | 08:45 |
| dholbach | also there was a request about python packaging and how to make your application translate-able | 08:45 |
| directhex | pfft, python. who wants that when there's mono? | 08:59 |
| directhex | also, aircon failures hurt | 08:59 |
| * pitti slaps directhex | 09:14 | |
| pitti | python ♥! :-) | 09:14 |
| * directhex hands pitti ironpython | 09:14 | |
| directhex | latest release needs mono 2.2 or some backports to 2.0.1 tho | 09:15 |
| directhex | and this new ikvm package would be the smallest openjdk at our disposal, at ~35 meg on disk :p | 09:23 |
| pitti | tjaalton, tseliot: do you know where the xrandr applet saves its settings? | 09:38 |
| tseliot | pitti: in ~/.config | 09:39 |
| pitti | tjaalton, tseliot: a friend of mine reports X crashes after he tries to log in, and I want him to reset this | 09:39 |
| pitti | ah, monitors.xml? | 09:39 |
| tseliot | pitti: yep | 09:39 |
| tseliot | pitti: is it this bug? https://bugs.launchpad.net/ubuntu/+source/gnome-desktop/+bug/314406 | 09:40 |
| ubottu | Launchpad bug 314406 in gnome-desktop "xrandr plugin of g-s-d crashes on startup" [Medium,Confirmed] | 09:40 |
| StevenK | cjwatson: I find it odd that USUITE in tasksel/Makefile was still intrepid in bzr HEAD. | 09:41 |
| === Skiessio is now known as Skiessi | ||
| === asac_ is now known as asac | ||
| pitti | tseliot: I don't know, it just started to happen recently | 10:26 |
| pitti | tseliot: (intrepid) | 10:26 |
| pitti | tseliot: I asked him some further questions | 10:26 |
| tseliot | pitti: ok | 10:27 |
| tseliot | pitti: let me know if you manage to get the error output so that I can try to fix it | 10:28 |
| Keybuk | persia: where do fridge requests get mailed to now? | 10:32 |
| StevenK | tjaalton: xf86-input-evtouch FTBFS, and is uninstallable. It looks like it needs source porting. | 10:33 |
| === thekorn_ is now known as thekorn | ||
| tjaalton | StevenK: yes, and no news from upstream | 10:39 |
| tjaalton | which reminds me.. pitti: there are a couple of patches for hal in fedora, making devices that declare input.touch to use evdev (which supports touchscreens now), for instance | 10:41 |
| tjaalton | StevenK: hum, that should be easy to fix though | 10:42 |
| StevenK | tjaalton: Fix it? :-) | 10:42 |
| pitti | tjaalton: which we want, I assume? | 10:42 |
| tjaalton | pitti: yep | 10:42 |
| tjaalton | pitti: including the patch by mjg59 which he posted on u-d@ in October | 10:42 |
| tjaalton | or was it u-d-d | 10:43 |
| StevenK | ScottK: Do you think #312659 should be extended to kfreebsd-6 and -7, too? | 10:43 |
| tjaalton | StevenK: looking :) | 10:43 |
| pitti | tjaalton: http://cvs.fedoraproject.org/viewvc//devel/hal/hal-tablet-evdev.patch?view=markup and http://cvs.fedoraproject.org/viewvc//devel/hal/hal-tablet.patch?view=markup ? | 10:43 |
| tjaalton | pitti: yes, and http://cvs.fedoraproject.org/viewvc/devel/hal/hal-joystick.patch?revision=1.2&view=markup | 10:44 |
| StevenK | pitti: Do you also think I should kill kfreebsd-6 and -7 and blacklist them at the same time I kill -5? | 10:44 |
| pitti | tjaalton: I think our joystick patch is better | 10:44 |
| tjaalton | pitti: we have one? | 10:44 |
| pitti | tjaalton: http://bazaar.launchpad.net/~ubuntu-core-dev/hal/ubuntu/annotate/head%3A/debian/patches/07_joystick_detection.patch | 10:45 |
| tjaalton | pitti: yeah, saw that now, nice :) | 10:45 |
| pitti | tjaalton: so, I'll just review all fedora ones and clean harvest then | 10:46 |
| * pitti hugs dholbach for harverst | 10:47 | |
| * dholbach hugs pitti back | 10:47 | |
| tjaalton | pitti: great, thanks | 10:47 |
| Keybuk | pitti: while you're in there, is there a patch for the udev rules location? | 10:50 |
| pitti | Keybuk: not that I can see | 10:50 |
| pitti | Keybuk: there is one for hal dbus permissions | 10:50 |
| pitti | but debian just fixed that, too, I'll merge from them ASAP | 10:50 |
| pitti | (but not today, I finally need to work on the apport retracers) | 10:51 |
| Keybuk | ?! | 10:51 |
| Keybuk | who shot Marco? | 10:51 |
| Keybuk | or do you mean Debian just fixed the dbus permissions? | 10:52 |
| pitti | Keybuk: so the idea is that udev itself and packages ship udev rules in /lib now, and /etc/udev/rules.d is solely for the admin's customizations? | 10:52 |
| Keybuk | pitti: yes | 10:53 |
| Keybuk | however my understanding was that this change was going into Debian "over Marco's dead body" | 10:53 |
| pitti | Keybuk: right, they fixed dbus permissions, not udev rules path | 10:53 |
| Keybuk | he's also refused to adopt standard upstream udev rules | 10:53 |
| pitti | Keybuk: I know a few packages installing udev rules (libsane, libgphoto, etc.); so I guess best is to convert them to use dh_installudev, so that the change can go to debian? | 10:53 |
| Keybuk | that's the easiest way | 10:54 |
| Keybuk | though from a brief glance, neither libsane or libgphoto actually install udev rules now? | 10:54 |
| pitti | I saw your change to that yesterday, so it seems it's supposed to DTRT | 10:54 |
| pitti | Keybuk: ah, right. auto-ACL magic, I remember | 10:54 |
| pitti | (our change is to *drop* udev rules installation) | 10:54 |
| pitti | seems part of my brain is still in holiday mode... | 10:54 |
| Keybuk | of course | 10:55 |
| Keybuk | ironically | 10:55 |
| Keybuk | the FDI becomes a udev rule later on anyway | 10:55 |
| Keybuk | which is a significant part of the reason most distros are going to share a single set of common rules | 10:56 |
| pitti | heh | 10:56 |
| pitti | Keybuk: I hope hal-info will get an fdi2udev script, so that it remains useful for both current and older releases | 10:56 |
| Keybuk | I'm honestly not sure how they intend to do that transition | 10:56 |
| Keybuk | it's not as if fdi and udev rules are easily translatable | 10:57 |
| pitti | well, but all of us distros have long-term releases, so we will need FDIs for the next couple of years still (unless we want to stop updating them) | 10:57 |
| pitti | Keybuk: the format of the hal-info rules is relatively straightforward, though, so I guess for a subset it should be possible with some clever XSLT | 10:58 |
| Keybuk | yeah | 10:58 |
| pitti | many rules are simply "0x1234/0x5678 is a scanner" kind of thing | 10:58 |
| Keybuk | you'll need hal-info as long as you have hal | 10:58 |
| pitti | I guess an udev rule won't look much different | 10:58 |
| pitti | e. g. the hotkey assignments are a different beast, of course | 10:58 |
| pitti | since they need an actual backend which processes those | 10:59 |
| Keybuk | *nods* | 11:00 |
| Keybuk | I still don't think the whole DK thing is entirely well thought out | 11:00 |
| pitti | bryce: good morning | 11:01 |
| tjaalton | StevenK: bah, iz not that easy to fix I'm afraid | 11:02 |
| StevenK | tjaalton: Oh? | 11:03 |
| cjwatson | maxb: we can tweak it easily | 11:04 |
| tjaalton | StevenK: uses some deprecated stuff | 11:05 |
| tjaalton | StevenK: just dropping some obsolete includes and copying xf86OSMouse.h didn't help (like with -mouse) | 11:05 |
| cjwatson | StevenK: I just hadn't run a real update since intrepid; fixed, thanks | 11:06 |
| cjwatson | meh, now I remember why I didn't convert pcmciautils to dh_installudev - the upstream Makefile installs the rules file | 11:08 |
| * cjwatson bodges | 11:08 | |
| cjwatson | dh_installudev is really only suitable for udev rules shipped as packaging modifications | 11:09 |
| pitti | hm, remove it from *.install, and move debian/tmp/etc/udev/rules.d to *.udev won't work? | 11:09 |
| pitti | s/move/put/ | 11:09 |
| Keybuk | pitti: that's a bit evil :_) | 11:10 |
| pitti | Keybuk: why? | 11:10 |
| cjwatson | pitti: sounds like more effort than reimplementing the necessary bits of dh_installudev! | 11:10 |
| Keybuk | cjwatson: your other problem will be that dh_installudev will want to call your file 85-pcmciautils.rules | 11:10 |
| Keybuk | so you'll have to deal with the rename in your maintainer scripts *anyway* | 11:10 |
| cjwatson | aye | 11:10 |
| pitti | cjwatson: sure, you can also change the dest path in debian/pcmciautils.install, but then you'd still need the postinst etc. bits; I don't think it's less effort that moving a line from .install to .udev... | 11:11 |
| Keybuk | so for these kinds of packages, unless it's a trivial dhification, I'm just copying the preinst snippet in to remove unchanged rules and changing the debian/rules file to match the new path | 11:11 |
| pitti | oh, wait | 11:12 |
| cjwatson | pitti: I didn't say it was in .install | 11:12 |
| pitti | .udev doesn't *list* the rules files, it *is* the rules file | 11:12 |
| cjwatson | I said it was installed by the upstream Makefile | 11:12 |
| pitti | so yeah, that won't work then | 11:12 |
| cjwatson | plus what you said | 11:12 |
| pitti | cjwatson: ah, you are installing directly into debian/pcmciautils/, not debian/tmp? | 11:12 |
| cjwatson | yes | 11:13 |
| cjwatson | Keybuk: BTW your debhelper modification doesn't seem to have a maintainer script abort path | 11:13 |
| cjwatson | of course the original udev stuff didn't either | 11:14 |
| pitti | hm, seems like dh_installudev could do with supporting debian/package.udev-files and treat that as file list | 11:14 |
| Keybuk | cjwatson: a what? | 11:14 |
| Keybuk | pitti: it's modelled after installinit, which doesn't have such a thing | 11:15 |
| cjwatson | Keybuk: postrm abort-install or whatever | 11:15 |
| pitti | Keybuk: right, I thought it would be like dh_install or dh_installman | 11:15 |
| Keybuk | cjwatson: IME very few packages bother with it :-/ | 11:15 |
| cjwatson | Keybuk: actually I guess it isn't strictly necessary in this case anyway | 11:15 |
| Keybuk | then again, it took me a very long time to get it right for udev and dpkg, so I'm not entirely surprised :p | 11:15 |
| cjwatson | Keybuk: well, yes, but debhelper getting it right would go a long way :) | 11:16 |
| cjwatson | Keybuk: I notice that udev still seds /var/lib/dpkg/status directly; I thought modern practice was to use dpkg-query | 11:19 |
| Keybuk | modern practice requires you to know the package name :-/ | 11:20 |
| StevenK | cjwatson: It seems kubuntu-kde4 needs to get ripped out too | 11:22 |
| cjwatson | Keybuk: yes, not hard :) | 11:23 |
| pitti | StevenK: kfreebsd-{6,7}> yes, makes sense | 11:23 |
| Keybuk | cjwatson: I'm not also convinced that the dpkg-query method is any better | 11:23 |
| Keybuk | after all, it still has to sed the output of dpkg-query | 11:23 |
| cjwatson | well, it's all based on the theoretical notion that the status file format might one day be changed; but dpkg-query's output could clearly be kept constant across such a change | 11:24 |
| cjwatson | StevenK: I guess so | 11:24 |
| cjwatson | StevenK: is the mobile branch ready for me to try? | 11:24 |
| StevenK | cjwatson: Yeah, it's all commited. | 11:25 |
| Keybuk | of course, the *hope* is that now udev rules are standardised between at least Ubuntu, Fedora/RH, SuSE and Gentoo - more upstreams will just ship them in their package | 11:32 |
| RainCT | calc: ping | 11:36 |
| RainCT | calc: Is bug #66933 really fixed? Because I have that problem on a clean Intrepid install... | 11:37 |
| ubottu | Launchpad bug 66933 in openoffice.org "Recent Documents doesn't include files opened from within OOO" [Low,Fix released] https://launchpad.net/bugs/66933 | 11:37 |
| cjwatson | Keybuk: is there a standard dependency or breaks or whatever for packages shipping new-location udev rules? | 11:42 |
| Keybuk | cjwatson: if they dependended on udev before, I've updated it | 11:45 |
| Keybuk | but I haven't added one where one didn't exist before | 11:45 |
| Keybuk | a lot of things ship udev rules without depending on udev | 11:45 |
| Keybuk | which makes it complicated :p | 11:45 |
| cjwatson | Keybuk: what should the version be - >> 136-1? | 11:46 |
| cjwatson | er >= | 11:46 |
| Keybuk | >= 136-1 | 11:46 |
| cjwatson | ok, pcmciautils done in my local tree then | 11:47 |
| soc | hi | 11:52 |
| Keybuk | debhelper is 7.0.17ubuntu2 | 11:53 |
| soc | i have patches against /var/lib/gconf/defaults/%gconf-tree.xml and /var/lib/gconf/debian/defaults/%gconf-tree.xml | 11:53 |
| Keybuk | if you use cdbs, 0.4.38 has the dh_installudev call | 11:53 |
| soc | whom should i send them? | 11:53 |
| cjwatson | StevenK: tasksel updated - any problem with me uploading it now or do I need to wait? | 11:59 |
| cjwatson | actually I guess it really ought to be now since the seeds have already been changed | 11:59 |
| cjwatson | and I see that mobile-meta has been uploaded | 12:00 |
| cjwatson | done | 12:01 |
| StevenK | cjwatson: Thanks! | 12:02 |
| StevenK | cjwatson: I'll upload livecd-rootfs tomorrow | 12:02 |
| ScottK | StevenK: I think extending to the other FreeBSD sources is reasonable. I only tripped over that one because of trying to get rid of old libdb versions. | 12:13 |
| StevenK | ScottK: Yup | 12:14 |
| soc | mhh weird | 12:16 |
| soc | i tried to create a patch, but the diff is always double the size of the original/changed file | 12:17 |
| soc | when i view the diff, it first removes _the whole_ original file and then adds _the whole_ new file, although just a few characters have been changed | 12:17 |
| broonie | soc: line endings change, probably. | 12:18 |
| soc | but i want to have a diff with just the lines which were changed, not the whole thing | 12:18 |
| soc | how can i ingore them? | 12:18 |
| === nhandler_ is now known as nhandler | ||
| soc | it's an xml file, btw | 12:18 |
| broonie | You're almost certainly actually changing all the lines in the file. | 12:19 |
| broonie | Possibly by changing the line endings, possibly some other way. | 12:19 |
| soc | maybe tab to space? | 12:19 |
| soc | does gedit make that automatically? | 12:19 |
| broonie | Might, but I'd be a bit surprised. | 12:19 |
| soc | i hate it ... always the latest step fails for me ... | 12:21 |
| soc | :-/ | 12:21 |
| soc | last step | 12:22 |
| soc | maybe something else is wrong... this is my line: diff -E --strip-trailing-cr -a --text -u /var/lib/gconf/debian.defaults/%gconf-tree.xml %gconf-tree.xml > debian.defaults-%gconf-tree.xml.diff | 12:22 |
| ahasenack | I wanted to do a distribution upgrade test with some update candidate packages I have for distro+1, is there some option for do-release-upgrade to use an extra repository? I would place my packages in this extra repository | 12:22 |
| ahasenack | for example, I want to test an upgrade from hardy to intrepid but I want it to consider my local repository as well | 12:23 |
| cjwatson | soc: try viewing the diff in an editor configured to show special characters | 12:24 |
| soc | which editor could i use for that? | 12:24 |
| cjwatson | soc: well, I use vim but you may not be comfortable with that if you're used to gedit :) do some research | 12:29 |
| soc | ok | 12:30 |
| cjwatson | soc: or you could run it through cat -A | 12:30 |
| soc | ok | 12:31 |
| === ember_ is now known as ember | ||
| === The_Company is now known as Company | ||
| maswan | \sh: Hah. I finally managed to get tickets to karlsruhe. :) | 13:02 |
| ahasenack | mvo: hi, is there a way for me to supply an extra apt repository for consideration by do-release-upgrade during a distro upgrade? | 13:06 |
| \sh | maswan: when? :) | 13:07 |
| maswan | \sh: 13th to early morning at the 16th | 13:08 |
| maswan | \sh: No plans for the 13th so far, might be meeting dinners etc at the other days though. | 13:08 |
| \sh | maswan: 13th sounds great :) | 13:09 |
| apw | so who owns the debian-installer in ubuntu | 13:10 |
| cjwatson | apw: *wave* | 13:11 |
| apw | cjwatson, heh is there anything you don't own? | 13:12 |
| mvo | ahasenack: not easily unfortuntaely. what is the use-case? | 13:12 |
| cjwatson | apw: yes :-) | 13:13 |
| cjwatson | (fortunately) | 13:13 |
| maswan | \sh: see you then, then. :) | 13:13 |
| ahasenack | mvo: updating some distro+1 packages, and checking that that distro upgrade from distro to distro+1 doesn't break. I would need do-release-upgrade to consider this other repository with the test packages | 13:13 |
| cjwatson | apw: something up that I can help with? | 13:14 |
| apw | cjwatson, Hobbsee reported that a dist-upgrade installed a lilo on her grub machine, looking at it it seems that the 32 bit intrepid installs are installing both grub and lilo, but 64 bit is only installing grub ... the initial thought was our recommends were causing it, but not as 32bit and 64 bit differ | 13:14 |
| cjwatson | apw: well, whether lilo or grub is installed depends on the installation parameters - for example if /boot is on LVM then lilo's needed | 13:15 |
| apw | so i am wondering how d-i decides which to install, and why it might install both? our kernel recommends do mention both but as i say 64bit cd's don't seem to install lilo but 32bit do | 13:15 |
| mvo | ahasenack: there is a good way to test this via the noninteractive upgrade tester in do-release-upgrade. its not exactly greatly documented, but this is probably a good opportunity to change that :) | 13:15 |
| cjwatson | I'm very surprised about both being installed, and would like to see the installer log | 13:15 |
| cjwatson | (/var/log/installer/syslog) | 13:15 |
| ahasenack | mvo: how can I try it? | 13:15 |
| mvo | ahasenack: how urgent is it? i.e. can we talk about it a little bit later (~2h)? | 13:15 |
| ahasenack | mvo: sure | 13:15 |
| apw | my 32bit sample is on a single normal ext3 disk and is using the grub by default | 13:15 |
| mvo | ahasenack: its in the update-manager bzr branch | 13:16 |
| apw | cjwatson, typically i am remote from that laptop today ... i will get that off and to you | 13:16 |
| cjwatson | apw: Recommends are ignored while installing the kernel during initial installation, so it won't be that | 13:16 |
| apw | Hobbsee, do you have your 32bit lilo/grub machine to hand? If so could you get the /var/log/installer/syslog off it and shove it into bug #314004 | 13:17 |
| ubottu | Launchpad bug 314004 in linux "Lilo gets installed on dist-upgrades, due to the kernel image recommending it. Is this intentional?" [Medium,In progress] https://launchpad.net/bugs/314004 | 13:17 |
| cjwatson | apw: http://bazaar.launchpad.net/~ubuntu-core-dev/grub-installer/ubuntu/annotate/head%3A/debian/isinstallable is what controls whether grub or lilo is installed | 13:17 |
| cjwatson | apw: if that script exits zero, then grub's used, otherwise lilo | 13:17 |
| cjwatson | (approximately) | 13:17 |
| apw | thanks, to basically its as expected, only one should be installed | 13:17 |
| cjwatson | apw: but that doesn't influence dist-upgrades | 13:17 |
| apw | from memory it definatly put both on in the same original install block | 13:18 |
| cjwatson | that's incredibly weird | 13:18 |
| apw | no i assume Hobbsee got the update just because there is a lilo update in jaunty and it was installed | 13:18 |
| cjwatson | I'd be astonished if the discrepancy were really due to i386 vs. amd64 | 13:18 |
| cjwatson | I think it's more likely to be something more subtle | 13:18 |
| Hobbsee | apw: i got it installed at the point where I did the dist-upgrade. | 13:19 |
| apw | cjwatson, if Hobbsee isn't able to get her logs, i will try and be where the other laptop is and get it off | 13:19 |
| cjwatson | the thing is that the kernel recommends lilo | grub | 13:19 |
| cjwatson | not both - either should satisfy it | 13:19 |
| Hobbsee | apw: should be http://pastebin.com/f81055d5 | 13:19 |
| cjwatson | now, I do think the kernel should recommend grub | lilo instead, switching the order | 13:19 |
| cjwatson | but that's cosmetic from the point of view of this bug | 13:19 |
| directhex | elilo! | 13:19 |
| apw | cjwatson, can i tell if there was a lilo update in jaunty | 13:19 |
| cjwatson | apw: shouldn't be relevant | 13:19 |
| cjwatson | apw: rmadison lilo | 13:20 |
| Hobbsee | (i didn't check whether it had installed lilo in the original install of intrepid) | 13:20 |
| apw | Hobbsee, i amhappy it installed lilo in the update. just want to know if it could also have been installed before dist-upgrade and was simply upgraded | 13:20 |
| Hobbsee | apw: could have been | 13:20 |
| apw | i think pgraner said his 32bit install had both too | 13:20 |
| cjwatson | apw: simply changing the version of lilo in jaunty wouldn't cause it to be magically installed | 13:21 |
| apw | so its something more than just one or two of us | 13:21 |
| apw | cjwatson, right, but it changing would make it upgrade at dist-upgrade which might explain why it was noticed by Hobbsee | 13:21 |
| cjwatson | I think this is related to installing with desktop vs. alternate/server | 13:21 |
| apw | and yes it is differnt | 13:21 |
| apw | lilo | 1:22.8-4ubuntu1 | intrepid | source, amd64, i386 | 13:21 |
| apw | lilo | 1:22.8-7ubuntu1 | jaunty | source, amd64, i386 | 13:21 |
| apw | so ... if she had had the same as me, that both were on, then lilo would be downloaded and installed as part of an update | 13:22 |
| Hobbsee | installer log added to bug. | 13:22 |
| apw | Hobbsee, perfect | 13:22 |
| cjwatson | this is interesting, lilo is installed as part of desktop | 13:22 |
| cjwatson | that would explain why ubiquity isn't removing it | 13:22 |
| cjwatson | mvo: update-manager might have to arrange to remove lilo :-( | 13:23 |
| cjwatson | (if unused ...) | 13:23 |
| Hobbsee | Setting up lilo (1:22.8-4ubuntu1) ... | 13:23 |
| Hobbsee | right, so i did get it in the intrepid version. | 13:23 |
| cjwatson | your initial install was intrepid desktop | 13:23 |
| apw | so can we tell from the log what slurped it in? | 13:24 |
| mvo | cjwatson: sure, that can be arranged | 13:24 |
| cjwatson | not from the log but I can tell in other ways, please wait | 13:24 |
| pgraner | apw: it installed it on a Intrepid->Jaunty upgrade | 13:24 |
| cjwatson | pgraner: but it was already installed on intrepid, I'm fairly certain# | 13:24 |
| apw | pgraner, what he said | 13:24 |
| cjwatson | therefore focusing on the upgrade is an error | 13:25 |
| apw | there was a new one in jaunty so if you had it already you get eh new one, even though you don't want it | 13:25 |
| pgraner | cjwatson: it might have been, I never noticed it. In fact the only way I noticed was when I got the "Configure LILO" screen from apt-get | 13:25 |
| cjwatson | oh goodness, yes, you would | 13:25 |
| cjwatson | due to the large-memory thing | 13:25 |
| cjwatson | yargh, lovely bug that's now enshrined on lots of systems | 13:25 |
| cjwatson | apw: I bet your intrepid-installed system without lilo was installed using the text-mode installer, and your system with lilo was installed using the desktop installer | 13:26 |
| cjwatson | apw: can you confirm? | 13:26 |
| cjwatson | so it's true that the order of the kernel recommends is what caused this, but really, accident ... | 13:27 |
| apw | cjwatson, i can confirm the 'broken' one was installed virgin from a desktop CD image | 13:27 |
| apw | the working one i am struggling to remember if it was hardy CD installed and updated or reinstalled from the intrepid 64 bit CD | 13:28 |
| cjwatson | let me give you a potted summary of what happened, then | 13:28 |
| apw | can i tell at all | 13:28 |
| cjwatson | yes, /var/log/installer/syslog will indicate, if only from the kernel version | 13:28 |
| cjwatson | in intrepid, we enabled recommends by default; this had some speedbumps but largely appeared to be working OK | 13:28 |
| apw | Oct 21 12:47:25 ubuntu kernel: Inspecting /boot/System.map-2.6.24-19-generic | 13:28 |
| apw | so hardy then upgraded me thinks | 13:28 |
| cjwatson | (therefore any installs from earlier than intrepid are entirely unaffected by this) | 13:28 |
| cjwatson | the alternate/server CD (d-i) installs as I described above, by explicitly choosing whether to install grub or lilo depending on installation parameters; no problem there | 13:29 |
| cjwatson | however, the desktop installer works quite differently | 13:29 |
| cjwatson | we put a "live filesystem" onto the desktop CD, a preinstalled filesystem image with lots of packages on it that's then copied to the target system | 13:30 |
| cjwatson | obviously, there are some things on this image that shouldn't end up on the target system, such as the installer itself | 13:30 |
| cjwatson | so we copy the filesystem image file-by-file, and then remove unwanted packages using apt (this is still a lot quicker than installing them all from scratch, and allows us to fit an installable live system onto a single CD) | 13:31 |
| cjwatson | the set of packages we remove is computed by taking the set-difference between a "desktop install" and the full live filesystem package list, plus one or two other tweaks | 13:31 |
| cjwatson | (things like language packs, removing unused kernels if there's more than one available, etc.) | 13:32 |
| apw | cjwatson, a sneak solution indeed | 13:32 |
| cjwatson | for various reasons, the script that builds the live filesystem (in the livecd-rootfs package) installs the kernel before it says "right, that's it, what I've got now is a desktop install" | 13:32 |
| cjwatson | and, due to the kernel's Recommends, the bootloader (in this case lilo) is considered as part of the desktop install, and not removed by the installer | 13:33 |
| cjwatson | the installer notices that it needs grub, and therefore arranges for it to stay installed as well | 13:33 |
| cjwatson | and voila, two bootloaders | 13:33 |
| cjwatson | I recommend three fixes for this, and will update the bug accordingly: | 13:34 |
| cjwatson | 1) ubiquity should arrange to remove all bootloaders except for the one it's installing | 13:34 |
| cjwatson | 2) linux should switch the order of its recommends to suit the modern age (not required given 1, but probably sensible anyway, and I think there may well be other bugs about this) | 13:34 |
| cjwatson | 3) update-manager should clean up this mess on upgrade | 13:35 |
| cjwatson | (done) | 13:35 |
| apw | ok ... so i can handle the linux(2) side under the linux task | 13:36 |
| cjwatson | yep | 13:36 |
| apw | will you make tasks for the rest? | 13:36 |
| cjwatson | yes, already have | 13:36 |
| apw | cool. will get on it. does this need doing for intrepid, or is it too late to matter | 13:37 |
| apw | (we are going to make new CD's I assume for the intrepid update?) | 13:37 |
| cjwatson | too late for intrepid, and we weren't planning new CDs | 13:37 |
| cjwatson | we normally only do new CDs for point releases, which are normally only for LTSes | 13:38 |
| apw | ok so then i'll just spin the change on jaunty | 13:38 |
| cjwatson | and they're a lot of work | 13:38 |
| cjwatson | yeah, jaunty will be fine | 13:38 |
| apw | heh, yeah i did notice a lot of moaning when they were being spun last time | 13:38 |
| cjwatson | Hobbsee: thanks for spotting this | 13:38 |
| Hobbsee | cjwatson: glad you can fix it :) | 13:38 |
| mvo | cjwatson: is there a bugnumber for this? I can do the work in u-m, just want to know a bit more about the problem (I can read scrollback if it was discussed here of course) | 13:41 |
| apw | mvo, bug #314004 | 13:42 |
| ubottu | Launchpad bug 314004 in linux "Lilo gets installed on dist-upgrades, due to the kernel image recommending it. Is this intentional?" [Medium,In progress] https://launchpad.net/bugs/314004 | 13:42 |
| apw | cjwatson, thanks for the insight into d-i's guts | 13:43 |
| cjwatson | apw: ubiquity's guts in this case | 13:43 |
| cjwatson | (you're welcome) | 13:43 |
| cjwatson | fixed for next upload, pending testing | 13:45 |
| apw | cjwatson, kernel patch out for review | 13:51 |
| Keybuk | cjwatson: heh, I spotted it the other day too but hadn't got around to mentioning it yet | 13:52 |
| Keybuk | james_w: around? | 14:02 |
| james_w | hey Keybuk | 14:03 |
| Keybuk | bzr build-deb appears to be ignoring my .bzr-builddeb/local.conf :-/ | 14:03 |
| Keybuk | quest ubuntu% cat .bzr-builddeb/local.conf | 14:03 |
| Keybuk | [BUILDDEB] | 14:03 |
| Keybuk | source-builder = dpkg-buildpackage -rfakeroot -uc -us -S -i'(?:/|^)(?:test|\.gitignore)(?:/|$)' | 14:03 |
| Keybuk | yet, when I do bzr bd -S I get lots of | 14:03 |
| Keybuk | dpkg-source: error: cannot represent change to udev-136/test/sys/devices/virtual/block/loop5/subsystem: | 14:03 |
| Keybuk | followed by (eventually) | 14:03 |
| Keybuk | dpkg-source: unrepresentable changes to source | 14:03 |
| Keybuk | dpkg-buildpackage: failure: dpkg-source -b udev-136 gave error exit status 1 | 14:03 |
| james_w | Keybuk: could you pastebin the full output please? | 14:04 |
| james_w | Keybuk: is the file versioned? | 14:04 |
| Keybuk | no | 14:04 |
| Keybuk | the full output is ~4 GB | 14:05 |
| james_w | ok, the top few lines should do | 14:05 |
| persia | Keybuk, ubuntu-news-team@lists.ubuntu.com, I think. | 14:05 |
| Keybuk | the files its complaining about are versioned, but not in the tarball | 14:05 |
| james_w | sorry, is .bzr-builddeb/local.conf versioned? | 14:05 |
| Keybuk | http://paste.ubuntu.com/101665/ | 14:05 |
| Keybuk | james_w: yes | 14:06 |
| james_w | Keybuk: ah, it shouldn't be, it's local overrides | 14:06 |
| Keybuk | what file do I put that line in instead? | 14:06 |
| james_w | there is no way to set per-package overrides yet currently unfortunately | 14:07 |
| james_w | you can either move that file to ~/.bazaar/builddeb.conf | 14:07 |
| Keybuk | that means nobody else will be able to build a udev package from bzr other than me though | 14:07 |
| Keybuk | no? | 14:07 |
| Keybuk | which kinda defeats the object :p | 14:07 |
| james_w | or unversion it ("bzr rm --keep") | 14:07 |
| james_w | don't put it in the local file then | 14:07 |
| james_w | bzr mv .bzr-builddeb/local.conf .bzr-builddeb/global.conf | 14:08 |
| james_w | er, default.conf sorry | 14:08 |
| Keybuk | Building the package in ../build-area/udev-136, using dpkg-buildpackage -rfakeroot -uc -us -S | 14:08 |
| Keybuk | no change | 14:08 |
| Keybuk | still ignores it | 14:08 |
| james_w | python -c "from bzrlib.workingtree import WorkingTree; print WorkingTree.open_containing('.')[0].path2id('.bzr-builddeb/default.conf')" | 14:12 |
| james_w | what does that print? | 14:12 |
| Keybuk | local.conf-20081222123037-mhcrh47mqkmhxuj7-2 | 14:13 |
| lool | james_w: Re debbug #426419 > no patch; did we actually patch this? | 14:16 |
| Keybuk | tkamppeter: so I'm looking at hplip's udev rules ... and I'd like to take your crack pipe away | 14:17 |
| Keybuk | heh | 14:25 |
| Keybuk | in fact | 14:25 |
| Keybuk | I can just delete the rules file entirely | 14:25 |
| Keybuk | because all it does is put things into the scanner group | 14:25 |
| Keybuk | which we, err, don't have | 14:25 |
| liw | Keybuk, hmm, I have it | 14:25 |
| ogra | tills crack pipe ? | 14:25 |
| liw | gid 105, so probably manually created | 14:25 |
| Keybuk | liw: it goes away in jaunty | 14:25 |
| liw | Keybuk, ah | 14:25 |
| james_w | Keybuk: ah, I see the issue. builder commands can't be specified in those files. The rationale was that it was arbitrary code execution, but that doesn't seem like a good one. | 14:26 |
| Keybuk | james_w: it should be at least possible to specify the ignore string? | 14:26 |
| james_w | Keybuk: yeah, but does everyone's builder command accept that option? | 14:27 |
| pitti | liw: it isn't necessary to be in the scanner group since hardy any more (replaced by automatic ACLs); but of course on upgrades your user isn't removed from it | 14:30 |
| james_w | lool: seems we didn't | 14:30 |
| james_w | lool: http://patches.ubuntu.com/by-release/ubuntu/a/acpid/acpid_1.0.4-5ubuntu6.patch.bz2 is the patch referred to in the initial debian bug report | 14:31 |
| Keybuk | james_w: another option would be files you could not export across to the build area? | 14:32 |
| james_w | lool: well, we patched acpid to check for the file, but didn't patch it to fix the ubuntu bug I referenced | 14:32 |
| james_w | Keybuk: that could work. | 14:34 |
| james_w | I want to do something about the builder command handling anyway, as it's quite irritating, but I'm not sure what the best approach to take is | 14:34 |
| Keybuk | cjwatson: you remember how we couldn't figure out why hwclock wasn't working properly? | 14:35 |
| Keybuk | well, I just looked at the udev rules | 14:35 |
| Keybuk | KERNEL=="rtc", ... | 14:35 |
| ScottK | slangasek: Is there any chance of us getting openldap off of db 4.2 in this cycle? 4.3 just got removed (thanks StevenK) and 4.4 is close behind. I think 4.2 is doable if slapd can move to a later db. | 14:35 |
| Keybuk | yeeeeah, that won't work | 14:35 |
| slytherin | Can any archive admin please process these bugs - 314470 314487 314505? | 14:35 |
| cjwatson | Keybuk: ah, heh | 14:37 |
| cjwatson | good catch | 14:37 |
| Keybuk | cjwatson: tbh, I should probably just read through all of the hwclock code, including that in the kernel | 14:38 |
| Keybuk | and do it from scratch again | 14:38 |
| Keybuk | since last time we briefly looked we found that must of it wasn't necessary anymore | 14:38 |
| Keybuk | (most of our changes esp.) | 14:38 |
| cjwatson | Keybuk: failing all else we can do it at the sprint | 14:50 |
| cjwatson | slytherin: done. (no need to ask me about binaries later, we'll do them) | 14:51 |
| slytherin | cjwatson: thanks. :-) | 14:52 |
| StevenK | If that's removal, I'm guessing NBS is going to be enormous once it regens, and I'll take care of it | 14:52 |
| cjwatson | no, syncs | 14:54 |
| dholbach | would somebody like to give a session about backtraces and debugging stuff at Ubuntu Developer Week? | 14:55 |
| dholbach | we still have some open slots available: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep | 14:55 |
| === AstralJa1a is now known as AstralJava | ||
| Keybuk | cjwatson: ah, you've never experienced the Berlin nightlife ;) | 14:57 |
| Keybuk | I'm not expecting this to be a productive sprint <g> | 14:57 |
| cjwatson | Keybuk: as far as I'm concerned, Berlin is my chance to spend a week getting uninterrupted nights' sleep; nightlife is not high on my agenda | 14:58 |
| Keybuk | cjwatson: :o) | 14:59 |
| slytherin | cjwatson: how come the bugs didn't get marked as fix released? Or do you need to do that manually? | 15:00 |
| slytherin | oops, I spoke too earley. | 15:00 |
| slytherin | early | 15:00 |
| cjwatson | slytherin: indeed ... | 15:02 |
| cjwatson | (and yes, I have to do that by hand, but I did so before saying anything to you) | 15:02 |
| cjwatson | we have a script that deals with bug closures but it doesn't work for requests of syncs of new packages | 15:03 |
| slytherin | hmm | 15:05 |
| slytherin | cjwatson: do you usually handle 'move to universe' kind of bugs? | 15:06 |
| cjwatson | slytherin: ~ubuntu-archive does, I largely do archive work when I'm too tired to program properly :-) | 15:06 |
| cjwatson | latching onto me for routine maintenance is a mistake | 15:06 |
| slytherin | ok. | 15:06 |
| cjwatson | we process the queue. Unless it's super-urgent, there's no need to poke explicitly | 15:07 |
| === seb128_ is now known as seb128 | ||
| slytherin | ok. it is not super urgent. | 15:07 |
| Keybuk | cjwatson: talking of which, since it's generally impolite to shove your own uploads through NEW ... :p | 15:09 |
| cjwatson | Keybuk: damn, and I was enjoying the way my jaunty system is largely working at the moment | 15:10 |
| Keybuk | I have _tested_ this, you know ;) | 15:10 |
| cjwatson | Keybuk: not that it hugely matters, but please set the priorities of the -dev packages to optional for your next upload | 15:12 |
| Keybuk | cjwatson: pushed for next tiome | 15:14 |
| pitti | Keybuk: so you *tested* that it'll break everyone's system :) | 15:14 |
| Keybuk | pitti: :o) | 15:14 |
| cjwatson | Keybuk: I think you broke udev-udeb | 15:14 |
| Keybuk | cjwatson: oh? | 15:15 |
| cjwatson | Keybuk: doesn't it need the libraries? | 15:15 |
| Keybuk | shouldn't do, it's built -static | 15:15 |
| cjwatson | ah, ok | 15:15 |
| cjwatson | Keybuk: what links against libudev0? udev doesn't seem to depend on it | 15:15 |
| Keybuk | cjwatson: DeviceKit, HAL, etc. | 15:15 |
| cjwatson | ah, but not udev itself? | 15:16 |
| Keybuk | right | 15:16 |
| cjwatson | ok | 15:16 |
| Keybuk | it's built-in to udev itself | 15:16 |
| Keybuk | I'm not entirely, honestly, sure *why* | 15:16 |
| cjwatson | I'm deliberately going to upload d-i before this so that I have a working d-i to test other things with, mind you :) | 15:16 |
| slytherin | cjwatson: do you mind if I bug you for few more syncs after I go home. That will be about 2 hours from now. | 15:17 |
| cjwatson | slytherin: don't bother, I'll be away by then | 15:17 |
| cjwatson | slytherin: please don't bug me personally | 15:17 |
| slytherin | cjwatson: ok. | 15:17 |
| slytherin | cjwatson: I hope you will clear all the binaries from new queue before you leave. :-) | 15:18 |
| cjwatson | slytherin: not necessarily. | 15:18 |
| cjwatson | Keybuk: accepted | 15:18 |
| tkamppeter | Keybuk, what do you mean with "and I'd like to take your crack pipe away"? | 15:19 |
| Keybuk | tkamppeter: welll | 15:19 |
| Keybuk | on upgrade you | 15:19 |
| cjwatson | slytherin: (although as it happens I believe that I have done; but I don't really appreciate being treated this way) | 15:19 |
| Keybuk | 1) rename the udev rules from a correct name to a bizarre one | 15:19 |
| Keybuk | 2) replace the old rules with a dummy file instead of nothing | 15:19 |
| Keybuk | 3) install a new dummy file with a name that appears to have never been used | 15:20 |
| slytherin | cjwatson: Sorry, didn't mean to. | 15:21 |
| cjwatson | I'm doing archive work because it seems to be a bit backed up and because I'm feeling helpful; that doesn't mean that I'm going to rearrange my life to be around at awkward-for-me hours so that non-urgent things can be done today rather than tomorrow, or that I want everyone to pile on and ask me to do such-and-such | 15:22 |
| slytherin | cjwatson: I understand. | 15:23 |
| cjwatson | thank you | 15:23 |
| Keybuk | pitti: I'm not going insane, right? | 15:25 |
| Keybuk | neither libgphoto2-2 or libsane actually ship udev rules anymore? | 15:26 |
| soc | what do you think of that dpi-widget? the thing looks like crap at the moment, but i hopt the intent gets clear.... http://ochsenreither.de/screenshots/dpi-widget.png | 15:27 |
| pitti | Keybuk: confirmed; I dropped them in hardy | 15:27 |
| Keybuk | pitti: mind if I drop the /etc/udev/rules.d directory from the packages then? | 15:28 |
| Keybuk | cause it keep showing up in Contents.gz/dpkg -S :p | 15:28 |
| pitti | Keybuk: they still ship the directory /etc/udev/rules.d | 15:29 |
| Keybuk | yeah they do | 15:30 |
| Keybuk | mind if I remove that? :) | 15:30 |
| pitti | no, not at all | 15:30 |
| pitti | probably just a leftover from package.dirs | 15:31 |
| Keybuk | it is | 15:31 |
| Keybuk | thanks | 15:31 |
| pitti | (the misbehaviour of using dh_installdirs together with dh_install is so widespread :( ) | 15:31 |
| seb128 | pitti: did you read about guest session freezing the computer on jaunty? | 15:32 |
| cjwatson | it can be reasonable if you're installing other files by hand too | 15:32 |
| Keybuk | misbehaviour? | 15:33 |
| cjwatson | dh_install creates directories for itself, so dh_installdirs is often unnecessary when you're using it | 15:35 |
| cjwatson | indeed pretty much all debhelper commands create directories for themselves | 15:35 |
| cjwatson | dh_installdirs is just a shorthand for when you need a manual mkdir for some other reason | 15:35 |
| pitti | Keybuk: yes, I often see .dirs containing "usr/bin" and "usr/lib", for example | 15:35 |
| cjwatson | that's probably due to dh-make | 15:35 |
| pitti | which is generated by upstream make install anyway | 15:35 |
| pitti | right | 15:35 |
| Keybuk | pitti: ugh, gphoto FTBFS :-/ | 15:43 |
| pitti | new kernel headers? | 15:44 |
| Keybuk | libtoolness | 15:44 |
| pitti | yay | 15:44 |
| Keybuk | nothing worse than touching a package and having it blow up in a completely unrelated way that you happen to be the best person to fix | 15:44 |
| pitti | *chuckle* | 15:45 |
| Keybuk | cjwatson: I spotted a udev bug you didn't ;) libudev0.shlibs was wrong | 15:46 |
| cjwatson | *grin* I just looked at the contents TBH | 15:46 |
| slangasek | ScottK: moving openldap off 4.2 requires moving to openldap 2.4.12 or later; I don't have any objections to doing this, but the impetus isn't going to come from Debian, which is frozen at 2.4.11 for lenny | 16:05 |
| ScottK | slangasek: OK. It'd be handy, but I suspect it's a fiddly enough update that someone familiar with the package ought to do it. I think it's the only real blocker for 4.2 removal. | 16:09 |
| slangasek | Is sasl migrated? I remember there was resistance in Debian to getting sasl moved off of db 4.2 as well | 16:09 |
| ScottK | Yes. We did that one. | 16:10 |
| ScottK | Debian did too. | 16:10 |
| * slangasek nods | 16:10 | |
| ScottK | I think cyrus imap still needs to be done. | 16:11 |
| ScottK | vorian is looking into the other 4.2 rdepends. | 16:11 |
| slangasek | ArneGoetje: hardy langpacks don't appear to be updated yet? | 16:11 |
| ArneGoetje | slangasek: the tarball is not ready yet... | 16:19 |
| ArneGoetje | slangasek: rosetta is a bit slow with exporting. | 16:19 |
| slangasek | ArneGoetje: ok. ETA? | 16:20 |
| ArneGoetje | slangasek: dunno. anytime soon. | 16:20 |
| slangasek | ArneGoetje: is there somewhere I can see the status of the tarball export (i.e., whether it's done or not), and how soon do you think I should escalate to the LP folks if it's not done (i.e., when do we conclude that the export is broken instead of just slow)? | 16:21 |
| ArneGoetje | slangasek: https://translations.edge.launchpad.net/ubuntu/hardy/+language-packs | 16:23 |
| ArneGoetje | slangasek: when the tarball is ready it will be top of the list and say "Full Export" | 16:23 |
| slangasek | ArneGoetje: ok | 16:23 |
| ArneGoetje | slangasek: but for us non-LP folks it's impossible to say what the export script is doing. | 16:24 |
| ArneGoetje | slangasek: jtv mentioned to me that it might take until Friday morning UTC... I just hope it won't take that long. | 16:25 |
| calc | RainCT: hmm looking at it | 16:25 |
| calc | RainCT: i believe there a few issues here | 16:26 |
| slangasek | ArneGoetje: hmm, that's rather longer than I'm comfortable with; I'll poke to see if there's some way it could possibly be made faster for us | 16:26 |
| calc | RainCT: if you open the file via the gnome file dialog inside OOo it should add it to the menu (last i checked anyway) | 16:26 |
| calc | RainCT: if you open it via OOo recent documents menu it doesn't (iirc) | 16:27 |
| calc | RainCT: and it doesn't resort properly which is another bug report | 16:27 |
| ArneGoetje | slangasek: good luck | 16:28 |
| asac | slangasek: an update on ubufox. upstream says we get counted. so its not as bad as it seems and can wait until after .2 i think; when is release date for that? | 16:30 |
| tjaalton | hum, why does initscripts ship both /etc/network/if-up.d/mountnfs{,.orig}? | 16:31 |
| tjaalton | at least on hardy | 16:31 |
| asac | tjaalton: without looking i would say that its a merge bug ;) | 16:31 |
| slangasek | asac: release date for .2 is Jan 22; I'll unmilestone the bug then, thanks | 16:33 |
| asac | cheers | 16:33 |
| mkrufky | from within a gnome-based app, how can i tell if we are about to suspend, or have just resumed? | 16:33 |
| tjaalton | asac: possibly | 16:33 |
| tjaalton | asac: introduced in 2.86.ds1-14.1ubuntu26 (gutsy) :/ | 16:41 |
| === Mirv_ is now known as Mirv | ||
| Keybuk | cjwatson: you're doing pcmciautils, right? | 17:02 |
| cjwatson | yeah | 17:02 |
| cjwatson | probably won't upload 'til tomorrow though, sorry | 17:02 |
| Keybuk | np | 17:02 |
| Keybuk | I wonder how much of that is needed | 17:03 |
| Keybuk | (the upstream diff of the rules, I mean) | 17:06 |
| Keybuk | if it's all valid, it should be just pushed upstream, including the move to /lib/udev/rules.d | 17:06 |
| Keybuk | oh, drop the -Q from modprobe | 17:06 |
| cjwatson | -Q no longer needed? | 17:07 |
| Keybuk | right | 17:07 |
| cjwatson | upstream already released pcmciautils 015 that I think included most of our changes, but I haven't got round to packaging it | 17:07 |
| Keybuk | ahh, k | 17:07 |
| cjwatson | well, I did in Debian but haven't merged, oops :) | 17:08 |
| cjwatson | still a few Makefile changes actually, I should do something about that | 17:08 |
| slangasek | mkrufky: I'm not sure you can; why do you need to? | 17:11 |
| mkrufky | slangasek: for instance.... if totem is streaming while the user suspend's his pc, totem needs to stop / start the stream upon resume, in order for it to continue working | 17:12 |
| slangasek | mkrufky: "streaming" being a network stream? | 17:12 |
| mkrufky | dvb-t / atsc | 17:13 |
| mkrufky | digital television | 17:13 |
| slangasek | hmm | 17:13 |
| mkrufky | the device loses power when in suspend | 17:13 |
| slangasek | typically this is handled via suspend/resume hooks for the hardware, not from the GUI | 17:13 |
| mkrufky | the device driver reinitializes the device upon resume | 17:13 |
| mkrufky | the driver itself does the right thing already | 17:13 |
| mkrufky | but the app needs to steer the ship | 17:13 |
| slangasek | right; I think the better abstraction is if totem can detect that the device driver has been reinitialized? | 17:14 |
| slangasek | since that could in theory happen outside of suspend/resume, and it would be nice if totem were robust against it? | 17:14 |
| mkrufky | hmm | 17:15 |
| mkrufky | there's currently no way for userspace to determine that fact | 17:15 |
| mkrufky | ...but i thought that dbus would provide some messaging system that would broadcast (we just resumed) to all applications | 17:16 |
| mkrufky | am i wrong? | 17:16 |
| slangasek | I don't know, really | 17:17 |
| mkrufky | :-/ okay | 17:17 |
| slangasek | you could check with dbus-monitor | 17:17 |
| mkrufky | ...or even if ubuntu has a script that is always run upon resume, that would be good enough | 17:18 |
| slangasek | but I can't really see too many other use cases for this, the ideal is that apps never need to know a suspend/resume happened | 17:18 |
| mkrufky | for the problem that i need to solve right now, even just killing totem after resume from suspend would suffice as a fix | 17:18 |
| mkrufky | television applications need to know | 17:18 |
| slangasek | oh, sure, you can put any manner of hook in on resume via pm-utils | 17:18 |
| ScottK | I know (from doing it by accident) that if I suspend in the middle of compiling a package, on resume dpkg will DTRT and keep right on building. | 17:19 |
| slangasek | mkrufky: c.f. /usr/lib/pm-utils/sleep.d | 17:20 |
| mkrufky | slangasek: " c.f. " ? | 17:20 |
| slangasek | mkrufky: hmm, properly "cf." - "compare" | 17:21 |
| TheMuso | ScottK: I've had a similar experience with a VM in KVM. | 17:22 |
| mkrufky | hmm... interesting slangasek -- thanks | 17:24 |
| === ember_ is now known as ember | ||
| TheMuso | hrm I think dmraid's raid5 implementation is broken somewhat. | 18:05 |
| sebner | jdong: siretart: ping, the video runs in a own window in vlc. We had this bug already though | 18:05 |
| pitti | good night everyone | 18:16 |
| * TheMuso goes to test raid5 for dmraid on real hardware to see if it makes any difference. | 18:17 | |
| Picklesworth | evand: Any news on that Ubiquity Slideshow thing? I remember you were hoping to get that moving, so I should contribute to the right place :) | 18:19 |
| evand | Picklesworth: there's a specification for it (https://wiki.ubuntu.com/UbiquitySlideshow). I'm currently trying to coordinate efforts between teams, but got caught up in holiday. Expect progress on that front soon :) | 18:23 |
| evand | The hardest part is going to be getting the artwork / text done and signed off by the respective teams. | 18:24 |
| Picklesworth | I have been tinkering with SVGs. I think I have a decent path figured out to localizing them, although it'll have to be a tad unusual | 18:24 |
| evand | Pango should be able to do the job nicely. I'm not too concerned with the underlying image format, assuming we can render it or convert it to something we can render. | 18:25 |
| Picklesworth | The reason I'm tinkering with SVGs is because I bet artists would like those. Could make it more encouraging to contribute to :) It also means people can be somewhat creative with text (within reason) and it'll still be translatable | 18:27 |
| ogra | note that the string length varies massively between localizations | 18:27 |
| Picklesworth | Alas, that's true :( | 18:28 |
| ogra | SVG is localizable since ages (its just XML in the end) but if you change strings inside an image it might just break because the strings get to long | 18:28 |
| evand | indeed, thus Pango. Give it a box and tell it to fit the text in that. Though we'd still put restrictions on number of sentences. | 18:28 |
| evand | So we don't get ridiculously small text. | 18:28 |
| Picklesworth | I guess the trick, then, is finding the right way to describe things visually since the text would have to be used mainly as captions | 18:30 |
| cjwatson | yeah, I think anything more than a single sentence would probably be too much in many cases | 18:38 |
| evand | Pretty much. I defer to the art and creative teams for that one though :) | 18:38 |
| * TheMuso sighs. The latest upstream release of dmraid cannot recognise the metadata of my gigabyte board/intel controller properly, yet the version in intrepid does. :S | 18:39 | |
| TheMuso | We have one big piece of crap on our hands folks, at least IMO. :S | 18:40 |
| directhex | punishment for buying gigabyte! | 18:49 |
| TheMuso | directhex: Not quite, if I were to explain exactly what dmraid was, I would probably destroy everything within reach right now. | 18:50 |
| TheMuso | THis has nothing to do with the board itself, and everything to do with bad upstraem regression testing. | 18:50 |
| TheMuso | particularly since Intel were involved with some of the coding for dmraid. | 18:51 |
| directhex | i thought it was mostly redhat people behind dmraid | 18:51 |
| TheMuso | directhex: Yes, but intel have been helping with supporting their own metadata format. Obviously that hasn't worked too well. | 18:52 |
| directhex | TheMuso, is it a specific series of ICH*R which doesn't work anymore? | 18:52 |
| TheMuso | directhex: I don't know. I have two gigabyte boards here that have intel dmraid BIOSes, but one is my file server, and all of its disks are part of Linux Raid, which is somewhat more sane, and I'd rather not take that offline. | 18:53 |
| TheMuso | Both boards have different ICH revisions as well. | 18:53 |
| TheMuso | But I doubt that the metadata is that different between them. | 18:54 |
| directhex | i've never trusted dmraid. always seen it as more of a concession to windows dual-booters with raid0 | 18:54 |
| TheMuso | directhex: I don't trust it, and don't like it either. However I am the one who is currently maintaining it, since I had the hardware to test Ubuntu integration on it, prior to dmraid itself being able to write metadata. | 18:55 |
| directhex | oh. lucky you :| | 18:55 |
| TheMuso | directhex: Damn right. I'd love to hand it off to someone who really cares, but I don't see that happening any time soon. | 18:55 |
| ScottK | Especially now that you've announced to everyone how painful taking over would be. | 18:57 |
| jcastro | directhex: see pm please! | 18:57 |
| TheMuso | ScottK: heh true. | 18:57 |
| directhex | jcastro, which PM? | 18:57 |
| TheMuso | ScottK: Even if I hadn't, I would tell any prospective maintainers that it would be painful anyway, which is why I say someone who really cares. | 18:57 |
| jcastro | the one I sent you ~45 minutes ago? | 18:58 |
| directhex | oh, let me check my logs | 18:58 |
| soren | asac: I have a couple of packages that provide extensions for Mozilla, specifically the kind that handles some new content types... How do I get firefox to know about these if a user accesses a page that embeds some of these kinds of objects? | 19:00 |
| soren | There's something about some Npp-* headers or some such, right? | 19:01 |
| cjwatson | Keybuk: http://ext4.wiki.kernel.org/index.php/Ext4_Howto - has the vol_id/blkid debate there been resolved? if so it would be nice if somebody could be persuaded to update the wiki | 19:20 |
| Keybuk | cjwatson: Ted has declined to change the text on the wiki, I forwarded the results of my efforts to mdz to follow-up on | 19:22 |
| cjwatson | ah | 19:22 |
| soren | asac: I think I've worked it out. Who assigns the appliction guid's? | 19:23 |
| walters | soren: you just generate one, there's no assignment | 19:24 |
| === bluesmoke is now known as Amaranth | ||
| ScottK | TheMuso: Of course you would. I was kidding. | 19:28 |
| TheMuso | ScottK: heh right. | 19:30 |
| superm1 | siretart, ping. I was wondering what's going to be the plans for vdpau en ffmpeg whenever the new version eventually floats into ubuntu? Since it lives in restricted likely, is it not going to be enableable? | 19:42 |
| TheMuso | You know there is something wrong with a piece of software that writes directly to your hard disk, when it manages to make your BIOS choak when attempting to boot your system. | 20:07 |
| siretart | superm1: I haven't updated ffmpeg yet, but I plan to do so this weekend or next week. Do you have already experience with the vdpau headers? which package ships them? | 20:10 |
| sebner | siretart: \o/ | 20:13 |
| sebner | superm1: does this new nvidia driver works with the new xorg? | 20:13 |
| soren | walters: Lovely... What's it used for? | 20:14 |
| walters | soren: to uniquely identify extensions | 20:14 |
| siretart | does vdpau actually work in jaunty already? | 20:14 |
| walters | soren: if you don't like uuids you can also name them like email addresses | 20:14 |
| soren | walters: Hmm... Ok. Does it uniquely define the particular version as well? | 20:19 |
| walters | soren: no | 20:19 |
| walters | soren: this is all documented fairly well here: https://developer.mozilla.org/en/Extensions | 20:20 |
| soren | walters: Ah, thanks. | 20:21 |
| soren | walters: Do you happen to know if adding the XB-Npp-* headers is all that's needed for firefox to pick them up? I mean... Is there something, somewhere that uses that information to build a mapping from mime-types to package names and the provide that to firefox? | 20:27 |
| walters | soren: no idea what XB-Npp headers are; as for mime types, see: http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html | 20:28 |
| slangasek | are those what ubufox uses, or are those the fields that Debian implemented independently? | 20:28 |
| slangasek | soren: I think you want mvo for answers, here | 20:29 |
| soren | mvo? Not asac? | 20:29 |
| slangasek | mm, possibly asac :) | 20:30 |
| soren | walters: They're headers we apparantly add to our packages that provide plugins for mozilla. | 20:30 |
| slangasek | they're also present in Debian | 20:31 |
| slangasek | so it's possible that was implemented independently of ubufox | 20:31 |
| soren | I think, maybe, ubufox provides the magic that goes to look up the mime-type somewhere. | 20:32 |
| soren | ...and then gets a list of plugins back, which is then used to present to the user. | 20:32 |
| soren | I could be completely wrong, though. | 20:33 |
| soren | It's been known to happen. | 20:33 |
| soren | No, really. | 20:34 |
| slangasek | anyway, I don't know whether ubufox is using the XB-Npp-* headers, but if anything does in Ubuntu, that's it | 20:34 |
| slangasek | if ubufox doesn't use them, they're entirely orthogonal | 20:35 |
| slangasek | well- parallel | 20:35 |
| soren | Heh :) | 20:35 |
| seb128 | soren: any plan to update gtk-vnc in jaunty? | 20:42 |
| exarkun | Is the wxPython package gravely broken in Hardy? | 21:04 |
| exarkun | http://rafb.net/p/Sj1n5Q79.html | 21:04 |
| exarkun | I just found the `python-wxversion´ package. Is that an Ubuntu thing? | 21:06 |
| superm1 | siretart, i just updated the packaging for them, they're now shipped in nvidia-180-libvdpau-dev binary package | 21:09 |
| siretart | superm1: I'm just skimming over the ffmpeg code in upstream trunk | 21:09 |
| superm1 | sebner, i dont believe it works unless you use IgnoreABI still, it was mostly uploaded so that stuff that needs the new vdpau API could build against it | 21:09 |
| siretart | superm1: it doesn't seem to make sense to compile ffmpeg against these headers yet | 21:10 |
| superm1 | siretart, due to code maturity, or is it that you get no added functionality? | 21:10 |
| siretart | superm1: the code to actually use vdpau has just been submitted one hour ago on the ffmpeg mailing list ;) | 21:11 |
| superm1 | siretart, ah :) | 21:11 |
| siretart | superm1: see, its nice that libavcodec offers access to vdpau, but you still need support in the codecs, and/or in the video output drivers | 21:12 |
| superm1 | siretart, right, and likely the applications will need to expose a way to change video output too | 21:13 |
| siretart | the whole thing seems to need some more months review and integration work. I don't think ffmpeg and mplayer will be ready until feature freeze. but who knows? | 21:13 |
| siretart | superm1: well, for mplayer and xine you can already select your video output plugin | 21:13 |
| siretart | I expect that you'll get yet another plugin for vdpau just like for xvmc | 21:13 |
| siretart | ideally these players would just autodetect if that is avaiable and just use it | 21:14 |
| superm1 | i'm not even sure the mythtv version that supports it (0.22) will be ready to be released by feature freeze, but in the event it is i wanted to make sure that the packaging side was ready to go with test builds /what not | 21:14 |
| siretart | but that isn't implemented yet. and I'm not sure if that makes sense at this point at all anyways | 21:14 |
| superm1 | yeah mythtv does autodetection and falls back | 21:14 |
| siretart | mythtv implements video output itself? I thought it uses mplayer or something for that? | 21:15 |
| superm1 | it implements itself yes | 21:16 |
| siretart | ah, ok | 21:16 |
| superm1 | it's got an internal playback system based on ffmpeg | 21:16 |
| siretart | aah, I see | 21:16 |
| siretart | anyway, it seems to me the sanest way to enable ffmpeg with vdpau is to place a copy of vdpau.h and vdapu_x11.h in the ffmpeg-debian source package and make it dlopen the libraries at runtime | 21:17 |
| siretart | and hope that the vdpau API and ABI are more stable than ffmpeg's | 21:18 |
| sebner | superm1: kk, thx | 21:18 |
| sebner | siretart: btw, did you notice that vlc open a further window for the video playing (again) | 21:19 |
| superm1 | siretart, well i believe the way that things are working is that you link against libvdpau.so which will dlopen libvdpau_nvidia.so later | 21:20 |
| superm1 | but i'm not positive | 21:20 |
| siretart | sebner: no, I'm still on intrepid. I wonder if I should update my laptop to jaunty yet... | 21:22 |
| sebner | siretart: heh, anyways. it's happening on jaunty. I didn't want to reopen the old bug but tell you via irc :) | 21:22 |
| asac | soren: yes. just add the headers | 21:23 |
| siretart | superm1: if I read the source correctly then it seems that you are right and ffmpeg would need to link against the vdpau libraries | 21:23 |
| siretart | superm1: would it be possible to rip the vdpau libraries and headers out of the nvidia-glx package into a package on its own suitable for main? | 21:24 |
| asac | soren: (if its a plugin) however, will not appear in plugin finder service until i update the plugin db | 21:24 |
| siretart | hi asac! | 21:24 |
| superm1 | siretart, that's what i just did in my last upload | 21:25 |
| siretart | superm1: excellent! | 21:25 |
| siretart | asac: any news on the sunbird 0.9 front? | 21:25 |
| superm1 | siretart, (https://edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180) suitable for main i'm not positive, since libvdpau.so is closed however | 21:25 |
| lure | last udev seems to break lvm root for me :( - I get just BusyBox | 21:25 |
| lure | is this known issue | 21:25 |
| superm1 | that's what i was worried about, it would likely need to live in restricted too still | 21:25 |
| siretart | superm1: is both libvdpau.so and libvdpau_nvidia.so closed? | 21:26 |
| asac | siretart: yes. its all packaged | 21:26 |
| asac | (i think ;)) | 21:26 |
| asac | probably an accident that its not uploaded yet | 21:26 |
| siretart | asac: cool! where to get binaries? ;) | 21:26 |
| asac | iceowl is also ready | 21:26 |
| asac | (maybe i uploaded that to experimental)? | 21:26 |
| * siretart hugs asac! | 21:27 | |
| superm1 | siretart, unfortunately :( | 21:27 |
| siretart | asac: it seems something went wrong with that :( | 21:27 |
| lure | uf, ENOKEYBUK :( | 21:27 |
| asac | siretart: i guess so | 21:27 |
| siretart | superm1: hm. that makes using it challenging :) | 21:28 |
| asac | https://code.edge.launchpad.net/~mozillateam/sunbird/ubuntu-0.x | 21:28 |
| asac | https://code.edge.launchpad.net/~mozillateam/sunbird/iceowl.debian-0.x | 21:29 |
| asac | so havent released the packages yet as it seems ;) | 21:29 |
| * asac writes this on his TODO to not forget | 21:29 | |
| superm1 | siretart, i wonder if we could try to ask nvidia to provide source for just that one library | 21:29 |
| superm1 | it literally is a 4.5k wrapper | 21:29 |
| siretart | superm1: that would be indeed helpful | 21:29 |
| siretart | asac: thanks! | 21:30 |
| asac | thank me after the upload ;) | 21:31 |
| siretart | asac: I tried testing the binaries from mozilla, but they don't enable gssapi support for some reason in their binaries :-( | 21:31 |
| siretart | so I'm eagerly waiting for the packages, because they do | 21:31 |
| asac | oh they do? ... competitive advantage ;) | 21:38 |
| siretart | indeed! | 21:41 |
| siretart | there is even a bugzilla bug about that open in their bugtracker | 21:41 |
| siretart | but being ignored for ages :/ | 21:41 |
| siretart | anyways. it seems that sunbird still cannot accept iTIP invitations :( | 21:41 |
| superm1 | siretart, i've got a contact with them that has been involved with vdpau that I sent a note to. i'll let you know what i hear | 21:43 |
| siretart | superm1: excellent! thanks! | 21:51 |
| superm1 | siretart, already got a response: http://paste.ubuntu.com/101886/ | 21:53 |
| siretart | superm1: that's great news! | 21:54 |
| superm1 | siretart, yeah and in the event that the open sourcing doesn't happen "soon", i think that stub idea would work well. | 21:55 |
| siretart | superm1: this means that things are going well. do you think it makes sense to target jaunty, or shall we defer this affair to jaunty+1? | 21:55 |
| siretart | giving my current available time, I'd vote for jaunty+1 | 21:55 |
| superm1 | siretart, well that all depends on how accepting ffmpeg ends up being for this patchset. all the other pieces will start to come after that | 21:56 |
| siretart | vdpau is currently being actively reviewed and integrated in ffmpeg right now | 21:56 |
| siretart | however I have no insight how invasive and how many patches are yet to follow, but things are very promising! | 21:56 |
| superm1 | siretart, indeed. i'll be keeping my eyes on it. i'll let you know if i hear more. i'll be glad to help out should there need to be some more integration pieces and it comes down to crunch time for FF | 21:59 |
| pochu | could some core-dev approve the intrepid task in bug 295490 please? TIA :) | 22:18 |
| ubottu | Launchpad bug 295490 in liferea "Liferea doesn't start with "Aborted" error." [Medium,Fix released] https://launchpad.net/bugs/295490 | 22:18 |
| kees | hm, that's serious code quality when you compile with -O99999999 | 22:36 |
| james_w | kees: http://people.ubuntu.com/~jamesw/ppamadison | 22:39 |
| james_w | likely to cause injuries to pets if used in anger, as it will open a web browser at every invocation currently | 22:39 |
| kees | james_w: cool | 22:40 |
| kees | james_w: btw, I tend to use this: http://pastebin.osuosl.org/23183 | 22:41 |
| james_w | kees: yeah. It would be good to have some standard way of doing that | 22:42 |
| bryce | kees, you should use ~/.cache/... and ~/.config/... | 22:48 |
| directhex | james_w, do you want to be thanked in my mono transition report, or do you want to hide from the boycottnovell hit list of evil freedom hating microsoft employees? | 22:49 |
| james_w | directhex: now there's an offer I can't refuse :-) | 22:49 |
| sebner | james_w for freedom \o/ | 22:50 |
| Hobbsee | robbiew: consider yourself whitelisted on u-d@ | 23:57 |
| robbiew | Hobbsee: \o/ | 23:58 |
| Hobbsee | :) | 23:58 |
| Hobbsee | so now I can read the team summary :P | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
