crimsunTheMuso: i'm thinking more along the lines of providing it as a non-default but available stanza so that users can choose it00:36
TheMusocrimsun: Right, I have thought that since you proposed it.00:36
TheMusocrimsun: Were you thinking of tweaking the original snippet in any way?00:37
TheMusoIf not, I can drop it in, and we may even be able to SRU it for intrepid.00:37
crimsunTheMuso: yeah, need to investigate what max db should be set to (some "sane value", which means lots of feedback required)00:38
TheMusocrimsun: Right.00:39
maxbIs there any standard python parser for debian control files that's faster that debian_bundle.deb822 ?00:56
Adri2000elmo: 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. thanks00:56
slangasekasac: no ubufox upload yet for bug #308397?01:25
ubottuLaunchpad 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/30839701:25
slangasekcalc: 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.201:33
=== hyperair1 is now known as hyperair
kirklandRiddell: hi there, i pushed another revision of screen-profiles, this one with a COPYING file in the tarball02:13
calcslangasek: yea just untarget them is fine02:34
=== racarr_ is now known as racarr
=== jono_ is now known as jono
slangasekcalc: ok.  are you planning to make time for an OOo SRU at some later time?03:33
calcslangasek: perhaps, but i will be very busy at least for the next 1.5 months03:38
* slangasek nods03:38
calcgot a 3.0.1 release coming up to get into jaunty this month then sprint and a week in hamburg at sun03:39
=== hyperair1 is now known as hyperair
=== emgent_ is now known as emgent
=== emgent_ is now known as emgent
dholbachgood morning06:46
keesjames_w: where's your ppamadison living?  I'm curious to see the lplib bits07:07
pittiGood morning07:19
directhexmorning, dholbach. i've pencilled in meebey & myself for a session for developer week07:20
dholbachdirecthex: rock and roll!07:21
dholbachyou guys are heroes!07:21
directhexwell poopy. looks like another total aircon failure in my machine room07:21
directhexthat's a couple of million quid of kit offline07:21
ion_Hi all07:26
=== tkamppeter_ is now known as tkamppeter
=== hyperair1 is now known as hyperair
dholbachthere 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/Prep08:45
dholbachalso there was a request about python packaging and how to make your application translate-able08:45
directhexpfft, python. who wants that when there's mono?08:59
directhexalso, aircon failures hurt08:59
* pitti slaps directhex09:14
pittipython ♥! :-)09:14
* directhex hands pitti ironpython09:14
directhexlatest release needs mono 2.2 or some backports to 2.0.1 tho09:15
directhexand this new ikvm package would be the smallest openjdk at our disposal, at ~35 meg on disk :p09:23
pittitjaalton, tseliot: do you know where the xrandr applet saves its settings?09:38
tseliotpitti: in ~/.config09:39
pittitjaalton, tseliot: a friend of mine reports X crashes after he tries to log in, and I want him to reset this09:39
pittiah, monitors.xml?09:39
tseliotpitti: yep09:39
tseliotpitti: is it this bug? https://bugs.launchpad.net/ubuntu/+source/gnome-desktop/+bug/31440609:40
ubottuLaunchpad bug 314406 in gnome-desktop "xrandr plugin of g-s-d crashes on startup" [Medium,Confirmed]09:40
StevenKcjwatson: 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
pittitseliot: I don't know, it just started to happen recently10:26
pittitseliot: (intrepid)10:26
pittitseliot: I asked him some further questions10:26
tseliotpitti: ok10:27
tseliotpitti: let me know if you manage to get the error output so that I can try to fix it10:28
Keybukpersia: where do fridge requests get mailed to now?10:32
StevenKtjaalton: xf86-input-evtouch FTBFS, and is uninstallable. It looks like it needs source porting.10:33
=== thekorn_ is now known as thekorn
tjaaltonStevenK: yes, and no news from upstream10:39
tjaaltonwhich 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 instance10:41
tjaaltonStevenK: hum, that should be easy to fix though10:42
StevenKtjaalton: Fix it? :-)10:42
pittitjaalton: which we want, I assume?10:42
tjaaltonpitti: yep10:42
tjaaltonpitti: including the patch by mjg59 which he posted on u-d@ in October10:42
tjaaltonor was it u-d-d10:43
StevenKScottK: Do you think #312659 should be extended to kfreebsd-6 and -7, too?10:43
tjaaltonStevenK: looking :)10:43
pittitjaalton: 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
tjaaltonpitti: yes, and http://cvs.fedoraproject.org/viewvc/devel/hal/hal-joystick.patch?revision=1.2&view=markup10:44
StevenKpitti: Do you also think I should kill kfreebsd-6 and -7 and blacklist them at the same time I kill -5?10:44
pittitjaalton: I think our joystick patch is better10:44
tjaaltonpitti: we have one?10:44
pittitjaalton: http://bazaar.launchpad.net/~ubuntu-core-dev/hal/ubuntu/annotate/head%3A/debian/patches/07_joystick_detection.patch10:45
tjaaltonpitti: yeah, saw that now, nice :)10:45
pittitjaalton: so, I'll just review all fedora ones and clean harvest then10:46
* pitti hugs dholbach for harverst10:47
* dholbach hugs pitti back10:47
tjaaltonpitti: great, thanks10:47
Keybukpitti: while you're in there, is there a patch for the udev rules location?10:50
pittiKeybuk: not that I can see10:50
pittiKeybuk: there is one for hal dbus permissions10:50
pittibut debian just fixed that, too, I'll merge from them ASAP10:50
pitti(but not today, I finally need to work on the apport retracers)10:51
Keybukwho shot Marco?10:51
Keybukor do you mean Debian just fixed the dbus permissions?10:52
pittiKeybuk: 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
Keybukpitti: yes10:53
Keybukhowever my understanding was that this change was going into Debian "over Marco's dead body"10:53
pittiKeybuk: right, they fixed dbus permissions, not udev rules path10:53
Keybukhe's also refused to adopt standard upstream udev rules10:53
pittiKeybuk: 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
Keybukthat's the easiest way10:54
Keybukthough from a brief glance, neither libsane or libgphoto actually install udev rules now?10:54
pittiI saw your change to that yesterday, so it seems it's supposed to DTRT10:54
pittiKeybuk: ah, right. auto-ACL magic, I remember10:54
pitti(our change is to *drop* udev rules installation)10:54
pittiseems part of my brain is still in holiday mode...10:54
Keybukof course10:55
Keybukthe FDI becomes a udev rule later on anyway10:55
Keybukwhich is a significant part of the reason most distros are going to share a single set of common rules10:56
pittiKeybuk: I hope hal-info will get an fdi2udev script, so that it remains useful for both current and older releases10:56
KeybukI'm honestly not sure how they intend to do that transition10:56
Keybukit's not as if fdi and udev rules are easily translatable10:57
pittiwell, 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
pittiKeybuk: the format of the hal-info rules is relatively straightforward, though, so I guess for a subset it should be possible with some clever XSLT10:58
pittimany rules are simply "0x1234/0x5678 is a scanner" kind of thing10:58
Keybukyou'll need hal-info as long as you have hal10:58
pittiI guess an udev rule won't look much different10:58
pittie. g. the hotkey assignments are a different beast, of course10:58
pittisince they need an actual backend which processes those10:59
KeybukI still don't think the whole DK thing is entirely well thought out11:00
pittibryce: good morning11:01
tjaaltonStevenK: bah, iz not that easy to fix I'm afraid11:02
StevenKtjaalton: Oh?11:03
cjwatsonmaxb: we can tweak it easily11:04
tjaaltonStevenK: uses some deprecated stuff11:05
tjaaltonStevenK: just dropping some obsolete includes and copying xf86OSMouse.h didn't help (like with -mouse)11:05
cjwatsonStevenK: I just hadn't run a real update since intrepid; fixed, thanks11:06
cjwatsonmeh, now I remember why I didn't convert pcmciautils to dh_installudev - the upstream Makefile installs the rules file11:08
* cjwatson bodges11:08
cjwatsondh_installudev is really only suitable for udev rules shipped as packaging modifications11:09
pittihm, remove it from *.install, and move debian/tmp/etc/udev/rules.d to *.udev won't work?11:09
Keybukpitti: that's a bit evil :_)11:10
pittiKeybuk: why?11:10
cjwatsonpitti: sounds like more effort than reimplementing the necessary bits of dh_installudev!11:10
Keybukcjwatson: your other problem will be that dh_installudev will want to call your file 85-pcmciautils.rules11:10
Keybukso you'll have to deal with the rename in your maintainer scripts *anyway*11:10
pitticjwatson: 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
Keybukso 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 path11:11
pittioh, wait11:12
cjwatsonpitti: I didn't say it was in .install11:12
pitti.udev doesn't *list* the rules files, it *is* the rules file11:12
cjwatsonI said it was installed by the upstream Makefile11:12
pittiso yeah, that won't work then11:12
cjwatsonplus what you said11:12
pitticjwatson: ah, you are installing directly into debian/pcmciautils/, not debian/tmp?11:12
cjwatsonKeybuk: BTW your debhelper modification doesn't seem to have a maintainer script abort path11:13
cjwatsonof course the original udev stuff didn't either11:14
pittihm, seems like dh_installudev could do with supporting debian/package.udev-files and treat that as file list11:14
Keybukcjwatson: a what?11:14
Keybukpitti: it's modelled after installinit, which doesn't have such a thing11:15
cjwatsonKeybuk: postrm abort-install or whatever11:15
pittiKeybuk: right, I thought it would be like dh_install or dh_installman11:15
Keybukcjwatson: IME very few packages bother with it :-/11:15
cjwatsonKeybuk: actually I guess it isn't strictly necessary in this case anyway11:15
Keybukthen again, it took me a very long time to get it right for udev and dpkg, so I'm not entirely surprised :p11:15
cjwatsonKeybuk: well, yes, but debhelper getting it right would go a long way :)11:16
cjwatsonKeybuk: I notice that udev still seds /var/lib/dpkg/status directly; I thought modern practice was to use dpkg-query11:19
Keybukmodern practice requires you to know the package name :-/11:20
StevenKcjwatson: It seems kubuntu-kde4 needs to get ripped out too11:22
cjwatsonKeybuk: yes, not hard :)11:23
pittiStevenK: kfreebsd-{6,7}> yes, makes sense11:23
Keybukcjwatson: I'm not also convinced that the dpkg-query method is any better11:23
Keybukafter all, it still has to sed the output of dpkg-query11:23
cjwatsonwell, 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 change11:24
cjwatsonStevenK: I guess so11:24
cjwatsonStevenK: is the mobile branch ready for me to try?11:24
StevenKcjwatson: Yeah, it's all commited.11:25
Keybukof 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 package11:32
RainCTcalc: ping11:36
RainCTcalc: Is bug #66933 really fixed? Because I have that problem on a clean Intrepid install...11:37
ubottuLaunchpad bug 66933 in openoffice.org "Recent Documents doesn't include files opened from within OOO" [Low,Fix released] https://launchpad.net/bugs/6693311:37
cjwatsonKeybuk: is there a standard dependency or breaks or whatever for packages shipping new-location udev rules?11:42
Keybukcjwatson: if they dependended on udev before, I've updated it11:45
Keybukbut I haven't added one where one didn't exist before11:45
Keybuka lot of things ship udev rules without depending on udev11:45
Keybukwhich makes it complicated :p11:45
cjwatsonKeybuk: what should the version be - >> 136-1?11:46
cjwatsoner >=11:46
Keybuk>= 136-111:46
cjwatsonok, pcmciautils done in my local tree then11:47
Keybukdebhelper is 7.0.17ubuntu211:53
soci have patches against /var/lib/gconf/defaults/%gconf-tree.xml and /var/lib/gconf/debian/defaults/%gconf-tree.xml11:53
Keybukif you use cdbs, 0.4.38 has the dh_installudev call11:53
socwhom should i send them?11:53
cjwatsonStevenK: tasksel updated - any problem with me uploading it now or do I need to wait?11:59
cjwatsonactually I guess it really ought to be now since the seeds have already been changed11:59
cjwatsonand I see that mobile-meta has been uploaded12:00
StevenKcjwatson: Thanks!12:02
StevenKcjwatson: I'll upload livecd-rootfs tomorrow12:02
ScottKStevenK: 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
StevenKScottK: Yup12:14
socmhh weird12:16
soci tried to create a patch, but the diff is always double the size of the original/changed file12:17
socwhen 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 changed12:17
brooniesoc: line endings change, probably.12:18
socbut i want to have a diff with just the lines which were changed, not the whole thing12:18
sochow can i ingore them?12:18
=== nhandler_ is now known as nhandler
socit's an xml file, btw12:18
broonieYou're almost certainly actually changing all the lines in the file.12:19
brooniePossibly by changing the line endings, possibly some other way.12:19
socmaybe tab to space?12:19
socdoes gedit make that automatically?12:19
broonieMight, but I'd be a bit surprised.12:19
soci hate it ... always the latest step fails for me ...12:21
soclast step12:22
socmaybe 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.diff12:22
ahasenackI 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 repository12:22
ahasenackfor example, I want to test an upgrade from hardy to intrepid but I want it to consider my local repository as well12:23
cjwatsonsoc: try viewing the diff in an editor configured to show special characters12:24
socwhich editor could i use for that?12:24
cjwatsonsoc: well, I use vim but you may not be comfortable with that if you're used to gedit :) do some research12:29
cjwatsonsoc: or you could run it through cat -A12:30
=== 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
ahasenackmvo: 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
\shmaswan: when? :)13:07
maswan\sh: 13th to early morning at the 16th13:08
maswan\sh: No plans for the 13th so far, might be meeting dinners etc at the other days though.13:08
\shmaswan: 13th sounds great :)13:09
apwso who owns the debian-installer in ubuntu13:10
cjwatsonapw: *wave*13:11
apwcjwatson, heh is there anything you don't own?13:12
mvoahasenack: not easily unfortuntaely. what is the use-case?13:12
cjwatsonapw: yes :-)13:13
maswan\sh: see you then, then. :)13:13
ahasenackmvo: 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 packages13:13
cjwatsonapw: something up that I can help with?13:14
apwcjwatson, 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 differ13:14
cjwatsonapw: well, whether lilo or grub is installed depends on the installation parameters - for example if /boot is on LVM then lilo's needed13:15
apwso 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 do13:15
mvoahasenack: 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
cjwatsonI'm very surprised about both being installed, and would like to see the installer log13:15
ahasenackmvo: how can I try it?13:15
mvoahasenack: how urgent is it? i.e. can we talk about it a little bit later (~2h)?13:15
ahasenackmvo: sure13:15
apwmy 32bit sample is on a single normal ext3 disk and is using the grub by default13:15
mvoahasenack: its in the update-manager bzr branch13:16
apwcjwatson, typically i am remote from that laptop today ... i will get that off and to you13:16
cjwatsonapw: Recommends are ignored while installing the kernel during initial installation, so it won't be that13:16
apwHobbsee, 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 #31400413:17
ubottuLaunchpad 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/31400413:17
cjwatsonapw: http://bazaar.launchpad.net/~ubuntu-core-dev/grub-installer/ubuntu/annotate/head%3A/debian/isinstallable is what controls whether grub or lilo is installed13:17
cjwatsonapw: if that script exits zero, then grub's used, otherwise lilo13:17
apwthanks, to basically its as expected, only one should be installed13:17
cjwatsonapw: but that doesn't influence dist-upgrades13:17
apwfrom memory it definatly put both on in the same original install block13:18
cjwatsonthat's incredibly weird13:18
apwno i assume Hobbsee got the update just because there is a lilo update in jaunty and it was installed13:18
cjwatsonI'd be astonished if the discrepancy were really due to i386 vs. amd6413:18
cjwatsonI think it's more likely to be something more subtle13:18
Hobbseeapw: i got it installed at the point where I did the dist-upgrade.13:19
apwcjwatson, if Hobbsee isn't able to get her logs, i will try and be where the other laptop is and get it off13:19
cjwatsonthe thing is that the kernel recommends lilo | grub13:19
cjwatsonnot both - either should satisfy it13:19
Hobbseeapw: should be http://pastebin.com/f81055d513:19
cjwatsonnow, I do think the kernel should recommend grub | lilo instead, switching the order13:19
cjwatsonbut that's cosmetic from the point of view of this bug13:19
apwcjwatson, can i tell if there was a lilo update in jaunty13:19
cjwatsonapw: shouldn't be relevant13:19
cjwatsonapw: rmadison lilo13:20
Hobbsee(i didn't check whether it had installed lilo in the original install of intrepid)13:20
apwHobbsee, 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 upgraded13:20
Hobbseeapw: could have been13:20
apwi think pgraner said his 32bit install had both too13:20
cjwatsonapw: simply changing the version of lilo in jaunty wouldn't cause it to be magically installed13:21
apwso its something more than just one or two of us13:21
apwcjwatson, right, but it changing would make it upgrade at dist-upgrade which might explain why it was noticed by Hobbsee13:21
cjwatsonI think this is related to installing with desktop vs. alternate/server13:21
apwand yes it is differnt13:21
apw      lilo | 1:22.8-4ubuntu1 |      intrepid | source, amd64, i38613:21
apw      lilo | 1:22.8-7ubuntu1 |        jaunty | source, amd64, i38613:21
apwso ... if she had had the same as me, that both were on, then lilo would be downloaded and installed as part of an update13:22
Hobbseeinstaller log added to bug.13:22
apwHobbsee, perfect13:22
cjwatsonthis is interesting, lilo is installed as part of desktop13:22
cjwatsonthat would explain why ubiquity isn't removing it13:22
cjwatsonmvo: update-manager might have to arrange to remove lilo :-(13:23
cjwatson(if unused ...)13:23
HobbseeSetting up lilo (1:22.8-4ubuntu1) ...13:23
Hobbseeright, so i did get it in the intrepid version.13:23
cjwatsonyour initial install was intrepid desktop13:23
apwso can we tell from the log what slurped it in?13:24
mvocjwatson: sure, that can be arranged13:24
cjwatsonnot from the log but I can tell in other ways, please wait13:24
pgranerapw: it installed it on a Intrepid->Jaunty upgrade13:24
cjwatsonpgraner: but it was already installed on intrepid, I'm fairly certain#13:24
apwpgraner, what he said13:24
cjwatsontherefore focusing on the upgrade is an error13:25
apwthere was a new one in jaunty so if you had it already you get eh new one, even though you don't want it13:25
pgranercjwatson: 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-get13:25
cjwatsonoh goodness, yes, you would13:25
cjwatsondue to the large-memory thing13:25
cjwatsonyargh, lovely bug that's now enshrined on lots of systems13:25
cjwatsonapw: 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 installer13:26
cjwatsonapw: can you confirm?13:26
cjwatsonso it's true that the order of the kernel recommends is what caused this, but really, accident ...13:27
apwcjwatson, i can confirm the 'broken' one was installed virgin from a desktop CD image13:27
apwthe working one  i am struggling to remember if it was hardy CD installed and updated or reinstalled from the intrepid 64 bit CD13:28
cjwatsonlet me give you a potted summary of what happened, then13:28
apwcan i tell at all13:28
cjwatsonyes, /var/log/installer/syslog will indicate, if only from the kernel version13:28
cjwatsonin intrepid, we enabled recommends by default; this had some speedbumps but largely appeared to be working OK13:28
apwOct 21 12:47:25 ubuntu kernel: Inspecting /boot/System.map-2.6.24-19-generic13:28
apwso hardy then upgraded me thinks13:28
cjwatson(therefore any installs from earlier than intrepid are entirely unaffected by this)13:28
cjwatsonthe 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 there13:29
cjwatsonhowever, the desktop installer works quite differently13:29
cjwatsonwe 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 system13:30
cjwatsonobviously, there are some things on this image that shouldn't end up on the target system, such as the installer itself13:30
cjwatsonso 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
cjwatsonthe 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 tweaks13:31
cjwatson(things like language packs, removing unused kernels if there's more than one available, etc.)13:32
apwcjwatson, a sneak solution indeed13:32
cjwatsonfor 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
cjwatsonand, 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 installer13:33
cjwatsonthe installer notices that it needs grub, and therefore arranges for it to stay installed as well13:33
cjwatsonand voila, two bootloaders13:33
cjwatsonI 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 installing13: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 upgrade13:35
apwok ... so i can handle the linux(2) side under the linux task13:36
apwwill you make tasks for the rest?13:36
cjwatsonyes, already have13:36
apwcool.  will get on it.  does this need doing for intrepid, or is it too late to matter13:37
apw(we are going to make new CD's I assume for the intrepid update?)13:37
cjwatsontoo late for intrepid, and we weren't planning new CDs13:37
cjwatsonwe normally only do new CDs for point releases, which are normally only for LTSes13:38
apwok so then i'll just spin the change on jaunty13:38
cjwatsonand they're a lot of work13:38
cjwatsonyeah, jaunty will be fine13:38
apwheh, yeah i did notice a lot of moaning when they were being spun last time13:38
cjwatsonHobbsee: thanks for spotting this13:38
Hobbseecjwatson: glad you can fix it :)13:38
mvocjwatson: 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
apwmvo, bug #31400413:42
ubottuLaunchpad 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/31400413:42
apwcjwatson, thanks for the insight into d-i's guts13:43
cjwatsonapw: ubiquity's guts in this case13:43
cjwatson(you're welcome)13:43
cjwatsonfixed for next upload, pending testing13:45
apwcjwatson, kernel patch out for review13:51
Keybukcjwatson: heh, I spotted it the other day too but hadn't got around to mentioning it yet13:52
Keybukjames_w: around?14:02
james_whey Keybuk14:03
Keybukbzr build-deb appears to be ignoring my .bzr-builddeb/local.conf :-/14:03
Keybukquest ubuntu% cat .bzr-builddeb/local.conf14:03
Keybuksource-builder = dpkg-buildpackage -rfakeroot -uc -us -S -i'(?:/|^)(?:test|\.gitignore)(?:/|$)'14:03
Keybukyet, when I do bzr bd -S I get lots of14:03
Keybukdpkg-source: error: cannot represent change to udev-136/test/sys/devices/virtual/block/loop5/subsystem:14:03
Keybukfollowed by (eventually)14:03
Keybukdpkg-source: unrepresentable changes to source14:03
Keybukdpkg-buildpackage: failure: dpkg-source -b udev-136 gave error exit status 114:03
james_wKeybuk: could you pastebin the full output please?14:04
james_wKeybuk: is the file versioned?14:04
Keybukthe full output is ~4 GB14:05
james_wok, the top few lines should do14:05
persiaKeybuk, ubuntu-news-team@lists.ubuntu.com, I think.14:05
Keybukthe files its complaining about are versioned, but not in the tarball14:05
james_wsorry, is .bzr-builddeb/local.conf versioned?14:05
Keybukjames_w: yes14:06
james_wKeybuk: ah, it shouldn't be, it's local overrides14:06
Keybukwhat file do I put that line in instead?14:06
james_wthere is no way to set per-package overrides yet currently unfortunately14:07
james_wyou can either move that file to ~/.bazaar/builddeb.conf14:07
Keybukthat means nobody else will be able to build a udev package from bzr other than me though14:07
Keybukwhich kinda defeats the object :p14:07
james_wor unversion it ("bzr rm --keep")14:07
james_wdon't put it in the local file then14:07
james_wbzr mv .bzr-builddeb/local.conf .bzr-builddeb/global.conf14:08
james_wer, default.conf sorry14:08
KeybukBuilding the package in ../build-area/udev-136, using dpkg-buildpackage -rfakeroot -uc -us -S14:08
Keybukno change14:08
Keybukstill ignores it14:08
james_wpython -c "from bzrlib.workingtree import WorkingTree; print WorkingTree.open_containing('.')[0].path2id('.bzr-builddeb/default.conf')"14:12
james_wwhat does that print?14:12
looljames_w: Re debbug #426419 > no patch; did we actually patch this?14:16
Keybuktkamppeter: so I'm looking at hplip's udev rules ... and I'd like to take your crack pipe away14:17
Keybukin fact14:25
KeybukI can just delete the rules file entirely14:25
Keybukbecause all it does is put things into the scanner group14:25
Keybukwhich we, err, don't have14:25
liwKeybuk, hmm, I have it14:25
ogratills crack pipe ?14:25
liwgid 105, so probably manually created14:25
Keybukliw: it goes away in jaunty14:25
liwKeybuk, ah14:25
james_wKeybuk: 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
Keybukjames_w: it should be at least possible to specify the ignore string?14:26
james_wKeybuk: yeah, but does everyone's builder command accept that option?14:27
pittiliw: 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 it14:30
james_wlool: seems we didn't14:30
james_wlool: 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 report14:31
Keybukjames_w: another option would be files you could not export across to the build area?14:32
james_wlool: well, we patched acpid to check for the file, but didn't patch it to fix the ubuntu bug I referenced14:32
james_wKeybuk: that could work.14:34
james_wI 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 is14:34
Keybukcjwatson: you remember how we couldn't figure out why hwclock wasn't working properly?14:35
Keybukwell, I just looked at the udev rules14:35
KeybukKERNEL=="rtc", ...14:35
ScottKslangasek: 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
Keybukyeeeeah, that won't work14:35
slytherinCan any archive admin please process these bugs - 314470 314487 314505?14:35
cjwatsonKeybuk: ah, heh14:37
cjwatsongood catch14:37
Keybukcjwatson: tbh, I should probably just read through all of the hwclock code, including that in the kernel14:38
Keybukand do it from scratch again14:38
Keybuksince last time we briefly looked we found that must of it wasn't necessary anymore14:38
Keybuk(most of our changes esp.)14:38
cjwatsonKeybuk: failing all else we can do it at the sprint14:50
cjwatsonslytherin: done. (no need to ask me about binaries later, we'll do them)14:51
slytherincjwatson: thanks. :-)14:52
StevenKIf that's removal, I'm guessing NBS is going to be enormous once it regens, and I'll take care of it14:52
cjwatsonno, syncs14:54
dholbachwould somebody like to give a session about backtraces and debugging stuff at Ubuntu Developer Week?14:55
dholbachwe still have some open slots available: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep14:55
=== AstralJa1a is now known as AstralJava
Keybukcjwatson: ah, you've never experienced the Berlin nightlife ;)14:57
KeybukI'm not expecting this to be a productive sprint <g>14:57
cjwatsonKeybuk: as far as I'm concerned, Berlin is my chance to spend a week getting uninterrupted nights' sleep; nightlife is not high on my agenda14:58
Keybukcjwatson: :o)14:59
slytherincjwatson: how come the bugs didn't get marked as fix released? Or do you need to do that manually?15:00
slytherinoops, I spoke too earley.15:00
cjwatsonslytherin: indeed ...15:02
cjwatson(and yes, I have to do that by hand, but I did so before saying anything to you)15:02
cjwatsonwe have a script that deals with bug closures but it doesn't work for requests of syncs of new packages15:03
slytherincjwatson: do you usually handle 'move to universe' kind of bugs?15:06
cjwatsonslytherin: ~ubuntu-archive does, I largely do archive work when I'm too tired to program properly :-)15:06
cjwatsonlatching onto me for routine maintenance is a mistake15:06
cjwatsonwe process the queue. Unless it's super-urgent, there's no need to poke explicitly15:07
=== seb128_ is now known as seb128
slytherinok. it is not super urgent.15:07
Keybukcjwatson: talking of which, since it's generally impolite to shove your own uploads through NEW ... :p15:09
cjwatsonKeybuk: damn, and I was enjoying the way my jaunty system is largely working at the moment15:10
KeybukI have _tested_ this, you know ;)15:10
cjwatsonKeybuk: not that it hugely matters, but please set the priorities of the -dev packages to optional for your next upload15:12
Keybukcjwatson: pushed for next tiome15:14
pittiKeybuk: so you *tested* that it'll break everyone's system :)15:14
Keybukpitti: :o)15:14
cjwatsonKeybuk: I think you broke udev-udeb15:14
Keybukcjwatson: oh?15:15
cjwatsonKeybuk: doesn't it need the libraries?15:15
Keybukshouldn't do, it's built -static15:15
cjwatsonah, ok15:15
cjwatsonKeybuk: what links against libudev0? udev doesn't seem to depend on it15:15
Keybukcjwatson: DeviceKit, HAL, etc.15:15
cjwatsonah, but not udev itself?15:16
Keybukit's built-in to udev itself15:16
KeybukI'm not entirely, honestly, sure *why*15:16
cjwatsonI'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
slytherincjwatson: 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
cjwatsonslytherin: don't bother, I'll be away by then15:17
cjwatsonslytherin: please don't bug me personally15:17
slytherincjwatson: ok.15:17
slytherincjwatson: I hope you will clear all the binaries from new queue before you leave. :-)15:18
cjwatsonslytherin: not necessarily.15:18
cjwatsonKeybuk: accepted15:18
tkamppeterKeybuk, what do you mean with "and I'd like to take your crack pipe away"?15:19
Keybuktkamppeter: welll15:19
Keybukon upgrade you15:19
cjwatsonslytherin: (although as it happens I believe that I have done; but I don't really appreciate being treated this way)15:19
Keybuk1) rename the udev rules from a correct name to a bizarre one15:19
Keybuk2) replace the old rules with a dummy file instead of nothing15:19
Keybuk3) install a new dummy file with a name that appears to have never been used15:20
slytherincjwatson: Sorry, didn't mean to.15:21
cjwatsonI'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-such15:22
slytherincjwatson: I understand.15:23
cjwatsonthank you15:23
Keybukpitti: I'm not going insane, right?15:25
Keybukneither libgphoto2-2 or libsane actually ship udev rules anymore?15:26
socwhat 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.png15:27
pittiKeybuk: confirmed; I dropped them in hardy15:27
Keybukpitti: mind if I drop the /etc/udev/rules.d directory from the packages then?15:28
Keybukcause it keep showing up in Contents.gz/dpkg -S :p15:28
pittiKeybuk: they still ship the directory /etc/udev/rules.d15:29
Keybukyeah they do15:30
Keybukmind if I remove that? :)15:30
pittino, not at all15:30
pittiprobably just a leftover from package.dirs15:31
Keybukit is15:31
pitti(the misbehaviour of using dh_installdirs together with dh_install is so widespread :( )15:31
seb128pitti: did you read about guest session freezing the computer on jaunty?15:32
cjwatsonit can be reasonable if you're installing other files by hand too15:32
cjwatsondh_install creates directories for itself, so dh_installdirs is often unnecessary when you're using it15:35
cjwatsonindeed pretty much all debhelper commands create directories for themselves15:35
cjwatsondh_installdirs is just a shorthand for when you need a manual mkdir for some other reason15:35
pittiKeybuk: yes, I often see .dirs containing "usr/bin" and "usr/lib", for example15:35
cjwatsonthat's probably due to dh-make15:35
pittiwhich is generated by upstream make install anyway15:35
Keybukpitti: ugh, gphoto FTBFS :-/15:43
pittinew kernel headers?15:44
Keybuknothing worse than touching a package and having it blow up in a completely unrelated way that you happen to be the best person to fix15:44
Keybukcjwatson: I spotted a udev bug you didn't ;)  libudev0.shlibs was wrong15:46
cjwatson*grin* I just looked at the contents TBH15:46
slangasekScottK: 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 lenny16:05
ScottKslangasek: 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
slangasekIs sasl migrated?  I remember there was resistance in Debian to getting sasl moved off of db 4.2 as well16:09
ScottKYes.  We did that one.16:10
ScottKDebian did too.16:10
* slangasek nods16:10
ScottKI think cyrus imap still needs to be done.16:11
ScottKvorian is looking into the other 4.2 rdepends.16:11
slangasekArneGoetje: hardy langpacks don't appear to be updated yet?16:11
ArneGoetjeslangasek: the tarball is not ready yet...16:19
ArneGoetjeslangasek: rosetta is a bit slow with exporting.16:19
slangasekArneGoetje: ok. ETA?16:20
ArneGoetjeslangasek: dunno. anytime soon.16:20
slangasekArneGoetje: 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
ArneGoetjeslangasek: https://translations.edge.launchpad.net/ubuntu/hardy/+language-packs16:23
ArneGoetjeslangasek: when the tarball is ready it will be top of the list and say "Full Export"16:23
slangasekArneGoetje: ok16:23
ArneGoetjeslangasek: but for us non-LP folks it's impossible to say what the export script is doing.16:24
ArneGoetjeslangasek: jtv mentioned to me that it might take until Friday morning UTC... I just hope it won't take that long.16:25
calcRainCT: hmm looking at it16:25
calcRainCT: i believe there a few issues here16:26
slangasekArneGoetje: 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 us16:26
calcRainCT: 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
calcRainCT: if you open it via OOo recent documents menu it doesn't (iirc)16:27
calcRainCT: and it doesn't resort properly which is another bug report16:27
ArneGoetjeslangasek: good luck16:28
asacslangasek: 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
tjaaltonhum, why does initscripts ship both /etc/network/if-up.d/mountnfs{,.orig}?16:31
tjaaltonat least on hardy16:31
asactjaalton: without looking i would say that its a merge bug ;)16:31
slangasekasac: release date for .2 is Jan 22; I'll unmilestone the bug then, thanks16:33
mkrufkyfrom within a gnome-based app, how can i tell if we are about to suspend, or have just resumed?16:33
tjaaltonasac: possibly16:33
tjaaltonasac: introduced in 2.86.ds1-14.1ubuntu26 (gutsy) :/16:41
=== Mirv_ is now known as Mirv
Keybukcjwatson: you're doing pcmciautils, right?17:02
cjwatsonprobably won't upload 'til tomorrow though, sorry17:02
KeybukI wonder how much of that is needed17:03
Keybuk(the upstream diff of the rules, I mean)17:06
Keybukif it's all valid, it should be just pushed upstream, including the move to /lib/udev/rules.d17:06
Keybukoh, drop the -Q from modprobe17:06
cjwatson-Q no longer needed?17:07
cjwatsonupstream already released pcmciautils 015 that I think included most of our changes, but I haven't got round to packaging it17:07
Keybukahh, k17:07
cjwatsonwell, I did in Debian but haven't merged, oops :)17:08
cjwatsonstill a few Makefile changes actually, I should do something about that17:08
slangasekmkrufky: I'm not sure you can; why do you need to?17:11
mkrufkyslangasek: 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 working17:12
slangasekmkrufky: "streaming" being a network stream?17:12
mkrufkydvb-t / atsc17:13
mkrufkydigital television17:13
mkrufkythe device loses power when in suspend17:13
slangasektypically this is handled via suspend/resume hooks for the hardware, not from the GUI17:13
mkrufkythe device driver reinitializes the device upon resume17:13
mkrufkythe driver itself does the right thing already17:13
mkrufkybut the app needs to steer the ship17:13
slangasekright; I think the better abstraction is if totem can detect that the device driver has been reinitialized?17:14
slangaseksince that could in theory happen outside of suspend/resume, and it would be nice if totem were robust against it?17:14
mkrufkythere's currently no way for userspace to determine that fact17:15
mkrufky...but i thought that dbus would provide some messaging system that would broadcast (we just resumed) to all applications17:16
mkrufkyam i wrong?17:16
slangasekI don't know, really17:17
mkrufky:-/ okay17:17
slangasekyou could check with dbus-monitor17:17
mkrufky...or even if ubuntu has a script that is always run upon resume, that would be good enough17:18
slangasekbut I can't really see too many other use cases for this, the ideal is that apps never need to know a suspend/resume happened17:18
mkrufkyfor the problem that i need to solve right now, even just killing totem after resume from suspend would suffice as a fix17:18
mkrufkytelevision applications need to know17:18
slangasekoh, sure, you can put any manner of hook in on resume via pm-utils17:18
ScottKI 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
slangasekmkrufky: c.f. /usr/lib/pm-utils/sleep.d17:20
mkrufkyslangasek: " c.f. "  ?17:20
slangasekmkrufky: hmm, properly "cf." - "compare"17:21
TheMusoScottK: I've had a similar experience with a VM in KVM.17:22
mkrufkyhmm... interesting slangasek -- thanks17:24
=== ember_ is now known as ember
TheMusohrm I think dmraid's raid5 implementation is broken somewhat.18:05
sebnerjdong: siretart: ping, the video runs in a own window in vlc. We had this bug already though18:05
pittigood night everyone18:16
* TheMuso goes to test raid5 for dmraid on real hardware to see if it makes any difference.18:17
Picklesworthevand: 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
evandPicklesworth: 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
evandThe hardest part is going to be getting the artwork / text done and signed off by the respective teams.18:24
PicklesworthI 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 unusual18:24
evandPango 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
PicklesworthThe 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 translatable18:27
ogranote that the string length varies massively between localizations18:27
PicklesworthAlas, that's true :(18:28
ograSVG 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 long18:28
evandindeed, 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
evandSo we don't get ridiculously small text.18:28
PicklesworthI guess the trick, then, is finding the right way to describe things visually since the text would have to be used mainly as captions18:30
cjwatsonyeah, I think anything more than a single sentence would probably be too much in many cases18:38
evandPretty 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. :S18:39
TheMusoWe have one big piece of crap on our hands folks, at least IMO. :S18:40
directhexpunishment for buying gigabyte!18:49
TheMusodirecthex: Not quite, if I were to explain exactly what dmraid was, I would probably destroy everything within reach right now.18:50
TheMusoTHis has nothing to do with the board itself, and everything to do with bad upstraem regression testing.18:50
TheMusoparticularly since Intel were involved with some of the coding for dmraid.18:51
directhexi thought it was mostly redhat people behind dmraid18:51
TheMusodirecthex: Yes, but intel have been helping with supporting their own metadata format. Obviously that hasn't worked too well.18:52
directhexTheMuso, is it a specific series of ICH*R which doesn't work anymore?18:52
TheMusodirecthex: 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
TheMusoBoth boards have different ICH revisions as well.18:53
TheMusoBut I doubt that the metadata is that different between them.18:54
directhexi've never trusted dmraid. always seen it as more of a concession to windows dual-booters with raid018:54
TheMusodirecthex: 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
directhexoh. lucky you :|18:55
TheMusodirecthex: 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
ScottKEspecially now that you've announced to everyone how painful taking over would be.18:57
jcastrodirecthex: see pm please!18:57
TheMusoScottK: heh true.18:57
directhexjcastro, which PM?18:57
TheMusoScottK: 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
jcastrothe one I sent you ~45 minutes ago?18:58
directhexoh, let me check my logs18:58
sorenasac: 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
sorenThere's something about some Npp-* headers or some such, right?19:01
cjwatsonKeybuk: 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 wiki19:20
Keybukcjwatson: Ted has declined to change the text on the wiki, I forwarded the results of my efforts to mdz to follow-up on19:22
sorenasac: I think I've worked it out. Who assigns the appliction guid's?19:23
walterssoren: you just generate one, there's no assignment19:24
=== bluesmoke is now known as Amaranth
ScottKTheMuso: Of course you would.  I was kidding.19:28
TheMusoScottK: heh right.19:30
superm1siretart, 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
TheMusoYou 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
siretartsuperm1: 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
sebnersiretart: \o/20:13
sebnersuperm1: does this new nvidia driver works with the new xorg?20:13
sorenwalters: Lovely... What's it used for?20:14
walterssoren: to uniquely identify extensions20:14
siretartdoes vdpau actually work in jaunty already?20:14
walterssoren: if you don't like uuids you can also name them like email addresses20:14
sorenwalters: Hmm... Ok. Does it uniquely define the particular version as well?20:19
walterssoren: no20:19
walterssoren: this is all documented fairly well here: https://developer.mozilla.org/en/Extensions20:20
sorenwalters: Ah, thanks.20:21
sorenwalters: 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
walterssoren: 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.html20:28
slangasekare those what ubufox uses, or are those the fields that Debian implemented independently?20:28
slangaseksoren: I think you want mvo for answers, here20:29
sorenmvo? Not asac?20:29
slangasekmm, possibly asac :)20:30
sorenwalters: They're headers we apparantly add to our packages that provide plugins for mozilla.20:30
slangasekthey're also present in Debian20:31
slangasekso it's possible that was implemented independently of ubufox20:31
sorenI 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
sorenI could be completely wrong, though.20:33
sorenIt's been known to happen.20:33
sorenNo, really.20:34
slangasekanyway, I don't know whether ubufox is using the XB-Npp-* headers, but if anything does in Ubuntu, that's it20:34
slangasekif ubufox doesn't use them, they're entirely orthogonal20:35
slangasekwell- parallel20:35
sorenHeh :)20:35
seb128soren: any plan to update gtk-vnc in jaunty?20:42
exarkunIs the wxPython package gravely broken in Hardy?21:04
exarkunI just found the `python-wxversion´ package.  Is that an Ubuntu thing?21:06
superm1siretart, i just updated the packaging for them, they're now shipped in nvidia-180-libvdpau-dev  binary package21:09
siretartsuperm1: I'm just skimming over the ffmpeg code in upstream trunk21:09
superm1sebner, 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 it21:09
siretartsuperm1: it doesn't seem to make sense to compile ffmpeg against these headers yet21:10
superm1siretart, due to code maturity, or is it that you get no added functionality?21:10
siretartsuperm1: the code to actually use vdpau has just been submitted one hour ago on the ffmpeg mailing list ;)21:11
superm1siretart, ah :)21:11
siretartsuperm1: see, its nice that libavcodec offers access to vdpau, but you still need support in the codecs, and/or in the video output drivers21:12
superm1siretart, right, and likely the applications will need to expose a way to change video output too21:13
siretartthe 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
siretartsuperm1: well, for mplayer and xine you can already select your video output plugin21:13
siretartI expect that you'll get yet another plugin for vdpau just like for xvmc21:13
siretartideally these players would just autodetect if that is avaiable and just use it21:14
superm1i'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 not21:14
siretartbut that isn't implemented yet. and I'm not sure if that makes sense at this point at all anyways21:14
superm1yeah mythtv does autodetection and falls back21:14
siretartmythtv implements video output itself? I thought it uses mplayer or something for that?21:15
superm1it implements itself yes21:16
siretartah, ok21:16
superm1it's got an internal playback system based on ffmpeg21:16
siretartaah, I see21:16
siretartanyway, 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 runtime21:17
siretartand hope that the vdpau API and ABI are more stable than ffmpeg's21:18
sebnersuperm1: kk, thx21:18
sebnersiretart: btw, did you notice that vlc open a further window for the video playing (again)21:19
superm1siretart, well i believe the way that things are working is that you link against libvdpau.so which will dlopen libvdpau_nvidia.so later21:20
superm1but i'm not positive21:20
siretartsebner: no, I'm still on intrepid. I wonder if I should update my laptop to jaunty yet...21:22
sebnersiretart: heh, anyways. it's happening on jaunty. I didn't want to reopen the old bug but tell you via irc :)21:22
asacsoren: yes. just add the headers21:23
siretartsuperm1: if I read the source correctly then it seems that you are right and ffmpeg would need to link against the vdpau libraries21:23
siretartsuperm1: 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
asacsoren: (if its a plugin) however, will not appear in plugin finder service until i update the plugin db21:24
siretarthi asac!21:24
superm1siretart, that's what i just did in my last upload21:25
siretartsuperm1: excellent!21:25
siretartasac: any news on the sunbird 0.9 front?21:25
superm1siretart, (https://edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180) suitable for main i'm not positive, since libvdpau.so is closed however21:25
lurelast udev seems to break lvm root for me :( - I get just BusyBox21:25
lureis this known issue21:25
superm1that's what i was worried about, it would likely need to live in restricted too still21:25
siretartsuperm1: is both libvdpau.so and libvdpau_nvidia.so closed?21:26
asacsiretart: yes. its all packaged21:26
asac(i think ;))21:26
asacprobably an accident that its not uploaded yet21:26
siretartasac: cool! where to get binaries? ;)21:26
asaciceowl is also ready21:26
asac(maybe i uploaded that to experimental)?21:26
* siretart hugs asac!21:27
superm1siretart, unfortunately :(21:27
siretartasac: it seems something went wrong with that :(21:27
lureuf, ENOKEYBUK :(21:27
asacsiretart: i guess so21:27
siretartsuperm1: hm. that makes using it challenging :)21:28
asacso havent released the packages yet as it seems ;)21:29
* asac writes this on his TODO to not forget21:29
superm1siretart, i wonder if we could try to ask nvidia to provide source for just that one library21:29
superm1it literally is a 4.5k wrapper21:29
siretartsuperm1: that would be indeed helpful21:29
siretartasac: thanks!21:30
asacthank me after the upload ;)21:31
siretartasac: I tried testing the binaries from mozilla, but they don't enable gssapi support for some reason in their binaries :-(21:31
siretartso I'm eagerly waiting for the packages, because they do21:31
asacoh they do? ... competitive advantage ;)21:38
siretartthere is even a bugzilla bug about that open in their bugtracker21:41
siretartbut being ignored for ages :/21:41
siretartanyways. it seems that sunbird still cannot accept iTIP invitations :(21:41
superm1siretart, 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 hear21:43
siretartsuperm1: excellent! thanks!21:51
superm1siretart, already got a response: http://paste.ubuntu.com/101886/21:53
siretartsuperm1: that's great news!21:54
superm1siretart, yeah and in the event that the open sourcing doesn't happen "soon", i think that stub idea would work well.21:55
siretartsuperm1: 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
siretartgiving my current available time, I'd vote for jaunty+121:55
superm1siretart, well that all depends on how accepting ffmpeg ends up being for this patchset.  all the other pieces will start to come after that21:56
siretartvdpau is currently being actively reviewed and integrated in ffmpeg right now21:56
siretarthowever I have no insight how invasive and how many patches are yet to follow, but things are very promising!21:56
superm1siretart, 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 FF21:59
pochucould some core-dev approve the intrepid task in bug 295490 please? TIA :)22:18
ubottuLaunchpad bug 295490 in liferea "Liferea doesn't start with "Aborted" error." [Medium,Fix released] https://launchpad.net/bugs/29549022:18
keeshm, that's serious code quality when you compile with -O9999999922:36
james_wkees: http://people.ubuntu.com/~jamesw/ppamadison22:39
james_wlikely to cause injuries to pets if used in anger, as it will open a web browser at every invocation currently22:39
keesjames_w: cool22:40
keesjames_w: btw, I tend to use this: http://pastebin.osuosl.org/2318322:41
james_wkees: yeah. It would be good to have some standard way of doing that22:42
brycekees, you should use ~/.cache/... and ~/.config/...22:48
directhexjames_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_wdirecthex: now there's an offer I can't refuse :-)22:49
sebnerjames_w for freedom \o/22:50
Hobbseerobbiew: consider yourself whitelisted on u-d@23:57
robbiewHobbsee: \o/23:58
Hobbseeso now I can read the team summary :P23:58

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!