[00:00] <RAOF> Whether the BIOS can actually set that mode for us.
[00:00] <RAOF> We don't have a graphics driver at that point; we're relying on VESA.
[00:00] <persia> The BIOS sets it, even when it's on kernel command line?
[00:00] <RAOF> Well, VESA calls into the graphics BIOS.
[00:00] <persia> Oh.  I see.  Ugly that.
[00:01] <RAOF> So, if you're lucky, the graphics BIOS will actually contain a mode that your attached display can use.  And if you're even luckier, we can pick that :)
[00:02] <RAOF> If you're unlucky, the graphics BIOS doesn't contain a mode your panel will display *at all*, and we pick something that results in the screen turning off until X starts.
[00:02] <persia> Which is why we tend to display the text interface when we don't have the necessary kernel bits?
[00:03] <RAOF> Well, for Lucid we used vga16fb, which was ugly but worked.
[00:04] <RAOF> *For values of “worked” which included “broke people's graphics in certain, not too uncommon, cases”
[00:04]  * RAOF is not sad to see the back of vga16fb.
[00:04] <persia> That's suspiciously similar to "didn't work" for values of "didn't work" that included "accidental success in certain, not too uncommon, cases"
[00:05] <RAOF> We *were* going to use the EFI fb driver in Maverick, I think, but that got shelved.
[00:06] <persia> Do we have meaningful EFI information for many cases?
[00:06] <persia> I have *one* EFI device of the 11 Ubuntu installations on my desk.
[00:06] <persia> (and it's special EFI that doesn't work with the standard EFI stuff)
[00:07] <RAOF> My memory of the conversations I had about it is that the EFI framebuffer driver was magic, and worked everywhere.
[00:07] <persia> Well, either you go to really good parties, or we should be using this.
[00:08] <RAOF> The kernel guys & keybuk & Colin were working on it in Prague, but it slipped.
[00:08] <persia> Do you know if it happens to also magically work for armel/ppc?
[00:09] <RAOF> Heh.  Sure!  It's magic! :)
[00:09] <persia> Excellent.
[00:09] <RAOF> (Statements may not actually correspond to reality)
[00:10] <persia> But they might.  With lucid, nouveau+KMS changed my powerpc/nvidia install from text to graphical for plymouth.
[00:10] <persia> I somehow doubt that was by the intent of anyone concerned with nouveau or plymouth directly.
[00:11] <gilir> n
[00:11] <ari-tczew> hey gilir
[00:12] <gilir> hi ari-tczew
[03:52] <micahg> superm1: sorry, I just duped your dupe for that $TERM bug
[03:52] <superm1> no problems, i wasn't aware of the original until i did a quick google, which i should have done before adding a task :)
[03:55] <persia> Which bug?  My $TERM issue mysteriously disappeared about 3 weeks ago, and I thought it was sorted.
[03:56] <micahg> persia: bug 621927
[03:56] <ubottu> Launchpad bug 621927 in Ubuntu release notes "Embedded Terminal Emulator isn't giving a TERM variable" [Undecided,New] https://launchpad.net/bugs/621927
[03:56] <persia> Oh, yeah, I'd believe that.  Changes in VTE that didn't get where they needed.
[05:45] <iefremov> Hi All! Can anybody say what means "format '3.0 (quilt)' is not permitted in natty" notification after dputting a new package? Should I change the source format or just wait until upload to natty will be opened?
[05:45] <Hobbsee> the latter
[05:46] <Hobbsee> at elsat
[05:46] <Hobbsee> *least
[05:46] <iefremov> ok, I see
[05:46] <iefremov> and what's wrong with quilt?
[05:47] <Hobbsee> i've no idea, but the natty toolchain hasn't been built yet, so i don't think anything's being allowed in
[05:47] <iefremov> ok, thanks for the help
[05:49] <persia> For the avoidance of doubt, it's quite likely that every other format is also not permitted in natty
[05:51] <iefremov> :) looks reasonable
[05:53] <wgrant> Ah, heh, I guess that has replaced the obscure "could not build architecture 'any'" error.
[06:53] <dholbach> good morning
[07:05] <\sh> moins
[08:26] <Rhonda> There is no natty dists in the archives, I would consider that being a very good indicator that uploads shouldn't be done yet. :)
=== yofel_ is now known as yofel
[10:11] <AnAnt> ScottK: ping
=== ivoks-afk is now known as ivoks
[14:47] <dholbach> https://wiki.ubuntu.com/UbuntuOpenWeek starting in 13 minutes in #ubuntu-classroom
=== ScottK changed the topic of #ubuntu-motu to: Maverick is released.  Lots of SRUs to be done. | Natty exists, but is only open for toolchain uploads.  | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://is.gd/2y76G | http://qa.ubuntuwire.com/ftbfs | http://people.canonical.com/~ubuntu-archive/NBS | http://qa.ubuntuwire.com/bugs/rcbugs/ | latest rebuild failures: http://udd.debian.o
[15:35] <josephnexus> hello everyone
[15:35] <ari-tczew> hello josephnexus
[15:35] <josephnexus> i see that the ogre packages and nvidia-cg packages have been fixed in this release, but those funny funguloids is still broken (due to simply using outdated data)
[15:36] <josephnexus> i've filed a bug about it, because this causes a segfault whenever you try to start playing, would it be possible for the motu team, being the masters of the universe, to gett he new data and whip up a fixed package?
[15:36] <dyfet> I have an interesting (from a policy perspective) package bug, which is a remote exploit, that is only fixed in a rather new upstream release (https://bugs.launchpad.net/ubuntu/+source/ziproxy/+bug/657024), I want to understand the best way of addressing this kind of issue, whether as a sync as proposed, or something different.
[15:36] <ubottu> Launchpad bug 657024 in ziproxy (Ubuntu) "please sync 3.1.3-1 from debian (unstable) to replace 2.7.2-1ubuntu2 in Maverick (universe) - security vulnerability" [Undecided,New]
[15:36] <ari-tczew> josephnexus: if you will prepare a patch, motu can sponsor it as SRU.
[15:37] <josephnexus> i have no clue how to prepare a patch :-(
[15:37] <ari-tczew> josephnexus: https://wiki.ubuntu.com/PackagingGuide/Howtos/Debdiff and https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[15:38] <ari-tczew> dyfet: I can't believe that security patch is not exist and is available only through full upstream release.
[15:38] <josephnexus> ok, I don't think that I need the diff, since this is only resolving the data package, not the binary
[15:38] <dyfet> ari-tczew: I was going by what debian did to resolve this
[15:39] <josephnexus> http://funguloids.sourceforge.net/files/funguloids-patches.tar.bz2 <--- contains everything needed
[15:40] <ari-tczew> dyfet: I understand, but security fixes are not welcome through syncs. Please investigate in upstream for stricte patch.
[15:41] <josephnexus> looks like there are patches to the binary :-(
[15:41] <josephnexus> i'm only a php dev, never done any python or ogre stuff.... so this is all above me :-(
[15:42] <dyfet> ari_tczew: I have also been looking through the changelog to see if I can identify when/which version this actually got fixed to see if it may be possible to create a diff from/patch from a specific change upstream.  If that is preferred I would be happy to see if this can be done.
[15:42] <dyfet> (the upstream source's changes...)
[15:43] <ari-tczew> dyfet: please use [TAB] for complete nicknames on IRC. for example, please write 'ari' and click [TAB]
[15:50] <ari-tczew> lfaraone: ping
[15:52] <ari-tczew> dyfet: I think that if you will create a debdiff between upstream 3.0.0 and 3.0.1 you will gain security patch.
[15:56] <dyfet> ari-tczew, that I can try and see it it can be back patched to our 2.7.2.  I thought there might be other changes also related to this bug from reading the upstream changelog.  But I will see what this approach yields first.
[15:56] <ari-tczew> dyfet: great
[15:59] <dyfet> ari-tczew, I guess I will assign it to me for now :)
[15:59] <ari-tczew> dyfet: are you available to test patched package?
[16:00] <dyfet> ari-tczew, yes.  Originally I did an arm patch for this package.
=== shriekout is now known as shriek
[16:01] <ari-tczew> dyfet: great. if you will create a debdiff, please subscribe ubuntu-security-sponsors. maybe I'll review/ACK your patch.
=== shriek is now known as Guest36033
=== Guest36033 is now known as shriekout
[16:21] <ari-tczew> is it candidate to papercuts? bug 653274
[16:21] <ubottu> Launchpad bug 653274 in linux (Ubuntu) "Plymouth doesn't show Kubuntu or Ubuntu logo with Nvidia proprietary driver" [Undecided,Confirmed] https://launchpad.net/bugs/653274
[16:27] <ari-tczew> lucas: ping
[16:42] <kklimonda> ari-tczew: did the logo show in lucid? I don't remember
[16:42] <ari-tczew> kklimonda: yes, for me yes
[16:43] <ari-tczew> IIRC this bug has been introduced at the end of August, maybe in half of September
[16:45] <ScottK> It shows fine with Intel/other free drivers.
[16:47] <kklimonda> ScottK: sure, but if the logo did show in lucid and it doesn't in maverick then it's weird.
[16:47] <ScottK> Agreed.
[16:47] <ari-tczew> a lot of ubuntu users have got nvidia cards. it's not good ad for ubuntu with that ugly plymouth.
[16:47] <kklimonda> ari-tczew: it's not our call, really
[16:48] <ari-tczew> kklimonda: who is?
[16:48] <kklimonda> ari-tczew: the workaround from the linked script doesn't work for everyone so the only way to really fix is for nvidia to support kms
[16:49] <ari-tczew> I hope that core developers will fix this bug ASAP.
[16:49] <kklimonda> ari-tczew: but they can't really do much
[16:50] <ari-tczew> kklimonda: unless I'm dreaming
[16:51]  * kklimonda suggests using open drivers - the do work like a charm here
[16:51] <josephnexus> i just fixed the issue in plymouth by following a forum tutorial, i'm going to see if it works
=== sebner_ is now known as sebner
[17:58] <lfaraone> ari-tczew: yep?
[17:58] <ari-tczew> lfaraone: could you sponsor new package in Debian?
[17:58] <lfaraone> ari-tczew: «it depends». What package?
[17:58] <ari-tczew> lfaraone: clementine. ACKed on revu.
=== xfaf is now known as zul
[18:02] <ari-tczew> lfaraone: would be nice if you give me tips to improve package for Debian.
[18:03] <lfaraone> ari-tczew: are you the maintainer? David Sansome is listed as the OM on REVU, but you're the one who uploaded it.
[18:04] <ari-tczew> lfaraone: I want to be a maintainer for clementine.
[18:04] <ari-tczew> and I prepared a ready source.
[18:05] <ari-tczew> lfaraone: I marked davidsansome as maintainer, because he wanted to be, but I would to own clementine. I have knowledge in ubuntu packaging.
[18:42] <lucas> ari-tczew: pong
[18:43] <ari-tczew> lucas: is it possible to use your UDD merges script with filter where maintainer is: Debian QA Group ?
[18:44] <lucas> ari-tczew: yes, just look at the source, find the appropriate query, and modify it
[18:44] <lucas> ari-tczew: it's quite easy
[18:45] <ari-tczew> lucas: merges.py file?
[18:46] <lucas> ari-tczew: http://svn.debian.org/viewsvn/collab-qa/udd/web/cgi-bin/merges.json.cgi?revision=1764&view=markup
[18:51] <ari-tczew> lucas: I'm thinking that appropriate query is 'sth'
=== ivoks is now known as ivoks-afk
[19:10] <ari-tczew> lucas: btw. it's time to change ubu release to natty.
=== ivoks-afk is now known as ivoks
[21:07] <ScottK> debfx: Congratulations.
=== ScottK changed the topic of #ubuntu-motu to: Maverick is released.  Lots of SRUs to be done. | Natty exists, but is only open for toolchain uploads.  | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://is.gd/2y76G | http://qa.ubuntuwire.com/ftbfs | http://people.canonical.com/~ubuntu-archive/NBS | http://qa.ubuntuwire.com/bugs/rcbugs/ | Congratulations to new MOTU: debfx.
=== ivoks is now known as ivoks-afk
[21:32] <micahg> debfx: congrats
[21:33] <debfx> micahg: thanks :)
=== JPM is now known as CapeTownParty
=== zooko` is now known as zooko