[00:34] <xaver> slangasek: hello
[00:35] <xaver> somebody told me you work on mountall too. i have some trouble since 2.13
[02:04] <weedar> could lots of "Ubuntu Archive Auto-Sync" changelog-entries in Launchpad mean that the package was without a maintainer?
[02:36] <nhandler> weedar: Do you mean without a Debian maintainer?
[02:40] <weedar> nhandler: Well, no, the package I'm thinking of is openbios-sparc and I noticed only auto-sync entries in the changelog - The maintainer according to launchpad is the same as the maintainer in Debian
[02:40] <nhandler> weedar: Yeah, most packages in Ubuntu don't have their own maintainer (like in Debian).
[02:43] <weedar> nhandler: I initally thought it meant that the package just came straight from Debian, without anyone checking to see if it worked. I also wondered about the link under "Uploaded by", here: https://launchpad.net/ubuntu/+source/openbios-sparc/1.0-1
[02:44] <weedar> It is a link to https://launchpad.net/~katie which doesn't exist. That is why I thought katie was the old maintainer for Ubuntu and that after she deleted her account all the links turned into "auto-sync"
[02:44] <nhandler> weedar: Yeah, that is what the Auto-Sync means. The Debian version was automatically uploaded to Ubuntu without any changes.
[02:44] <nhandler> That is how most packages wind up in Ubuntu
[02:48] <ari-tczew> slangasek: I sent an e-mail to you for sponsoring request 2 merges - bug 609634 and bug 609620
[02:50] <weedar> nhandler: In this case the package (openbios-sparc) provides bios rom blobs for sparc32 and sparc64, could I change it so the Ubuntu package only provided the sparc32 rom (since compiling for sparc64 seems impossible right now) or would I have to ask the Debian maintainer to change it in Debian?
[02:51] <weedar> Or is there yet an alternative; That I could provide a openbios-sparc32 package and propose it replace openbios-sparc in universe, since the existing openbios-sparc source package fails to build and there is no install candidate for openbios-sparc?
[02:55] <weedar> I'm sorry if my question(s) was/were poorly worded - I'm just trying to understand the "politics" behind Ubuntu packaging :-)
[07:03] <robertzaccour> hey yall i got a question
[07:03] <robertzaccour> will the libtheora bug be fixed in time for maverick?
[08:41] <bilalakhtar> Someone, please sponsor fix for bug #155930
[08:45] <bilalakhtar> BlackZ: please sponsor bug #604910
[08:45] <bilalakhtar> lifeless: are you a core-dev ?
[08:47] <lifeless> bilalakhtar: please let the queuing process do its job; I know its higher latency than we'd all like, but it does let people get in the flow of what they are doing.
[08:49] <bilalakhtar> lifeless: I have been waiting for weeks
[08:50] <bilalakhtar> lifeless: I completely understand you people are busy and there is a lack of sponsors
[08:50] <BlackZ> bilalakhtar: is it urgent?
[08:50] <bilalakhtar> BlackZ: not very much, but
[08:51] <bilalakhtar> During the wait, a developer will push a new version of a package, thus forcing me to update my patches
[08:52] <micahg> bilalakhtar: what's wrong with that?
[08:52] <bilalakhtar> micahg: nothing, just mentioning
[08:53] <bilalakhtar> sorry micahg
[08:53] <micahg> bilalakhtar: well, you would then propose another merge anyway, right?
[08:53] <bilalakhtar> micahg: yup
[08:54] <micahg> bilalakhtar: so, since the queue is long, you're saving sponsorship time by keeping the merge up to date :)
[08:54]  * bilalakhtar is doing exactly what he and micahg are discussing
[08:57] <BlackZ> bilalakhtar: be patient, I think somebody will sponsor your upload but it can take weeks too. I can't look at it right now, sorry
[08:59] <bilalakhtar> BlackZ: ok, I came here as FF is approaching. Won't trouble you devs anymore
[08:59] <BlackZ> bilalakhtar: if the merge is requested before the FF it will not need an FFe
[09:00] <BlackZ> s/an/a
[09:00] <bilalakhtar> BlackZ: really? O_o Thanks for the info. I will be more patient from now onwards
[11:11] <iceroot> hi
[11:12] <iceroot> maybe you can help me with this. what is supported 5 years in the lts server-edition? the default installed packages? everything? everything expect ubuntu-desktop? everything expect using a gui? so what about the package vim? is it supported 3 or 5 years for example
[11:17] <nigelb> doko_: whats your take on bug 13371?  Is the patch worth it?
[12:43] <directhex> iceroot, for any package, try "apt-cache show packagename | grep ^Supported"
[12:43] <directhex> someone made a list of everything via grep-dctrl. was it Laney?
[12:43] <Laney> yeah
[12:43] <Laney> http://orangesquash.org.uk/~laney/supported-5y
[12:44] <Laney> guess the rest of the urls
[13:17] <micahg> doko_: I think the recent gcc change might be preventing xulrunner from building on armel, I haven't set up a local environment yet to test with, but there was almost no difference between 1.9.2.7 which built and 1.9.2.8 which didn't
[13:50] <directhex> micahg, so test-build 1.9.2.7 on a recent environment?
[13:51] <micahg> directhex: good idea :)
[13:52] <directhex> that's why i get paid the big bucks
[17:31] <un214> what can be done about absolutely bogus dependencies?
[21:46] <kees> apachelogger: hi! you around? your rekonq crash bug -- what kernel version were you running?
[21:46] <kees> apachelogger: (in theory, it should be fixed already...)
[22:11] <ari-tczew> does anybody works on merge cdbs and debhelper?
[22:11] <ari-tczew> devscripts
[22:23] <ari-tczew> thanks for respons
[22:33] <MattJ> $ file /usr/share/backgrounds/warty-final-ubuntu.png
[22:33] <MattJ> /usr/share/backgrounds/warty-final-ubuntu.png: JPEG image data, JFIF standard 1.02
[22:33] <MattJ> Does that not strike anyone else as wrong? :)
[22:39] <ion> mattj: The only wrong thing is the original decision on a filename like that that can’t be changed later. :-P But filenames are just for humans. As far as computers are concerned, everything could be just an anonymous inode.
[22:40] <MattJ> Yes, maybe... though eog refuses to open it
[22:41] <MattJ> otherwise I wouldn't have noticed
[22:41] <ion> Then there is a bug in eog. No software should base its decision of file type solely on the filename.
[22:48] <crimsun_> MattJ: that's bug 172416
[22:48] <MattJ> crimsun_: Ah ok, thanks :)