[02:50] <emgent> morning
[03:10] <TheMuso> /c/c
[03:10] <emgent> heya TheMuso :)
[03:10] <TheMuso> Hey mgolisch.
[03:10] <TheMuso> gah typing
[03:10] <TheMuso> hey emgent
[03:10] <emgent> :)
[03:22] <lifeless> codehosting is down to fix a regression cuased by the rollout
[05:04] <Hobbsee_> afternoon all
[05:08] <emgent> morning Hobbsee_ :)
[05:08] <ion_> Good night
[05:09] <emgent> lol
[05:10] <ion_> It’s 7:10 here, a good time to go to sleep.
[05:10] <emgent> am ?
[05:11] <ion_> I rather avoid the AM/PM notation. I have nothing against using a 12-hour clock, but having the time of each half go from 12 to 1 to 11 is just too bereft of logic. :-)
[05:12] <ion_> So yes, 7, not 19. :-)
[05:13] <emgent> yeah, i think so. good night ion_ :)
[05:13] <ion_> :-)
[05:14] <emgent> here 6.14 am
[05:32] <lifeless> ion_: to disambiguate, use a leading 0
[05:35] <poptones> hello. does anyone know where i would submit code for newspost? the newspost webpage hasnt updated since 2003
[05:45] <poptones> ooook so much for that
[06:33] <pitti> Good morning
[06:34] <geser> pitti: Guten Morgen
[06:34] <pitti> elmo: it's off by default in hardy-updates; if you manually turned it on in /etc/default/apport, you can disable it there again
[06:35] <pitti> ion_: "prove pitti right" -> I made some joke about "go, keybuk, go! push it to -ubuntu20" :)
[06:35] <geser> pitti: can you give the MIR for libpar-dist-perl a quick look if something is missing? bug #236298
[06:36] <geser> https://bugs.edge.launchpad.net/ubuntu/+source/libpar-dist-perl/+bug/236298
[06:36] <pitti> calc: ok, thanks; I was just wondering why both tasks are open; if you are working on the bug, all is fine
[06:36] <Hobbsee_> pitti1
[06:37] <pitti> bryce, cjwatson: I agree; it's generally better to have public bugs for SRUs; a second public one WFM if the primary bug has a good justification for being private
[06:37] <pitti> arthur-: thanks; did you see the mail I wrote to the Debian BTS?
[06:37] <dholbach> good morning
[06:37] <pwnguin> A question about merges: the wiki on merges says to file a bug and assign it to yourself -- is it not okay to file a bug requesting a merge but not work on it?
[06:38] <pitti> pwnguin: no, that's not ok
[06:38] <pitti> pwnguin: there's not reason to file bugs for "plzmergekthxbye"
[06:38] <pitti> pwnguin: since we already have MoM to remind us about it
[06:38] <pwnguin> how does MoM get updated?
[06:38] <pitti> s/not/no/
[06:38] <emgent> morning people :)
[06:38] <pitti> pwnguin: it automatically updates daily (or even more often, not sure)
[06:38] <pitti> hey emgent
[06:39] <pitti> hey dholbach
[06:39] <dholbach> hi pitti
[06:39] <pwnguin> pitti: well hrm. i dont see wacom-tools on it =(
[06:41] <pitti> pwnguin: that's because Ubuntu's version is newer
[06:41] <pitti> 1:0.7.9.8-0ubuntu3 >> 0.8.0
[06:41] <pwnguin> huh
[06:41] <pitti> no idea why we have an epoch, thouch
[06:41] <pitti> though
[06:41] <pwnguin> thats no good
[06:41] <pitti> so right, in this case a merge bug would make sense
[06:42] <pitti> wacom-tools (1:0.7.9.3-2ubuntu1) hardy; urgency=low
[06:42] <pitti>    - Bump the epoch because of old Ubuntu packaging.
[06:43] <pitti>  -- Timo Aaltonen <tepsipakki@ubuntu.com>  Sun, 30 Dec 2007 18:59:29 +0200
[06:43] <pitti> tjaalton: ^ why did you do this? that'll stick forever, and we'll never have the chance to properly merge/sync with Debian?
[06:44] <pwnguin> that second part doesnt really sound like a question ;)
[06:45] <wgrant> pitti: It's been there since Dapper...
[06:45] <wgrant>   * Bump epoch to make xserver-xorg-driver-wacom newer than the one in breezy.
[06:46] <pitti> ah, then that bit got dropped from teh changelog; sorry, tjaalton
[06:46] <pitti> wgrant: ah, ok; bah, there are less sticky ways to do that...
[06:47] <wgrant> pitti: It does say 'Remaining changes
[06:47] <pitti> right
[06:48] <pwnguin> i wonder what can be done about that
[06:48] <wgrant> Nothing.
[06:48] <pitti> the only way would be to beg Debian to bump it
[06:48] <pitti> but they most likely won't
[06:49] <pitti> so we're stuck with it
[06:49] <persia> Upstream could change the versioning scheme
[06:49] <wgrant> I had a nice DD that bumped an epoch for us because we had another use for the name first.
[06:49] <geser> Guten Morgen dholbach
[06:49] <pitti> wgrant: right, but TBH, if I were only a DD, I wouldn't bump the epoch "just because"
[06:49] <pwnguin> Ron's usually pretty cool
[06:50] <pwnguin> im not sure if he'd do something quite that silly
[06:50] <Chipzz> given the "destructive" nature of epoch's, I'ld say packages that gain an epoch would be ideal candidates for the NEW queue (or similar)
[06:50] <pwnguin> what about renaming the package?
[06:51] <pitti> pwnguin: that only makes it worse
[06:51] <dholbach> hi geser
[06:51] <pitti> Chipzz: yeah, indeed
[06:51] <pwnguin> pitti: how so?
[06:51] <Chipzz> pwnguin: can't sync from debian then
[06:51] <pitti> pwnguin: then merging becomes even more difficult, and you have to additionally keep transitional packages for a while
[06:51] <Chipzz> pitti: and by gain I mean gain or increase an existing epoch
[06:51] <pwnguin> given that the software is "linux wacom" upstream and "wacom-tools" in debian/ubuntu
[06:52] <Chipzz> s/gain or/acquire or/
[06:52] <wgrant> Chipzz: I've always thought that would be a very good idea.
[06:52] <pwnguin> there MIGHT be a chance at that
[06:53] <pwnguin> clearly ubuntu wacom is in a bad spot at this point, just trying to brainstorm anything that might be better than the status quo
[06:54] <dholbach> pitti: is subscribing fixed you in the newest bzr revision of py-lp-bugs?
[06:54] <pitti> dholbach: in bzr main head, yes
[06:55] <pwnguin> is MoM amenable to some sort of special casing wacom-tools?
[06:55] <dholbach> pitti: I still get http://paste.ubuntu.com/16348
[06:55] <dholbach> pitti: nevermind
[06:55] <dholbach> pitti: it uses the system pylpbugs
[06:55] <pitti> yes, it's not yet fixed in any ubuntu release
[07:03] <pwnguin> i love it when people close bugs because i accidentally use the wrong terminology
[07:03] <wgrant>   status invalid
[07:04] <pwnguin> fortunately they went and did it three days later
[07:07] <tjaalton> pitti: yes, I've asked the debian developer to bump it but got no response
[07:07] <tjaalton> it's not maintained by the XSF
[07:07] <pitti> tjaalton: right; I wouldn't put a lot of hope into Debian bumping the epoch; thanks for asking, though!
[07:09] <pwnguin> tjaalton: well, in the mean time, is there something we can do to make wacom-tools updates more visible to Ubuntu developers?
[07:11] <pwnguin> i have an RSS feed of versions moving around in debian
[07:13] <wgrant> Maybe MoM could automagically drop epochs if they're higher in Ubuntu?
[07:13] <wgrant> Or maybe not automagically.
[07:14] <pwnguin> how many broken epochs does ubuntu have?
[07:15] <StevenK> wgrant: That strikes me as prone to breakage
[07:15] <tjaalton> pwnguin: we use this http://people.ubuntu.com/~bryce/Xorg/versions_current.html
[07:15] <pwnguin> okie
[07:16] <wgrant> StevenK: More breakage than having a differing epoch in the first place?
[07:16] <StevenK> wgrant: It isn't breakage, it's just ... different
[07:18] <tjaalton> pwnguin: there were quite a few in the X packages, but most of them are now in debian too. most of the unsyncable packages are x11proto's which have a different tarball (and no hope of a new release :)
[07:18] <tjaalton> (anytime soon)
[07:18] <StevenK> \o/
[08:24] <tkamppeter> pitti, hi
[08:24] <pitti> hi tkamppeter
[08:24] <tkamppeter> itti, it is about the blueprint of the PDF printing workflow
[08:25] <tkamppeter> pitti, you tell I did not mention what needs to be changed in CUPS.
[08:26] <tkamppeter> pitti, In the second paragraph of the "Implementation"  part I told that nothing needs to be changed in the CUPS daemon itself, only filters need to be added.
[08:27] <pitti> tkamppeter: right, I meant the filters
[08:27] <pitti> they are shipped in the cups package
[08:28] <tkamppeter> pitti, the extra filters can be shipped in the CUPS backage but they do not need to be shipped there necessarily.
[08:28] <pitti> tkamppeter: right, but that doesn't matter much
[08:28] <pitti> tkamppeter: so which filters do we still need? pstopdf?
[08:28] <tkamppeter> pitti, probably as long as they are not official upstream part of the CUPS package, they will come in an extra package.
[08:29] <pitti> tkamppeter: didn't Mike intend to switch to PDF internally for 1.4?
[08:30] <tkamppeter> The filters are the following, AFAIK: pdftopdf, imagetopdf, texttopdf, pdftoraster, pstopdf, pdftoijs, pdftoopvp
[08:31] <tkamppeter> I do not know whether Mike has this intention, this would be great. If he does it, he will grab the filters from OpenPrinting at SourceForge.jp, as these filters are not yet in the 1.4 SVN.
[08:54] <tkamppeter> pitti, I have updated the spec now.
[08:55] <pitti> tkamppeter: danke
[09:03] <pitti> seb128: would you have some time to verify bug 152246? it's my upload, so I can't officially verify
[09:03] <seb128> pitti: sure
[09:05] <pitti> seb128: urgh, that bug isn't SRUish at all; fixing
[09:08] <pitti> seb128: bug is ok now
[09:09] <seb128> pitti: ok, going to try that in a few minutes
[09:09] <seb128> pitti: I just have to upgrade before ;-)
[09:09] <pitti> seb128: thanks
[09:17] <Hewus> Does anyone know why myspell-en-au is in universe, while the other three myspell-en-* are in main?
[09:17] <cjwatson> Hewus: language-support-writing-en depends on the others, but not myspell-en-au
[09:17] <cjwatson> it's probably a bug
[09:18] <Hewus> cjwatson: thank you, I'll try and take care of it
[09:22] <tkamppeter> I am trying to get a consistent Intrepid installation onto a 32-bit PC and have a problem:
[09:22] <tkamppeter> I cannot install KDE apps because of
[09:22] <tkamppeter> The following packages have unmet dependencies:
[09:22] <tkamppeter>   kdebase-kio-plugins: Depends: kdelibs4c2a (>= 4:3.5.8-1) but it is not going to be installed
[09:22] <tkamppeter>                        Depends: kdesktop but it is not going to be installed
[09:23] <tkamppeter> but I have kdelibs4c2a 4:3.5.9.dfsg.1 on this box, so the dependency should be fulfilled.
[09:26] <cjwatson> tkamppeter: while apt's output is often suboptimal when this sort of thing happens, http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html indicates that kdebase-kio-plugins is entirely uninstallable in intrepid
[09:26] <cjwatson> so you probably won't be able to get far until that's sorted out
[09:27] <tkamppeter> cjwatson, thank you. I will keep Hardy on at least one box for now so that I can use digikam there.
[09:28] <liw> it's pretty early in the cycle to start running the development version, isn't it?
[09:28] <pitti> liw: why?
[09:28] <pitti> without people running it we'll never know what stuff to fix
[09:28] <RAOF> Probably because stuff like this happens all the time? :)
[09:29] <liw> pitti, yeah, but things break so much that one runs the risk of not getting anything else done than bug reporting :)
[09:29] <pitti> tkamppeter: what was the problem: I got disconnected, so I just got your "I have a problem" and then liw's comment
[09:29] <cjwatson> pitti: uninstallable kdebase-kio-plugins
[09:29] <pitti> hm, traditionally I upgraded to the dev release on the day we opened it
[09:30] <pitti> I don't report all those bugs yet, since they usually shake out themselves without bug spam
[09:30] <cjwatson> Keybuk: valgrind: I think you're right, looks like one of Kees' changes was responsible
[09:30] <pitti> RAOF: uninstallable packages usually don't break your box; the upgrade should just hold them back
[09:30] <cjwatson> I'll talk with him about it later
[09:31] <RAOF> pitti: Yeah.  FWIW, *I'm* running intrepid.
[09:31] <norsetto> pitti: I think we should proceed with bug 199190
[09:32] <pitti> norsetto: ah, did anyone test it?
[09:33] <norsetto> pitti: no, it runs a self test at the end
[09:33] <pitti> that doesn't check if the package actually installs and works
[09:34] <norsetto> pitti: installs it installs, wether it works or not, nobody has any idea. The package as is now doesn't install
[09:34] <Riddell> tkamppeter: KDE is stuck half way between KDE 3 and 4 and will not be installable until the rest of the main inclusion reports get reviewed
[09:34] <pitti> norsetto: if installation works, I'm good with it
[09:37] <cjwatson> pitti: bug 221664 looks nasty
[09:40] <pitti> cjwatson: eww, indeed; the documentation of "large-memory" seems to indicate that this would break on 'older' systems, but not how old 'old' is here
[09:42] <pitti> nothing that immediately jumps out on google
[09:47] <tkamppeter> pitti, it was about trying to install a KDE app in Intrepid. KDE is a komplete mess currently, we need for the KDE 4 introduction to complete.
[09:47] <pitti> tkamppeter: right; see Riddell's explanation above
[09:49] <davmor2> sbeattie: Ping
[09:50] <norsetto> pitti: dankeschoen!
[09:57] <pitti> norsetto: what for? :-) I didn't do anything yet
[09:58]  * norsetto hugs pitti 
[09:58]  * pitti hugs norsetto back
[10:13] <RicardoPerez> hi all
[10:14] <pitti> hi RicardoPerez
[10:14] <RicardoPerez> pitti: hi! one question...
[10:14] <RicardoPerez> pitti: in which packages are the firefox translations in hardy-proposed?
[10:14] <pitti> RicardoPerez: language-pack-XX-base
[10:14] <pitti> RicardoPerez: I answered your mail, too
[10:15] <RicardoPerez> pitti: yes, I saw it. I updated firefox, xulrunner & all the langpacks, but firefox is still in English... :(
[10:16] <pitti> Riddell: dpkg -l language-pack-es-base|grep es-base
[10:18] <RicardoPerez> pitti: there are directories inside language-pack-es-base, called /usr/lib/firefox-addons/extensions/langpack-es-ES@firefox-3.0.ubuntu.com and /usr/lib/xulrunner-addons/extensions/langpack-es-ES@xulrunner-1.9.ubuntu.com, but they're empty...
[10:19] <pitti> asac: ^ any idea?
[10:19]  * pitti takes a look at the source package
[10:19] <asac> hmm
[10:19] <asac> i tested es.tar.gz at least
[10:19] <RicardoPerez> pitti: correction: they contains a directory called chrome, which is empty, too
[10:20] <pitti> hm, the mozilla.tar.gz looks fine here
[10:20] <asac> source package is fine here too
[10:20]  * asac installs langpacks
[10:21]  * pitti downloads .deb
[10:21] <RicardoPerez> pitti: ....langpack-en-GB@xulrunner-1.9.ubuntu.com/chrome CONTAINS a file called en-GB.jar
[10:22] <asac> looks good here:
[10:22] <asac> http://paste.ubuntu.com/16368/
[10:22] <pitti> -rw-r--r-- root/root    157031 2008-05-29 10:52 ./usr/lib/xulrunner-addons/extensions/langpack-es-AR@xulrunner-1.9.ubuntu.com/chrome/es-AR.jar
[10:23] <pitti> -rw-r--r-- root/root     57414 2008-05-29 10:49 ./usr/lib/firefox-addons/extensions/langpack-es-AR@firefox-3.0.ubuntu.com/chrome/es-AR.jar
[10:23] <pitti> .deb looks fine here
[10:23] <RicardoPerez> mmmmm.... I don't have too many files...
[10:23] <pitti> asac: same here
[10:23] <pitti> maybe something went wrong with the Replaces:
[10:24] <RicardoPerez> http://paste.ubuntu.com/16369/
[10:25] <RicardoPerez> ricardo@kadath:~$ dpkg -l language-pack-es-base | grep ^ii
[10:25] <RicardoPerez> ii  language-pack-es-base                      1:8.04+20080527                                    translations for language Spanish; Castilian
[10:25] <asac> RicardoPerez: try dpkg -S usr/lib/xulrunner-addons
[10:25] <asac> err
[10:25] <asac> :)
[10:25] <pitti> RicardoPerez: I guess if you sudo apt-get install --reinstall language-pack-es-base, it'll work
[10:26] <asac> pitti: how to figure what happened?
[10:26] <RicardoPerez> pitti: mmmmmm.... strange.... the .deb file contains more files than I have installed... I'll try --reinstalling it
[10:26] <RicardoPerez> sudo apt-get --reinstall install language-pack-es-base
[10:26] <asac> RicardoPerez: can you keep the current state for a second?
[10:26] <RicardoPerez> asac: sure, I wait
[10:27] <asac> RicardoPerez: dpkg -S langpack-es-ES@xulrunner-1.9.ubuntu.com
[10:27] <asac> ?
[10:27] <asac> what does that give you?
[10:27] <RicardoPerez> ricardo@kadath:~$ dpkg -S langpack-es-ES@xulrunner-1.9.ubuntu.com
[10:27] <RicardoPerez> language-pack-es-base: /usr/lib/xulrunner-addons/extensions/langpack-es-ES@xulrunner-1.9.ubuntu.com
[10:27] <RicardoPerez> language-pack-es-base: /usr/lib/xulrunner-addons/extensions/langpack-es-ES@xulrunner-1.9.ubuntu.com/chrome
[10:27] <RicardoPerez> ricardo@kadath:~$
[10:27] <pitti> that looks correct
[10:28] <asac> pitti: where is the replaces state tracked?
[10:28] <asac> e.g. in /var/ ... ?
[10:28] <RicardoPerez> the es-AR.jar & es-ES.jar files are missing
[10:28] <pitti> I think what happened is that the upgrade order was done in a way that the Replaces: wasn't done properly
[10:28] <pitti> asac: should be /var/lib/dpkg/info/<package>.list
[10:29] <RicardoPerez> ... are missing in the installed, but not in the .deb...
[10:29] <asac> RicardoPerez: grep langpack-es-ES@xulrunner-1.9.ubuntu.com /var/lib/dpkg/info/*
[10:30] <asac> err,
[10:30] <asac> RicardoPerez: grep langpack-es-ES@xulrunner-1.9.ubuntu.com /var/lib/dpkg/info/*.list
[10:30] <RicardoPerez> ricardo@kadath:~$ grep langpack-es-ES@xulrunner-1.9.ubuntu.com /var/lib/dpkg/info/*.list
[10:30] <RicardoPerez> /var/lib/dpkg/info/language-pack-es-base.list:/usr/lib/xulrunner-addons/extensions/langpack-es-ES@xulrunner-1.9.ubuntu.com
[10:30] <RicardoPerez> /var/lib/dpkg/info/language-pack-es-base.list:/usr/lib/xulrunner-addons/extensions/langpack-es-ES@xulrunner-1.9.ubuntu.com/chrome
[10:30] <RicardoPerez> ricardo@kadath:~$
[10:31] <asac> RicardoPerez: did you ever had the language-pack-gnome-es-base installed?
[10:31] <pitti> asac: -es was one of the packages where the gnome update packages had a newer version than -base, right?
[10:31] <RicardoPerez> ricardo@kadath:~$ dpkg -s language-pack-gnome-es-base | grep Status
[10:31] <RicardoPerez> Status: install ok installed
[10:31] <RicardoPerez> ricardo@kadath:~$
[10:31] <pitti> asac: that just affected three languages AFAIK (es, pt, and zh?)
[10:32] <pitti> asac: so for those we have three different versions of translations
[10:32] <asac> pitti: we have, but the packages are similar to the other packages
[10:32] <asac> it was basically just a manual update that shipped a better chrome.manifest
[10:33] <asac> dont see why it would make any difference over lets say -de
[10:33] <asac> pitti: ah ... you mean because those were in language-pack-gnome-es
[10:33] <asac> yeah. maybe dpkg has problems to deal with three replaces ;)
[10:34] <pitti> right
[10:34] <pitti> I didn't get reports for other languages about this kind of problem
[10:35] <asac> yes, but -es is a popular language ... so maybe a quick catch
[10:35] <pitti> asac: so maybe; (1) update language-pack-es-base (files), then (2) update language-pack-gnome-es{,-base}
[10:36] <pitti> lp-es-base replaced lp-gnome-es-base, and that conflicted with lp-gnome-es (still in the old version)
[10:37] <asac> yeah
[10:38] <asac> so we have to put them into language-pack-es as a first measure? or are we brave enough to fix conflicts/replaces?
[10:39] <asac> pitti: ? i could upload language-pack-es -zh -pt if thats what you like
[10:41] <RicardoPerez> I can downgrade my langpacks and wait for new langpacks updates uploaded into hardy-proposed, if you want...
[10:41] <pitti> asac: no idea how to solve it, I'm afraid, as long as we don't understand what's happening in the guts of dpkg
[10:42] <asac> might mvo help?
[10:42] <pitti> asac: we might need to add a Conflicts: to force upgrade ordering
[10:42] <pitti> i. e. ensure that we don't install the new language-pack-es-base before upgrading language-pack-gnome-es{,-base}
[10:43] <pitti> RicardoPerez: can you purge langpacks, install the ones from hardy, and then manually upgrade first -gnome-* and then language-pack-es{,-base}? that should work
[10:43] <RicardoPerez> pitti: ok, i'll do that in a moment
[10:43] <pitti> RicardoPerez: gracias
[10:49] <RicardoPerez> pitti: works!
[10:49] <pitti> RicardoPerez: great
[10:49] <Hobbsee> cjwatson: when is supposed to be the accepted time that ppas will be able to build for intrepid?
[10:49] <cjwatson> Hobbsee: I didn't know it was delayed
[10:50] <pitti> RicardoPerez: just for confirmation, if you do the same, but first upgrade language-pack-es{,-base} and then *gnome*, it fails?
[10:50] <cjwatson> should at most be a matter of chroots being set up? (i.e. -> infinity)
[10:50] <Hobbsee> cjwatson: apparently it's delayed, because it's waiting on word from the distro team.
[10:50] <Hobbsee> infinity: poke
[10:50] <cjwatson> gar
[10:50] <RicardoPerez> pitti: I'll do that in a moment, again :)
[10:50] <cjwatson> ok, I'll go talk with them
[10:50] <Hobbsee> cjwatson: cool, thanks
[10:50] <pitti> RicardoPerez: thanks a lot; if that is the reason, we can add a Conflicts:
[10:53] <RicardoPerez> pitti: as you say, if I do the upgrade in the reverse order, it don't work :)
[10:54] <pitti> superm1, tseliot: I just tried to DKMSify http://linuxtv.org/hg/v4l-dvb (I want to provide a driver backport for hardy), but I have some trouble with upstream's Makefile; it doesn't build any modules when being called from /lib/modules/2.6.24-17-generic/build; do you have some experience with that and could help me?
[10:54] <pitti> RicardoPerez: awesome; thanks a lot for testing!
[10:54] <RicardoPerez> pitti: thanks to you :)
[10:55] <pitti> asac: ok, so AFAICS we should add "Conflicts: language-pack-gnome-es (<< 8.04+20080527), language-pack-gnome-es-base (<< 8.04+20080527)" to language-pack-es-base? likewise for pt and zh?
[10:55] <cjwatson> Keybuk: around? I think enabling PPAs for Intrepid requires a techboard member
[10:56] <Keybuk> cjwatson: err, why?
[10:57] <tseliot> ﻿pitti: I have no experience with that driver however if you upload your code somewhere I think I can give you hand with DKMS
[10:57] <Keybuk> is there a button that needs to be pushed?
[10:57] <cjwatson> Keybuk: apparently it requires turning on 'support-virtualization' in each distroarchrelease
[10:57] <Keybuk> ?
[10:57] <RicardoPerez> now I must leave. see you!
[10:57] <cjwatson> https://launchpad.net/ubuntu/intrepid/amd64/+admin, https://launchpad.net/ubuntu/intrepid/i386/+admin, https://launchpad.net/ubuntu/intrepid/lpia/+admin
[10:57] <pitti> tseliot: that's the (essential part of) the Makefile: http://paste.ubuntu.com/16376/
[10:57] <Keybuk> ENOPERM
[10:58] <cjwatson> Keybuk: seriously? argh
[10:58] <Keybuk> duckie required, I suspect
[10:58] <Keybuk> or maybe infinity
[10:58] <Keybuk> or my tech board membership expired already
[10:58] <cjwatson> your techboard membership is still active
[10:58] <cjwatson> though five days - shouldn't that be extended?
[10:58] <Keybuk> dunno, ask sabdfl ;)
[10:59] <pitti> tseliot: running "make" in /var/lib/dkms/v4l-dvb/0.20080328/build/ works, but running make KERNELRELEASE=2.6.24-17-generic -C /lib/modules/2.6.24-17-generic/build M=/var/lib/dkms/v4l-dvb/0.20080328/build (as dkms does) doesn't
[10:59] <pitti> tseliot: dkms passes M=/var/lib/dkms/v4l-dvb/0.20080328/build to make
[10:59] <asac> pitti: yes that makes sense
[10:59] <asac> pitti: actually, shouldn't the language pack conflict all other lang packs with lower version anyway?
[10:59] <pitti> tseliot: apparently the kernel upstream Makefile is supposed to handle M=, but that seems to need some support in the target Makefile, too
[11:00] <pitti> asac: AFAIR we used Replaces: instead of a million Conflicts: to avoid confusing apt-get
[11:00] <pitti> asac: and I have never seen it fail for the 'usual' case (just two versions)
[11:01] <pitti> asac: this is a special kind of a three-way replaces:, which apparenlty has issues
[11:01] <asac> pitti: yes, i think its a rare thing that translations migrate from gnome to normal and vv.
[11:01] <tseliot> ﻿pitti: what does your dkms.conf look like?
[11:01] <pitti> asac: so, it's certainly worth testing to generally replace some Replaces: with Conflicts:, but we shouldn't overdo it
[11:01] <asac> yep. lets please keep the solution as simple as possible for hardy
[11:02] <asac> and review the conflicts/replaces in intrepid ;)
[11:02] <asac> pitti: btw, could langpack-o-matic pass the lsb release version the package is targetted for?
[11:02] <pitti> tseliot: http://paste.ubuntu.com/16378/ (just the first 5; there are 209 modules built from that)
[11:03] <asac> i need to maintain different blacklists for different releases for instance
[11:03] <pitti> asac: you mean the target? like gutsy-proposed, intrepid, etc? yes, that's no problem
[11:03] <asac> yes
[11:03] <asac> for me the lsb version would be better though ;)
[11:03] <asac> but well.
[11:03] <pitti> asac: like 8.04?
[11:03] <asac> yes
[11:03] <pitti> asac: no problem, you can have that as well
[11:03] <asac> thats what i current use locally. but i can adapt my transformer if its easier for you
[11:03] <pitti> I have a code name -> version mapping anyway
[11:04] <asac> ah good
[11:04] <pitti> asac: however, that will loose the distinction between release and -proposed; do you need that?
[11:04] <asac> maybe <lsb_version> <purpose> => 8.04 updates (if things go to proposed)
[11:04] <asac> but yeah. at best just pass the whole target ... ill take care of the rest
[11:04] <pitti> asac: I don't have a meaningful lsb_release there, just 'hardy-proposed' and a mapping to '8.04'
[11:05] <asac> ok ... Ill let you know when i have setup the code to deal with that. but after this update ;)
[11:06] <pitti> asac: I think manually adding the three conflicts: is minimally invasive and the easiest solution I can think of; WDYT?
[11:06] <tseliot> pitti did you add a line like the following to your dkms.conf? MAKE[0]="make module KERNDIR=/lib/modules/$kernelver SYSSRC=$kernel_source_dir"
[11:06] <pitti> asac: I'll do that in langpack-o-matic, I have everything there already
[11:07] <asac> i think they should be fine.
[11:07] <pitti> tseliot: no, I didn't; I need to?
[11:07] <asac> we should test the upgrade path for those three afterwards.
[11:07] <pitti> yes, absolutely
[11:07] <asac> let me know when they are in so i can test all combinations in a chroot
[11:07] <asac> well ... all combinations i have in mind ;)
[11:07] <tseliot> ﻿pitti: yes, you should, so that DKMS can build the module
[11:08] <pitti> tseliot: and that won't run make 209 times?
[11:08] <pitti> tseliot: it just needs to run 'make' in the target dir, that's all
[11:08] <pitti> s/target/dkms source directory/
[11:09] <tseliot> ﻿pitti: why should it run make 209??? DKMS is a sensible system
[11:09] <asac> pitti: will you reupload all? if so we have to take care the the right fi.tar.gz is used ;)
[11:09] <tseliot> pitti: yes, I picked that up
[11:09] <asac> rookery should be fixed in case you want to recreate them for real
[11:09] <pitti> asac: no, I was just going to upload -zh, -es, and -pt
[11:09] <asac> ok good
[11:09] <pitti> asac: I already put your -fi to rookery
[11:10] <asac> pitti: what do you mean by "put my -fi" ? do you preserve the tar.gz ?
[11:10] <pitti> asac: yes, I unpacked your sources to rookery
[11:10] <asac> ah ok. didn't know that you use some kind of source caching. grewat
[11:10] <pitti> it shouldn't actually matter, but just to be on the safe side
[11:10] <asac> yep
[11:12] <tseliot> ﻿pitti: let me know how it goes ;)
[11:13] <pitti> tseliot: I will, thanks for the hint! just fixing the langpack mess first
[11:15] <doko> pitti: is it possible to a) add a new binary package to hardy-proposed, b) add a new source package?
[11:16] <cjwatson> it is technically possible and sometimes also allowed by policy ;-)
[11:16] <pitti> doko: technically yes, practically we did that only once or so
[11:16] <pitti> it needs a really really good justification anyway
[11:17] <doko> pitti: noticed that libmudflap0-4.1-dev is not built anymore, so -fmduflap doesn't work with gcc-4.1
[11:18] <pitti> doko: do we care enough about 4.1 to fix that in hardy?
[11:18] <doko> pitti: the other package would be ca-certificates-java (ca-certificates built for java); cannot be built from ca-certificates, because this is in main, and requires at least openjdk as a b-d
[11:19] <doko> pitti: well, I don't care that much about 4.1
[11:19] <pitti> java can't use /etc/ssl/certs/*?
[11:20] <doko> no, has it's own format
[11:20] <pitti> yay
[11:21] <mgolisch> lib/security/cacerts or so is the file in the java installation directory
[11:21] <pitti> mgolisch: well, a mere path could be worked around with a symlink
[11:22] <pitti> but if it actually uses its own encoding of SSL certificates, that's more tricky
[11:22] <mgolisch> yeah the certs are saved in a so called keystore file
[11:23] <pitti> . o O { just gotta love the Sun guys for not using already existing platfom independent standard formats ... }
[11:23] <pitti> mgolisch: do you know if it is possible to generate them on the client side?
[11:23] <pitti> mgolisch: then we could just add that call to ca-certificate's postinst
[11:24] <pitti> since ca-certificates itself can change, and the user can reconfigure which certificates he wants, that would then automatically apply to Java as well
[11:24] <cody-somerville> woot woot
[11:24] <cody-somerville> I isolated the Xubuntu black screen of death bug :]
[11:24] <asac> pitti: do you have powers to proactively prevent xulrunner source package from being synched?
[11:24] <pitti> asac: yes
[11:24] <pitti> asac: we can add it to the sync blacklist
[11:25] <asac> the new package is still in experimental, but once it reaches unstable the xulrunner source will ship the same package names we have in xulrunner-1.9
[11:25] <asac> (+ some more)
[11:25] <asac> not sure what would happen :/
[11:25] <pitti> asac: but as long as our's has 'ubuntu' in the version, it won't get autosynced
[11:25] <pitti> asac: and in principle, if Debian adopts our changes, we could sync; or is there a general reason why we will never ever do that?
[11:26] <asac> pitti: well. they still have a package split we dont want
[11:26] <asac> they ship a -common package and a libmozjs for which mike added so-versioning
[11:27] <asac> (not sure why he kept that as afaik there is no standalone rdepends on libmozjs)
[11:27] <asac> pitti: and the bad is that debian doesnt use a patch-system ... so no sync possible
[11:27] <pitti> eww
[11:28] <asac> yeah ... glandium rolled-back his opinion that it is sane to have a patch-system for mozillas
[11:28] <asac> not sure why
[11:28] <asac> now he has a private git archive
[11:28] <doko> pitti: it doesn't help, I can't assume that openjdk is installed when ca-certificates is installed
[11:28] <pitti> doko: sure, but you can test whether the conversion binary exists
[11:29] <pitti> [ -x /usr/sbin/update-java-ssl ] && /usr/sbin/update-java-ssl || true
[11:29] <pitti> something in that spirit
[11:29] <pitti> doko: of course that only works if the client side actually has the means to update them
[11:30] <pitti> if that needs a ton of programs that users don't usually have, that'd be bad
[11:30] <pitti> (like the issue with tzdata)
[11:30] <doko> pitti: sorry, this is insane. you can't assure that this exists. the alternative is to add this to openjdk, sun-java5, sun-java6, and generating duplicate copies. which is more insane
[11:31] <doko> it won't be a problem if openjdk is in main
[11:31] <pitti> doko: that was my question; I didn't know whether openjdk ships the tool to modify that keyring
[11:31] <pitti> doko: it's not a question of "you can't assure"
[11:31] <doko> ahh, yes. openjdk ships it
[11:31] <pitti> it's a question of "does openjdk ship the tool or not"
[11:32] <pitti> I'm just concerned that it needs the same debconfiscation as ca-certificates itself, and the user needs to configure it twice
[11:33] <pitti> well, it could use ca-certificate's debconf values, I guess
[11:46] <pitti> asac: all fixed, uploaded, tripe-checked, accepted
[11:47] <Keybuk> mmm, tripe
[11:58] <siretart> asac: do you happen to have an sunbird 0.8 backport for hardy in some ppa?
[11:58] <asac> siretart: ~mozillateam
[12:00] <siretart> awesome! thanks!
[12:29] <cjwatson> mvo: should bug 235454 be an upgrade-fix target for 8.04.1?
[12:29] <cjwatson> oh, sorry, ignore me, that's an intrepid bug
[12:33] <mvo> cjwatson: aha, ok - maybe a 8.10 upgrade-fix then :) (/me reads the bug)
[12:33] <cjwatson> nah, never mind, it's being sorted in Debian by the looks of things
[12:33] <cjwatson> I misread it as a hardy problem
[12:33]  * mvo nods
[12:34] <a7p> hi everyone - I've got a rather complex bugreport and I could use some help - it involves a java-applet, compiz and may be cups - it causes either a reboot or an X11-restart.
[12:39] <Keybuk> what's the standard way out of a PulseAudio wedge?
[12:39] <lool> killall pulseaudio and relaunch it
[12:39] <lool> At least that's how I do it, but make sure nobody grabs the alsa device in between
[12:40] <lool> I think you want --log-target=syslog if you want the new one to behave like the autostarted one
[12:43] <Keybuk> killing pulse kills most of the apps with it
[12:45] <lool> (Not for me)
[12:46] <lool> It does have trouble with flash if playing, but if e.g. I'm paused on a flash page such as youtube, killing pa will allow the page to play afterwards
[12:55] <munckfish> pitti: I've just found this http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483399. Are you working PS3/Cell stuff then?
[13:01] <persia> munckfish: Ideally, although there are lots of outstanding bugs.
[13:03] <munckfish> persia: Ok ... I think I see what you mean - I'm working on the PS3 Port of Ubuntu so I'm aware of the issues, I'm trying to find out if Martin is too.
[13:03] <munckfish> I have a feeling there maybe too camps of dev effort working in parallel not aware of each other
[13:04] <persia> munckfish: Chase the ubuntu-ppc team as a point of coordination
[13:06] <munckfish> persia: I just tried to join #ubuntu-ppc but it kicked me said invite only do you know anything about that?
[13:06] <persia> munckfish: Nothing, I'm afraid.
[13:07] <liw> might be related to all the changes to freenode servers this past week
[13:07] <cjwatson> munckfish: I think pitti was just doing the initscripts merge
[13:08] <munckfish> cjwatson: ok thx. I just noticed Arthur Loiret has been putting libspe2 packages into debian
[13:08] <munckfish> Just want to make sure that I'm aware of what is happening and where in relation to PS3 stuff
[13:08] <munckfish> and that these folks know our Port project exists too
[13:09] <munckfish> Who is working on the powerpc port? Is there any particular person I should speak to?
[13:10] <cjwatson> I don't know of anyone who might be a powerpc port leader
[13:10] <cjwatson> I think "just do it" comes into play
[13:10] <munckfish> ok I thought that maybe the case
[13:11] <munckfish> I noticed there was no mailing list
[13:11] <munckfish> I'm beginning to wonder if the cell mailing list we have is not as useful as maybe just sticking to ubuntu-devel in terms of visibility
[13:14] <seb128> calc: hi, could you look at bug #234532 when you have some time? that seems to be an annoying issue for some openoffice hardy users in corporate environments
[13:22] <emgent> morning dendrobates- :)
[13:26] <pitti> munckfish: actually no, I'm just the messenger; I just sent our patch to Debian
[13:26] <pitti> munckfish: I was told that arthur- was working on Cell in Debian, I CC'ed him
[13:27] <munckfish> pitti: hi, ok I see. So where/who did our patch come from?
[13:27] <pitti> munckfish: doko, I think
[13:27] <munckfish> Arthur is also working on toolchain stuff for us I believe?
[13:27] <munckfish> Ok I see, thx for the info
[13:27] <pitti> I honestly don't know
[13:27] <munckfish> us = ubuntu in general
[13:28] <munckfish> ok pitti thx I'll speak with them
[13:28] <pitti> munckfish: I know that doko and cjwatson were involved with it, but I don't know any details
[13:28] <cjwatson> the patch in question is in hardy
[13:28] <cjwatson> and I think was in gutsy as well
[13:28] <pitti> munckfish: I'm just reasonably sure that nobody in Ubuntu is working on it right now
[13:28] <munckfish> pitti: well I'm trying to
[13:28] <munckfish> with cjwatson's help
[13:29] <munckfish> and others ofcourse
[13:29] <persia> pitti: Are you sure about that?  I thought there were still a few people on the ubutu-ppc team, and there was certainly discussion from a few forums folk in the last forums meeting
[13:29] <munckfish> so the powerpc team are sort like a vapour-team
[13:29] <pitti> persia: right, sorry; I meant "in Canonical's Ubuntu team"
[13:29] <munckfish> ?
[13:29] <munckfish> :D
[13:30]  * persia encourages collective coordination, regardless of sponsorship
[13:30] <cjwatson> persia: I haven't seen much in the way of patches; though I could be missing something
[13:30] <munckfish> cjwatson: you mean from folk seeming to care about the ppc port?
[13:31] <persia> cjwatson: True.
[13:31] <doko> arthur broke his shoulder at rugby, so he may not respond quickly ...
[13:31] <cjwatson> munckfish: right, with the exception of yourself
[13:31] <cjwatson> doko: there, clearly hackers should avoid all physical activity for safety reasons
[13:31] <munckfish> doko: doh, nasty. Rugby is a dangerous game :D
[13:32] <pitti> well, then he might have gotten a tennis arm from too many mouse clicks in WoW
[13:32]  * doko hits cjwatson (and hopes he doesn't get injured himself) ;-p
[13:32] <munckfish> yeah I think devs have got to stick with non-contact
[13:32]  * cjwatson blocks
[13:32] <ogra> doko, point him to the a11y team, injured people make awesome testers :)
[13:32] <munckfish> :D
[13:32] <pitti> doko: consider Colin's Karate belt first :)
[13:33] <pitti> cjwatson: so, no sparring contest on the next allhands then?
[13:33] <cjwatson> I'm a bit rusty ...
[13:33] <cjwatson> I might be better off tying somebody up with the belt
[13:33] <pitti> lol
[13:33] <ogra> lol
[13:34] <\sh> ogra, was missing you at LT ;)
[13:34] <ogra> \sh, yeah, no trains that could get me there :(
[13:34] <Mithrandir> cjwatson: kinky. ;-P
[13:34] <\sh> ogra, I heard it...sad you really missed a good party
[13:34] <ogra> yeah
[13:34] <ogra> well, i did some work instead :)
[13:35] <pitti> \sh: too bad I missed the BBQ
[13:35] <mvo> ogra: oh? no trains?
[13:35] <\sh> pitti, I missed you, too :)
[13:36] <ogra> mvo, well, trains with unpredictable schedules .... they told me the next northbound train *could* go in 90mins but no guarantee it goes at all and no guarantee that i get any connection in hanover
[13:36] <mvo> oh, because of the thunderstorms at the weekend?
[13:37] <ogra> i gave up after these 90min being told the same
[13:37] <\sh> pitti, but we really had luck yesterday on our way back...really..
[13:37] <ogra> mvo, yeah, broken tracks etc
[13:37] <munckfish> cjwatson: in response your last comments on on LP 221647
[13:37] <munckfish> I don't think we're aiming at 8.04.1 anymore
[13:38] <cjwatson> munckfish: oh
[13:38] <munckfish> I didn't feel Ben C wanted to consider PS3 patches in the hardy kernel
[13:38] <munckfish> He suggested it would be tough getting them in
[13:38] <munckfish> So refocusing on Intrepid
[13:38] <cjwatson> what is its current state? completely broken or only slightly broken?
[13:38] <munckfish> Hardy?
[13:38] <cjwatson> I gather you got X fixed
[13:38] <cjwatson> yes, hardy
[13:39] <munckfish> Without Ben H's vmemmap fix it's crippled with on ~80MB of RAM
[13:39] <ogra> no kernel sounds slightly serious
[13:39] <cjwatson> ogra: it has a kernel, it's just not very good
[13:39] <ogra> ah
[13:39] <munckfish> His patch will be in Geoff's 2.6.25 patch set
[13:39]  * ogra didnt read the bug, only judged by description
[13:39] <munckfish> and I think Geoff said it would be back ported
[13:40] <munckfish> cjwatson: is there any point in cont. effort for Hardy?
[13:40] <munckfish> is that what you're thinking?
[13:40] <cjwatson> it's up to you, I just thought since we were partly there it might be worth a few tiny tweaks
[13:40] <munckfish> Well me too
[13:40] <cjwatson> we're basically past the deadline so no more substantial changes
[13:41] <cjwatson> I was just wondering whether I should push for the trivial backport of base-installer so that it at least installs the right kernel!
[13:41] <munckfish> Yeah, well, even if we fix the kernel, I've no idea what the installer/upgrade situation would be
[13:41] <cjwatson> bear in mind that upgrades from gutsy are going to have to go through hardy
[13:42] <cjwatson> so that will need to at least minimally work, or else people will have to reinstall
[13:42] <munckfish> yes of course your right :(
[13:42] <cjwatson> I suppose I can always do the base-installer thing for 8.04.2
[13:43] <munckfish> Well, we have a couple of major issues with X which are now fixed in Intrepid they would need to be SRU'd
[13:43] <munckfish> Then we have 2 problems with the kernel - the 80MB RAM thing
[13:43] <munckfish> and it not being able to power off
[13:43] <munckfish> Power off I've not explored much yet
[13:43] <munckfish> but I saw some one said it was affected by the video mode chosen
[13:43] <munckfish> so it could also be RAM related
[13:44] <munckfish> If there's a chance of getting the vmemmap patch accepted into the kernel then I agree we should try for 8.04.1 or 8.04.2
[13:44] <cjwatson> http://people.debian.org/~cjwatson/tmp/ssh-client-blacklist.diff <- prevent ssh from sending blacklisted keys. Anyone have a good reason for hating that idea?
[13:44] <munckfish> I really need to get an opportunity to chat with Ben C directly at some point
[13:45] <munckfish> our communication has bee via sporadic email so far
[13:45] <Mithrandir> cjwatson: might lose you access to a system if your only access is through a broken key.
[13:45] <persia> cjwatson: The need to get to a remote server insecurely to update the keys because you've been alseep for a month?
[13:45] <Mithrandir> cjwatson: make it overridable with --yes-I-know-this-is-insecure or something.
[13:45] <cjwatson> Mithrandir: it is, -o UseBlacklistedKeys=yes
[13:46] <cjwatson> the ssh-add bit isn't overridable, but I don't think that's so big a deal
[13:46] <Mithrandir> then it sounds fine to me
[13:46] <cjwatson> at the moment any key already in the agent is used anyway
[13:47] <cjwatson> not sure whether to bother with changing that
[13:47] <cjwatson> inclined not to as agents have a finite lifetime anyway
[13:48] <pitti> tseliot: nice! a simple "MAKE[0]=make" did the trick
[13:49] <tseliot> ﻿pitti: easy ;)
[13:52] <pitti> tseliot: so, the thing won't actually respect KERNELRELEASE=2.6.24-17-generic that way, but for a first test that's pretty good
[13:54] <calc> seb128: ok will look, about to be in an ooo meeting
[13:55] <seb128> calc: thanks
[13:57] <tseliot> pitti: DEST_MODULE_LOCATION[0] should be enough. Furthermore you can build a module for a specific kernel with "dkms add -m name_of_the_module -v version_of_the_module -k name_of_the_kernel", ﻿"dkms build -m name_of_the_module ﻿-v version_of_the_module  -k name_of_the_kernel", ﻿"dkms install -m name_of_the_module ﻿-v version_of_the_module -k name_of_the_kernel"
[13:58] <pitti> tseliot: right, that's what I used; I just wonder whether there is a command "rebuild/install all dkms modules which are not built/installed for the current kernel"?
[14:00] <tseliot> pitti: if such modules are installed as dkms packages and they have AUTOINSTALL="yes" in the dkms.conf it will all be done automatically
[14:00] <pitti> tseliot: i. e. if DEST_MODULE_LOCATION[4] is not specified, it will fallback to DEST_MODULE_LOCATION[0]?
[14:00] <pitti> tseliot: aah
[14:00] <nxvl> seb128: can you please take a look at #182690, i'm experiencing the problem since the last upload
[14:00] <nxvl> seb128: i have added a screenshot of the error
[14:01] <seb128> nxvl: no clue about this one, I don't work on f-spot and the bug shows that's not a new version regressions, you would have better chance to get an useful reply by contacting the people who work on this code using bugzilla.gnome.org
[14:02] <tseliot> pitti: the man page says that the number, say, 4, "must be the same for each of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION". I don't think there's a fallback system.
[14:03] <pitti> tseliot: right, I did't see that either; but you said "DEST_MODULE_LOCATION[0] should be enough"
[14:03] <pitti> tseliot: well, MAKE[0] has this kind of fallback
[14:03] <tseliot> pitti: sorry, I should have omitted the number
[14:03] <nxvl> seb128: mm i think i'm having a different problem, the error i'm getting is different, are you able to open the image i have pasted?
[14:04] <seb128> nxvl: yes, that's a standard png, eog open it fine, why?
[14:04] <nxvl> seb128: also, i was able to upload my photos until the last upload
[14:04] <seb128> or my web browser rather
[14:04] <tseliot> ﻿pitti: but "MAKE" is not included in the line which I quoted ;)
[14:04] <nxvl> seb128: because here i'm getting Bad Gateway error
[14:04] <pitti> tseliot: right, I understand; I was just misled to think that a similar [0] default exists for the paths as well
[14:04] <seb128> nxvl: this bug has been opened months ago
[14:05] <seb128> nxvl: I doubt that's a new version regression
[14:05] <tseliot> ﻿pitti: mdomsch is the right person to ask about this. He taught me a few things on DKMS
[14:05] <nxvl> seb128: yep, but the error i'm getting is a different one i think i just reported my comment here and not in a new one
[14:05] <nxvl> seb128: because the problems are similar
[14:05] <pitti> tseliot: right
[14:05] <pitti> tseliot: just testing teh AUTOINSTALL now
[14:06] <pitti> yay, it works \o/
[14:06] <nxvl> seb128: and as i have seend on the f-spot changelog you changed something on the flickr net thing of f-spot
[14:06]  * pitti hugs dkms
[14:06] <seb128> nxvl: hum, you should really not abuse an old bug if you have a different error, that's confusing for everybody
[14:06] <nxvl> seb128: and something about it is on the error
[14:06] <tseliot> ﻿pitti: it's a great feature :-)
[14:06] <pitti> tseliot: ah, except that the build failed
[14:06] <nxvl> seb128: mm, maybe you are right, i will open a new bug for this
[14:06] <seb128> nxvl: thanks
[14:07] <tseliot> ﻿pitti: what's changed?
[14:07] <seb128> nxvl: your issue seems to be http://bugzilla.gnome.org/show_bug.cgi?id=533254
[14:07] <pitti> tseliot: (just forgot to install a -headers-generic dependency, PEBCAK)
[14:07] <tseliot> ﻿﻿pitti: if you tried another kernel just make sure that the headers for that kernel are installed
[14:07] <seb128> nxvl: the bug indicates the guy who had the bug had networking issues
[14:08] <pitti> tseliot: I dpkg -i'ed  -16-generic , but not -16
[14:08] <tseliot> pitti: LOL that's what I thought
[14:08] <pitti> building now
[14:08] <cjwatson> nxvl: re the libssh/libssh-2 conversation the other day, where I think you suggested getting in touch with me; I wouldn't bother if I were you, I only care about openssh not the other implementations
[14:10] <tseliot> ﻿pitti: I can't wait to tell you about my new project: X-Kit. I'll send you an email.
[14:11] <ogra> argh
[14:11] <ogra> another kit
[14:11] <ogra> will we rename gnome to DesktopKit  ?
[14:12] <tseliot> ﻿ogra: no, it will be GNOMEKit
[14:12] <ogra> heh
[14:12] <tseliot> the "Kit" suffix makes it sound so original :-P
[14:13] <ogra> "this app was originally invented in nightrider episode ...."
[14:13] <Pici> Wouldnt it be kitt then?
[14:13]  * pitti hands ogra a K
[14:13] <ogra> Pici, pfft details
[14:14] <nxvl> cjwatson: the guy was only asking for the difference of this 2 libraries, and i thought you where the person who should know
[14:14] <ogra> pitti, K-Kit ? for KDE ?
[14:14] <cjwatson> nxvl: I don't, I've been studiously ignoring those libraries
[14:14] <pitti> ogra: I meant "Knight", not "Night"
[14:14] <ogra> ah, right
[14:14] <nxvl> cjwatson: oh ok
[14:14] <ogra> its a while ago ... i'm getting old, you know :)
[14:15] <nxvl> cjwatson: i just assosiate ssh* with you
[14:15] <nxvl> cjwatson: sorry about thet
[14:15] <nxvl> that*
[14:15] <nxvl> seb128: Bug #236783
[14:15] <nxvl> seb128: i will take a look at the bugzilla bug and try to fix it later
[14:15] <seb128> nxvl: did you read my comment on the chan?
[14:15] <nxvl> now i need to go to work
[14:16] <seb128> nxvl: the one saying that's likely an network issue on your side?
[14:16] <nxvl> seb128: not before filing the bug
[14:16] <nxvl> seb128: the thing is that i have tried on different conections
[14:17] <nxvl> seb128: well, i will read the bug report and try to discard networking problems
[14:17] <nxvl> seb128: thanks for your help
[14:17]  * nxvl HUGS seb128 
[14:17] <seb128> you are welcome
[14:18] <seb128> good luck with that, let me know if you figure something, maybe it's shocking on an image which takes a while to transfert or something
[14:18] <nxvl> seb128: i have also tried with 2 different bunch of pictures :S
[14:18] <nxvl> is really weird
[14:19] <seb128> ok, weird
[14:19] <nxvl> now need to run
[14:19] <nxvl> see you later
[14:19] <seb128> later
[14:36] <ion_> mvo: http://heh.fi/tmp/recovery-mode-dpkg.patch
[14:40] <ion_> mvo: Btw, how about using aptitude instead of apt-get there? It is more intelligent. One could use -o aptitude::Delete-Unused=false to prevent any unintended removals.
[14:41] <mvo> ion_: let me check the diff
[14:44] <mvo> ion_: looks good, thanks. aptitude> no real reason I'm just in the habit of using apt-get more
[14:45] <superm1> pitti, tseliot looks like you solved the mess with dkms/v4l-dvb if i'm not mistaken?
[14:45] <pitti> superm1: mostly, yes
[14:45] <superm1> okay good :)
[14:45] <pitti> superm1: thanks
[14:47] <ion_> mvo: When there’s something presumably broken and the user wants a program to Just Fix It™, aptitude is probably the way to go. :-)
[15:07] <asac> ogra: how about joining #ubuntu-mobile ?
[15:47] <pitti> zul: seems you didn't forward our openvpn patches to Debian? I did that now, but please do it in the future as well
[15:47] <zul> pitti: sorry about that
[15:47] <pitti> zul: no problem
[15:48] <pitti> zul: we have just three easy things left (LSB init script, README.Debian, udev debconf), I changed the latter in a way to be Debian compatible; I hope they'll be applied soon, then we can sync again
[15:49] <zul> pitti: cool with me
[15:50] <pitti> argh, except that our orig.tar.gz is different; apparenty Debian rolled their own :/
[15:50]  * pitti uploads again
[15:55] <pitti> Keybuk: do you plan to do the devmapper merge soon, or shall I take it?
[15:56] <Keybuk> pitti: feel free
[15:56] <Keybuk> I thought you were already doing that one ;)
[16:08] <sistpoty|work> bryce, soren: do you have any clue about bug #193323 (since I was told, that kvm suffered from the same bug once, but actually works in hardy)
[16:09] <soren> sistpoty|work: bryce put in a quirk in dexconf.
[16:09] <sistpoty|work> soren: ah
[16:09] <soren> sistpoty|work: ...It detects if we're running in a kvm instance, and then shoves cirrus in the xorg.conf.
[16:09] <sistpoty|work> soren: ah, k... then I guess I don't need to dig through diffs between kvm and qemu any longer :)
[16:11] <soren> sistpoty|work: Heh. No.
[16:11] <soren> sistpoty|work: The cirrus driver really, *really* should just list the pci vendor/device id's.
[16:17] <sistpoty|work> soren: actually I doubt, that the cirrus driver is to blame. imho what's going wrong is that the defaultdepth changed to 32 (and the real cirrus card) just doesn't support 32bpp, and so no valid modes are found
[16:19] <soren> sistpoty|work: Maybe I'm getting things mixed up here. What I seem to remember is that the pci vendor/device id of the emulated cirrus card is not listed as one handled by the cirrus X driver, so we needed to poke stuff into xorg.conf to make it work.
[16:20] <sistpoty|work> soren: no, that doesn't seem to be the case, as the attached log does show that qemu detects the correct cirrus card
[16:20] <soren> sistpoty|work: Ah, right. I was thinking of vmware.
[16:20] <soren> sistpoty|work: (the vmware X driver, that is)
[16:21] <sistpoty|work> soren: heh, that would make sense (can you have a PCI id for a virtual device *g*)
[16:22] <soren> Oh, yes, indeed.
[16:22] <soren> Qumranet has bought a stack of them.
[16:22] <sistpoty|work> heh
[16:22] <soren> The virtio nic and block device have officially registered pci vendor/device ID's, for instance.
[16:23] <sistpoty|work> cool
[16:23] <soren> I would imagine VMWare has done the same for their graphics adapter.
[16:23] <soren> At least it's uniquely identifiable by its pci id's.
[16:24] <soren> I'm guessing we'd have heard about it, if the just squatted on those id's and didn't properly register them :)
[16:25] <sistpoty|work> heh
[16:26]  * Mithrandir steals soren's '
[16:27]  * Hobbsee steals Mithrandir
[16:28]  * ion_ substitutes ' with ’
[16:28] <soren> ion_: Aw. I *hate* that.
[16:32] <cgregan> Does anyone know if there is a way to extract the symbol list from a library to a text file?
[16:33] <pitti> cgregan: something like nm -D /lib/libm.so.6 ?
[16:34] <pitti> cgregan: alternatively objdump -T /lib/libm.so.6
[16:34] <cgregan> pitti: I can give that one a try....would then: nm -D /lib/libm.so.6 > symbols.txt?
[16:34] <pitti> cgregan: yes
[16:34] <pitti> objdump is slightly more verbose, but by and large they output the same info
[16:34] <cgregan> pitti: Thanks! I'll give it a shot
[17:15] <Mithrandir> pitti: the fix for 230716 can cause data loss, which is probably not what we want.
[17:18] <slangasek> Mithrandir: can you elaborate? (and perhaps tag the bug as 'verification-failed'?)
[17:22] <Mithrandir> slangasek: mounting file systems will always cause the journal to be replayed, something which can cause data loss if the file system is in use by a hibernated system.
[17:23] <Mithrandir> so, hibernate, boot live cd, boom, instant file system corruption.
[17:24] <Mithrandir> luckily only if you try to use it with persistence enabled, it seems.
[17:30] <slangasek> Mithrandir: I guess I'm not seeing how this relates to the change in question; the only new reference to 'mount' there is a 'mount -o bind', which doesn't mount any filesystems that weren't already mounted?
[17:31] <Mithrandir> slangasek: from the changelog it looks like the list of file systems has been extended.
[17:31] <Mithrandir> https://bugs.edge.launchpad.net/ubuntu/+source/casper/+bug/230703 is the one I meant, sorry
[17:31] <Mithrandir> there was a reason for it originally only being vfat. :-)
[17:31] <Mithrandir> hm, and ext2 too, since that doesn't have a journal
[17:32] <slangasek> ah, I see, so the "try_mount" is now run in more cases, gotcha
[17:32] <slangasek> vfat|iso9660|udf|ext2|ext3|ntfs)
[17:35] <sebner> pitti: hi, you may remember my boson sync where dpkg-source -x wasn't working. any news/updates/progress?
[17:45] <pitti> Mithrandir: thanks for pointing out; I reopened the bug in intrepid, too, slangasek already added a comment
[17:46] <pitti> sebner: not yet; if the package itself is fine, we can work around it with a manual upload
[17:47] <sebner> pitti: should be fine, yes
[17:48] <Keybuk> ==31654== Conditional jump or move depends on uninitialised value(s)
[17:48] <Keybuk> ==31654==    at 0x400A62B: (within /lib/ld-2.8.90.so)
[17:48] <Keybuk> ==31654==    by 0x400329C: (within /lib/ld-2.8.90.so)
[17:48] <Keybuk> ==31654==    by 0x4013E60: (within /lib/ld-2.8.90.so)
[17:48] <Keybuk> ==31654==    by 0x4000BFC: (within /lib/ld-2.8.90.so)
[17:48] <Keybuk> ==31654==    by 0x40007F6: (within /lib/ld-2.8.90.so)
[17:48] <Keybuk> *sigh*
[18:10]  * ion_ notices libc6 is still upgraded before findutils when upgrading to intrepid, triggering the xargs problem.
[18:37] <MacSlow> mvo_, ehm... got my reply via priv.-msg. ?
[18:38] <MacSlow> njpatel, although I got these going http://people.ubuntu.com/~mmueller/authenticate-rgba.png http://people.ubuntu.com/~mmueller/logout-rgba.png I've not been able to fix the issues with GtkSpinButton and GtkComboBoxEntry.
[18:39] <MacSlow> njpatel, they seem to draw their frames differently compared to GtkEntry
[18:41] <MacSlow> njpatel, btw... take the "brushed metal"-look only as an example of a non-uniform parent-widget background... I don't intend to push that upstream :)
[18:43] <ion_> macslow: Nice
[18:43] <MacSlow> ion_, thanks
[18:46] <njpatel> MacSlow: (sorry for late reply) have you seen what happens with different themes?
[18:47] <njpatel> MacSlow: oh, and its looking very nice :-)
[18:49] <MacSlow> njpatel, only the GtkEntry gets ugly... I'm using a slightly patched murrine... because Cimi does clear the background to the themes bg-color, which would be ok if GtkEntry would not be so "oddly" implemented
[18:50] <njpatel> MacSlow: I see, that sucks
[18:51] <MacSlow> njpatel, in order to get the background of GtkEntry cleared to full transparency, thus avoiding those nasty gliches with rectangles larger than the decorating frame, I've to redirect it offscreen, clear to transparency in the expose-handler of my GtkEntry and finally composite it onto to parent widget in the parents expose-handler
[18:51] <MacSlow> njpatel, that currently the only approach that works to get the rendering clean
[18:51] <njpatel> MacSlow: woah, that's not good at all
[18:51] <MacSlow> njpatel, yeah that sucks
[18:52] <njpatel> MacSlow: can we fix it by patching Gtk before the next release?
[18:52] <MacSlow> njpatel, I've not very high hopes for the "spit-and-polish" spec... but I need to collect all that info myself in order to write proper documentation for the spec
[18:53] <MacSlow> njpatel, I don't think gtk+-upstream would accept a patch where GtkEntry is implicitly redirected offscreen
[18:53] <njpatel> MacSlow: no, I mean that there must be a correct fix for entry, so it works better in this situation
[18:54] <MacSlow> njpatel, I've talked to people like Owen Tayler and they also suggested the "redirect to offscreen..."-approach
[18:54] <njpatel> MacSlow: okay, thats that then :-)
[18:55] <MacSlow> njpatel, I'm already loosing too much time on figuring out all the issues for something that does not have a high priority
[18:55] <MacSlow> I honestly have not expected it to be so nasty
[18:56] <njpatel> MacSlow: dude, as long as you can get it to work for your use-case, move on to the next problem :-)
[18:56] <amikrop> How can I declare wxPython as a dependency (python-wxgtk does not have an installation candidate, so I am not sure how to handle this)?
[19:00] <amikrop> So, any help, please?
[19:01] <jpds> amikrop: you needn't ask two channels
[19:01] <amikrop> jpds: Oh, OK.
[19:22] <tkamppeter> Domeone knows a command line tool to check the integrity of HTML files? I need this two check a server-side cache for corrupted entries.
[19:23] <mterry> tkamppeter: HTML Tidy should be able to validate (http://tidy.sourceforge.net/)
[19:25] <tkamppeter> mterry, thanks. Is it already packaged for Ubuntu (the server runs Dapper AFAIR).
[19:27] <geser> !info wdg-html-validator dapper
[19:27] <geser> mterry: ^^
[19:28] <geser> it's also in dapper
[19:28] <mterry> neat
[19:44] <tkamppeter> Thank you very much. I am installing the package on the server now.
[20:25] <tkamppeter> !info tidy
[20:39] <jcastro> evand: Is there a plan for a slideshow during the installer for intrepid ala: https://blueprints.edge.launchpad.net/ubuntu/+spec/ubiquity-slideshow
[20:40] <evand> jcastro: Yes.  The Art Team will be making a MNG that will play during the file copy process.
[20:41] <jcastro> evand: is there a spec someplace or should I just bug kwwii?
[20:41] <evand> jcastro: Drafting the specification falls on me, so bug me :)
[20:41] <jcastro> evand: k, I was just cleaning up installer stuff on brainstorm
[20:42] <evand> link?
[20:43] <jcastro> http://brainstorm.ubuntu.com/idea/136/
[20:44] <Amaranth> evand: What supports MNG?
[20:45] <Lightkey> Mozilla M17-1.4 :->
[20:47] <evand> Amaranth: argh, point taken.
[20:48] <Amaranth> xulrunner 1.9 does support APNG
[20:49] <jcastro> evand: ok, I'll just mark it as in development for 8.10 and then link the spec later
[20:49] <evand> thanks
[20:50] <Lightkey> or you could alternatively include the still maintained MNG patch into your gecko browsers builds ;-)
[20:53] <mario_limonciell> why not just have a normal video that plays instead?
[20:55] <evand> That would work.  I'm not particularly tied to a format.
[20:56] <mario_limonciell> you figure if space ends up being a limitation, you pull out some of the example-content, and put this video in it's place
[20:57] <mario_limonciell> hum.  since when do the buildd's not have lsb_release by default?  i  thought it was a dependency of ubuntu-minimal. take a look at http://launchpadlibrarian.net/14897107/buildlog_ubuntu-intrepid-i386.mythplugins_0.21.0%2Bfixes17416-0ubuntu1_FAILEDTOBUILD.txt.gz;  search the log for "lsb_release:"
[20:57] <mario_limonciell> it built fine in an intrepid sbuild
[20:59] <norsetto> mario_limonciell: are minimal packages in buildd? I thought just essential were.
[20:59] <mario_limonciell> norsetto, well at least used to be for gutsy and hardy..
[20:59] <mario_limonciell> norsetto, and still in my intrepid sbuild, so  i assumed so?
[21:00] <norsetto> mario_limonciell: well, I always assumed only essential, I guess I erred on the safe side
[21:01] <mario_limonciell> norsetto, i suppose i could just fix the failure by adding lsb-release to build-depends, but if something suddenly changed on the buildds that archive admins dont know about, it would be better to make sure they saw it and got it fixed
[21:18] <Mirv> is there already something that prevents moving stable-proposed packages into stable-updates if the to-be-moved packages break main dependencies / packages?
[21:22] <ScottK> Mirv: Hopefully they get tested and this is found out.
[21:22] <ScottK> Nothing gets moved automatically.  It's only after testing.
[21:31] <jfcgauss_> hi. i could not locate the page (and the changelog) of linux-image-2.6.24-17-generic from http://packages.ubuntu.com. i see that package installed on my machine and it is from hardy-updates. thx..
[21:37] <shiyee> jfcgauss_: see /usr/share/doc/linux-image-2.6.24-17-generic/changeog.Debian.gz
[21:41] <jfcgauss_> :D thx
[22:10] <emgent> heya