=== asac_ is now known as asac [00:18] jmarsden|work: ping [00:18] jmarsden: ping again :) [00:43] emgent: I'm here... [00:44] jmarsden: query ? [00:45] You pinged at 16:18 ? [00:45] 1.18 am here.. [00:51] !packaging [00:51] The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports [00:52] if i make a package, how long until i can get a ppa, and have it uploaded and compiled there? [00:52] after i got a package upon the ppa, how long until i can have it in official repo? [00:54] miik: the ppa is no requirement for getting a package into the ubuntu repositories [00:54] miik: I am not remotely an expert, but I think you can do the PPA yourself [00:54] !ppa | miik [00:54] miik: With Launchpad's Personal Package Archives (PPA), you can build and publish binary Ubuntu packages for multiple architectures simply by uploading an Ubuntu source package to Launchpad. See https://help.launchpad.net/PPAQuickStart. [00:58] qq about get-orig-source: does it have to be version independent? [00:59] !lpia [00:59] Sorry, I don't know anything about lpia [00:59] well obivously is has to, but howto get the latest version [00:59] lpia? [01:00] miik: i think its intels atom platform [01:00] oh [01:00] thought atom was x86 [01:00] It is [01:01] lpia stands for Low Power Intel Architecture [01:01] StevenK: so ... its atom? [01:02] handschuh: Yeah [01:02] StevenK: ok, thx [01:06] someone feed thato the bot [01:07] !botsnack [01:07] Yum! Err, I mean, APT! [01:13] miik: See https://help.launchpad.net/Packaging/PPA for how to get a PPA [01:14] ok [01:14] yeah, i read that [01:14] how long before i make a package, until it can get included in official repo? [01:15] miik: Read https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages. You need to upload it to REVU and get 2 MOTUs to advocate it. [01:16] anyone can upload to REVU? [01:16] Package of a new piece of software ... takes a while unless you know MOTUs to persuade... ; package an existing piece of software, fixing a bug... not much time at all, usually, you put the debdiff into the LP bug and persuade a MOTU to look at it :-) [01:16] Yes miik [01:16] how long it take before 2 MOTU advocate it? after that, how long it take before it in repo? [01:16] !revu | miik [01:16] miik: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU [01:17] well, packaging is a pain in the ass, its so difficult, but im considering learning it, but dont want todo it, if its gonna be in vain, and im not gonna be able to get stuff into the repo anyways [01:17] miik: How long... seconds, if they are both in IRC and you persuade them to do it right away :-) Or years, if noone cares about your software package :-| [01:17] oh [01:18] miik: You might want to start by fixing bugs in existing packages rather than packaging new stuff. [01:18] so if packaging isnt difficult enough, there is beaurocracy and stuff too [01:18] miik: Packaging new programs is not necessarily the best way to start packaging. [01:18] jmarsden_, fixing bugs is difficult, then you need to know programming. packing new package, i just download source, and package it [01:18] miik: Not so much bureaucracy, just too few MOTUs and a lot of stuff already in REVU [01:18] could anyone review my package at: http://revu.ubuntuwire.com/details.py?package=libballoontip-java ? [01:19] miik: Fixing bugs can mean adding a desktop icon, or a translation to a .desktop file... not all bugs require code changes. [01:20] oh okie [01:20] can i just upload the .deskop file, or i need download package, add desktop file, package it, upload it? [01:21] miik: You will submit your changes in the form of a debdiff. To generate the debdiff [01:21] Well, the first is a start, the second is better. [01:21] https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff [01:22] miik: https://launchpad.net/bugs/236140 is a bug where someone else uploaded a .desktop file, I did the packaging/debdiff, and the _RainCT checked it and got it uploaded to an offical repository. [01:22] Launchpad bug 236140 in koverartist "New .desktop file for KoverArtist" [Wishlist,Fix released] [01:24] oh [01:24] i need gpg and stuff to make a debdiff? [01:25] miik: TO sign it so we know it is really from you, yes. You can make them without signing them, but that's not useful for official repo use. [01:25] oh, ok [01:25] miik: man debdiff [01:26] what point of sign them, if anyone can come with a nickname like "asd78asd8f7g" and come only once, then submit, then leave never to been again? [01:29] Erm. GPG is *not* a requirement for creating debdiffs. [01:29] jmarsden|work: Um. We don't require signed debdiffs [01:29] In fact, we don't _accept_ signed debdiffs. Or don't have the infrastructure for it, and I've never seen one. [01:29] miik, When building a package for a debdiff, just use `debuild -S -us -uc` to avoid the GPG step. [01:30] RAOF, Well, we can accept signed debdiffs. It's just a text file. Most of us will grumble about stripping the signature though. [01:30] Really? Ah, right, my bad. [01:31] * jmarsden|work should be working, not talking in here and trying to work at the same time... :-) [01:42] under which circumstances is a get-orig-source rule needed? [01:43] handschuh, When `uscan --force-download` doesn't automatically get the upstream source. [01:44] persia: so what if uscan gets the upstream source but this file contains additional data (like binaries) [01:45] handschuh, If there's source available for those binaries, you can just delete them in debian/rules clean. [01:45] If there's no source available for those binaries, you need a get-orig-source to delete them when constructing the orig.tar.gz [01:46] persia: ok the package contains also the source so I just modify the clean task [01:46] persian: thanks [01:47] sry, "perisa" [01:47] handschuh, No problem. Thanks for helping build the Ubuntu Java library set. Someday we'll actually be able to use most Java apps cleanly :) [01:48] persia: there is still a lot to do, but I will try to add as many packages as possible like jaxws [01:49] persia: i am also working on cleaning up of old packages that have strange dependencies [01:49] but first I have to learn how to make acceptable packages ;-) [01:52] handschuh, If you're looking for Java stuff, one of the targets for Jaunty is to get maven working, and there's a list of packages that need packaging, for which there's a few people who'd be happy to help review. [01:54] persia: i will try to help as much as possible [01:54] * persia hunts down the spec [01:55] persia: the problem is that java is to easy to bundle. so erverybody just adds the needed libraries to their package [01:57] handschuh, Which is a security nightmare, as you might imagine. [01:58] hence the number of +dfsg packages some of us need to maintain [01:58] handschuh, https://wiki.ubuntu.com/JavaTeam/Specs/MavenSupportSpec , under bootstrapping. [01:59] Hey, would documentation that is under this license be considered debian-free: "Permission is granted to reproduction and modification, as long as proper attribution is given. Changes made in derivatives need not be under the same license. By use of the work or a derivitive, you agree to indemnify its author from any liability connected to said use. Finally, if any of the term(s) of this license is deemed invalid by a court, or if it is vio [01:59] *bookmark* [01:59] lfaraone, pastebin [01:59] persia: that's it, actually. [02:00] persia: but here you go: http://pastebin.ca/1255778 [02:00] lfaraone, sounds pretty free to me [02:00] lfaraone, expat license, give or take [02:00] lfaraone, It got cut off :) [02:01] well then .. i have to take my 4 hours of sleep ... [02:01] persia: awww... [02:01] lfaraone, Hrm. Looks mostly ok, but I'm not sure about the bit that if the license isn't valid, it can't be distributed. That makes me wonder if it is valid. [02:02] I'd much prefer to see a clause saying that if any provision is invalid, the rest remain, rather than that if any provision is invalid, it cannot be distributed. [02:02] persia, that's called "copyright" [02:02] Anyway, sleep well. Maybe someone else disagrees with me. [02:02] directhex, Right, which doesn't allow redistribution by default. [02:02] persia: The GPL has the same policy: [02:03] * persia reads the GPL again, sure that it's not the same [02:03] most licenses don't bother stating the obvious [02:03] the obvious being "in the absence of this license, you don't have this license" [02:03] Um, that's not what this says. [02:03] i.e. copyright applies, i.e. no rights matey [02:03] persia: http://pastebin.ca/1255783 [02:04] anyway, bedtime [02:04] lfaraone, That says I have to follow the license even if the court says I can't, and that if I can't deal with that, I can't distribute it. [02:05] That's different from saying if a court has a problem with the license, even if they say I can distribute it, I can't. [02:05] persia: ah, OK. [02:06] persia: (I'm the "author" of the above, CC_BY is too tl;dr for my tastes in some cases) [02:07] lfaraone, You wrote that license? [02:07] lfaraone, Have you considered using the ISC license? Similar intent, but common, and without the snag. [02:08] persia: Yeah, I did. (Yes, I know it's bad to write your own, and that -motu INAL) [02:08] WTFPL! [02:08] it's dfsg-free! [02:08] Yeah, the WTFPL is certainly dfsg-free, but it's a little in-your-face. [02:09] persia, if you don't like it, then clause 0 of the license permits relicensing :) [02:09] Plus it doesn't have the attribution restriction. ISC has the attribution restriction, which seems to be a better fit for what lfarone seeks. [02:10] persia: I'm seriously thinking of legally changing my name. _Every_ person on this earth seems to forget the second "a". :P [02:10] I haven't forgotten the second a lfaraone ! [02:10] * lfaraone gives NCommander a cookie. [02:10] yay! [02:11] how about "raven darktalon blood" as a new name? [02:11] persia: ISC looks cool. I'm wondering if I can condense all of the "SHOUTING FOR LEGAL AUTHORITY" to a "You disclaim the author from all liability related to use of this document/program" [02:11] directhex: Sure.... [02:11] lfaraaone: Sorry about that. I'll try to make up for it in the future. [02:12] directhex: considereing prior to now I went as "firefoxman" :P [02:12] lfaraone, Well, the SHOUTING FOR LEGAL AUTHORITY is about as brief as you can get without going for something like WTFPL. I don't know of any widely supported licenses that are shorter and still provide the desired protection. [02:13] if you replace the SHOUTING part with LOOK AT MY LOVELY HAT, how many people do you think would notice? [02:13] anyway, bedtime [02:14] persia: http://en.wikipedia.org/wiki/Poetic_License just looks nice. (and rhymes!) [02:16] lfaraone, I don't see any issues with that one, although I've not seen other software under it. It's probably good, but I'd want a second opinion before pushing it. [02:17] persia: Ironically, the spesific use case I wrote this license for was for the reuse of another legal document I wrote (and _that_ was actually checked by a lawyer) for which I didn't want to be sued if the reuser was. But I'd also apply it to more relevent-to-ubuntu things. [02:17] *(the document being licensed was a legal document itself) [02:17] Oh, and for new packages, is debian or ubuntu prefered? [02:18] (should I go through the NPP process on Ubuntu or on Debian?) [02:18] debian! [02:18] Debian is preferred. [02:18] don't enhance ubuntu, enhance free software. ubuntu gets the same benefit either way [02:18] the splash damage is desirable [02:18] You can still use REVU to get it mostly right, but once it gets an ACK, declare your intention to publish in Debian, and we'll ignore it. [02:19] ideally do both [02:20] persia: Ah, OK. [02:20] * directhex fails to write a limerick about picking licenses [02:20] anyway, BED [02:21] persia: Oh, and a wider debian politics issue: How hard is it to push patches upstream? (I'm technically a "co-maintainer" of a suite of packages I also steward in ubuntu, but the only person who has uploader rights in that group has been nonresponsive) [02:23] lfaraone, If you're a comaintainer, you just need a DD to upload. If none of the DD uploaders for the package are responsive, put a candidate on mentors, and ask for another DD to upload. #debian-mentors on OFTC is a good place to ask. [02:23] lifeless, both? How do you mean? === jmarsden_ is now known as jmarsden [02:26] persia: become a debian package maintainer and an ubuntu MOTU [02:26] lifeless: heh, I'm working on it :P [02:28] lifeless, Oh, yeah, that's a good combination for a person. For a package, I don't see the point of Ubuntu source NEW if it's at all likely to be interesting in Debian. [02:30] persia: oh, full ack; modulo freezes [02:30] persia: are the requirements for "participating" enough to qualify for universe-contributors defined anywhere? [02:32] lfaraone, Not quantitatively. Essentially, you need to demonstrate 1) understanding of Ubuntu ideals, 2) significant and sustained contribution, 3) integration with the development team. [02:33] Usually involves being around and active for several months, with some expectation of continuing to be around and active, and having a few developers who are willing to speak on your behalf. [02:35] persia: ah... I guess I'm confused on what is "significant". Most of my work has been in one suite of packages (same one I am co-maintaining in debian), and I've only done work in Intrepid. (Even though I'm somehow 113 in the "msot uploads to intrepid" list) [02:37] lfaraone, I'd recommend chatting with some of the developers with whom you've worked closely, and get their opinions on the matter. [05:12] Hi. In case Debian fixed a security issue with a standard new subrelease, do I ask for a sync following the SRU process, subscribing also Security team, or should I replicate the debian changes in an Ubuntu specific version? [05:13] in this case, Debian version change is from 0.6.0.2-2 to 0.6.0.2-3 [05:19] fabrice_sp: In general you should replicate the Debian changes for each Ubuntu release, following https://wiki.ubuntu.com/SecurityUpdateProcedures. [05:20] wgrant: I know, but in this case, the change is only in control file (to link with the correct library) [05:21] it's Debian Bug #504429 [05:21] Debian bug 504429 in kadu "kadu: CVE-2008-4776 remote DoS" [Grave,Closed] http://bugs.debian.org/504429 [05:21] Urgh. [05:21] fabrice_sp: That doesn't make it special. Just replicate that change as with a normal security update. [05:22] wgrant: ok. Will follow the standard Security Update, then. [05:23] By the way, should I also suscribe Motu SRU at the same time that Security team? [05:23] It's not a SRU. [05:23] So no. [05:25] This is fixed in Jaunty, so if I want it in Intrepid, it's not a SRU? Sorry about that, but I don't really understand how Securtiy Updates and SRU unteracts [05:25] (even after looking at wiki pages) [05:25] They are separate processes. [05:25] SRUs are for non-security updates. [05:25] While one called call a security update to a stable release a form of SRU, that's not how the terms are used. [05:26] s/called/could/ [05:26] ooook [05:26] I really thought a Security update eneded as a SRU [05:26] s/eneded/ended/ [05:27] will follow the Security update process then. Thanks [05:27] No, motu-sru is never involved. [05:28] Involed w/ what? [05:28] so, can you please usubscribe motu-sru from bug #297475? It's another one that I have to update then [05:28] Launchpad bug 297475 in dns2tcp "[Sync Request] Please sync dns2tcp 0.4.dfsg-5 from Debian Unstable" [Undecided,New] https://launchpad.net/bugs/297475 [05:29] NCommander: Security updates. [05:29] fabrice_sp: As a practical matter the contents of -security are periodically copied into -updates, but that's a Soyuz thing that doesn't involve us at all. Thay may be what you're thinking of. [05:29] Stupid question, why aren't security updates just put in -updates? [05:30] NCommander: So people can have -updates disabled. [05:30] StevenK, ICMP echo [05:30] NCommander: because some people just want security fixes [05:30] without anything else [05:30] Oh [05:30] ScottK: I really thought that all updates to a stable release should go to with a SRU [05:30] Makes some sense [05:30] * NCommander would agree w/ fabrice_sp [05:30] clear now :-) [05:30] fabrice_sp: Ah. Nope. As [05:30] NCommander: What's this thing you want me to look at? [05:30] As you now see ... [05:31] StevenK, its a no-changes SRU to a2ps so it can exist in updates (and then promoted w/i that pocket), and then a modification to xfprint4 to depend on a2ps [05:31] Isn't there a bug with the command-line override tool and pocket overrides? [05:31] wgrant, it worked fine on dogfood [05:32] I heard that before, hence why I got bigjools to test it [05:32] StevenK, https://bugs.edge.launchpad.net/ubuntu/+source/xfprint4/+bug/211335 - relevant bug [05:32] Launchpad bug 211335 in xfprint4 "Mousepad -> xfprint4 Crashes" [Medium,Confirmed] [05:32] Ah, bug #36022 [05:32] Launchpad bug 36022 in soyuz "change-override can't handle pockets" [High,Fix committed] https://launchpad.net/bugs/36022 [05:34] Looks like it hasn't rolled out yet [05:34] NCommander: So, no, I can't. [05:35] Strange that it would be fixed on Dogfood then [05:35] NCommander: It could have been done directly on the DB. [05:35] Which I can't do [05:36] Based on the scary script error in that bug, I'm not playing. [05:36] Exactly. [05:36] Wait for 2.11 [05:36] Fair enough [05:36] 2.11... 10 years? :P [05:36] I would think it would be -6 years [05:36] Fine. The next Launchpad rollout [05:36] NCommander: Sorry, but thems the brakes [05:37] -EBAH :-P [05:38] * NCommander listens to an awesome song [06:11] wgrant: I like the debian/changelog entry here: http://launchpad.net/ubuntu/jaunty/+source/mime-tools/5.427-1ubuntu1 [06:11] With that, I'm off to bed. [06:11] ScottK: Haha. [06:11] ScottK: I've filed 22 Launchpad bugs in the past 24 hours. [06:12] ahahahah [06:13] good morning [06:13] morning dholbach [06:13] hiya NCommander [06:14] * NCommander is eyeing over the current FTBFS lists [06:14] Morning dholbach. [06:14] hi wgrant! [06:14] hppa made a bit of a come-back while fakeroot was broken on armel :( [06:14] heh [06:14] lpia is really quite broken :-/ [06:15] armel is still beating it relative to last night, though. [06:15] In terms of throughput, or percentage of archive? [06:16] if its the later, I worry about HPPA :-P [06:16] Relative counts of pending builds. But I guess depwait isn't counted in those numbers on /+builds, so it's not right. [06:17] Well, from the armel build failures, I'm not sure the depwait checker is doing well. [06:17] Where's the best place to file a bug against http://qa.ubuntuwire.com/ftbfs/ ? I'd like a link to the page with the "rebuild me" button. [06:17] Indeed, it seems to only catch when deps are missing, not when the archive is borked. [06:17] persia: That'd be build/+retry? [06:18] Or retrybuild, one of them. [06:18] Well, doesn't have to be direct. I was thinking the build summary page rather than the build log. It's two clicks to the build log, but if it's just that debhelper couldn't be installed, I can press the pretty button. [06:18] NCommander, You look at these a lot. What do you think of that change? [06:19] * NCommander usually uses the buildd command [06:19] I think probably linking to the build page rather than log makes sense. [06:19] no [06:19] That would make things hardware because then its four or five clicks to the log [06:19] No, two. [06:19] Since retrying, while signifcant, is still only about half the build fixes [06:19] Click on build page. Click on log link. [06:19] s/page/page link/ [06:19] oh, I see [06:20] * persia starts retrying lpia universe alphabetically from ack where it's just build-dep stuff [06:21] I wonder if LP needs to grow an 'archive breakage' state where that kind of build will go. [06:21] Current click path is PTS -> Ubuntu -> version -> build page -> rebuild [06:21] Although I guess sometimes it is real build-dep combination problems. [06:21] persia: Version -> arch -> rebuild [06:22] wgrant, No, from the version page there's a link on the top right to the build page. [06:22] (unless that's going away early next week) [06:23] persia: I can click on the version number of /ftbfs, and get https://edge.launchpad.net/ubuntu/jaunty/+source/linux-meta/2.6.27.7.11. I then click on the appropriate distroarchseries in the Builds portlet, which gets me to the build page. [06:23] s/number of/number on/ [06:24] Oh. That's not so bad then. Ignore my request, as lots of packages need attention on multiple arches. [06:24] buildd.py is useful. [06:24] three -> two isn't enough benefit to pay one -> two for each build record. [06:26] SO is it possible to get limited upload rights to main? (someone was talking about that on the list a few days ago, and with the current talk on emacs-snapshot) [06:26] It is possible. You need to apply to the tech board, and have a strong history of maintenance for the package in question. [06:26] NCommander: Technically, yes. By policy, not entirely. [06:27] * NCommander would like to get upload rights to linux-ports, and linux-ports-meta [06:27] I think we have three such people. It's rare. [06:27] And I think one of them recently became a core-dev. [06:27] NCommander, You'll want to build some history first. [06:27] persia, I'm the only one who is actively touching this package? [06:28] wgrant, I thought we had three left, after that, but you may be right that it's only two (as only two names are springing to mind) [06:28] NCommander, history. It takes time. [06:28] Of course, there's no UI for it... [06:28] I see. [06:29] Generally it only happens when someone has been working for long enough on main stuff to normally qualify for core-dev, except that they only expect to do a small cluster of packages, and they don't expect this to change over time. It's a rare thing, and probably not best sought. [06:30] Ah, I see [06:31] * NCommander schedules package retries in universe [06:31] Start from the bottom of the list, so we don't collide :) [06:31] I'm right now retrying the r-* packages [06:31] Oh, that's fine. I'm still on a [06:31] I just jump around and retry obvious failures [06:31] It might be nice to have a mass-giveback on !(armel|hppa) soon. [06:32] It would be nice if LP retried failed builds once in awhile [06:32] wgrant, Who has to schedule that? Saves me poking things, since 6/8 packages I've examined so far would benefit. [06:32] persia: Somebody with DB access, I believe. Probably infinity. [06:33] Ah. That's hard then. [06:33] * persia goes back to doing it manually [06:33] Or, AIUI, he normally requests that somebody with DB access does them. [06:33] * NCommander pulls out the RAID utilities FTBFS [06:33] So one of the build admins could do it? (build admin != buildd admin) [06:33] Why can't glibc believe in a stable API :-/ [06:34] persia: Unsure. [06:34] * persia goes to a likely more informed channel [06:35] Bad time of day though. [06:35] Indeed. [06:36] bah [06:36] /usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments [06:36] * NCommander sighs [06:36] The sign of quality software: when including a header is enable to FTBFS [06:43] * wgrant tracks down LP bug #24 for this 24 hour period. [06:43] Launchpad bug 24 in rosetta "uploading language po file causes extra lines to be appended" [Medium,Fix released] https://launchpad.net/bugs/24 [06:44] lol [06:45] I have 8 minutes. [06:45] File a bug about a lack of UI for seeing people w/ limited main upload rights [06:47] That bug already exists. It needs to be a new one. [06:48] wgrant, No navigation from and architecture on https://launchpad.net/+builds to the list of pending builds? [06:48] * persia doesn't know if that already exists [06:48] I know one [06:49] Private team membership causes the recent team membership list to break [06:49] persia: Unfortunately that's dependent on there being such a list of pending builds. [06:49] https://edge.launchpad.net/~cody-somerville [06:49] And that has been deferred indefinitely. [06:49] Cody's page is a prime example [06:50] NCommander: Hmmm. Interesting. Maybe that's only because his last five are private. [06:50] Because other people who I know have private memberships have older teams listed. [06:51] * wgrant files it anyway, leaving LP people to deal with it. Nyahah. [06:51] wgrant, Ooh. Annoying. lpnet/ubuntu/+builds works, lpnet/ubuntu/$(release)/$(arch)/+builds works, but lpnet/ubutu/$(arch)/+builds doesn't work. Never noticed that before. [06:51] persia: That's because distroarch doesn't exist. Only distroarchseries. [06:51] persia: And Ubuntu isn't the only distro on LP. [06:51] Well, at the moment it is. [06:51] Which is why it's been deferred indefinitely? [06:51] wgrant, I just thought of it for your 24 bugs in 24 hours [06:52] wgrant, I also have another bug [06:52] persia: I don't know. [06:53] Right, #24 filed, but only 23 are open :( [06:53] wgrant, want another one? [06:53] Which one got killed? [06:53] NCommander: Sure. [06:54] persia: Bug #297882 [06:54] Launchpad bug 297882 in malone "Bug/+addbranch's subscribers portlet has strange header" [Undecided,Invalid] https://launchpad.net/bugs/297882 [06:54] Apparently that's present on all bug action pages. [06:54] Except for the main page, which is where most actions take place. [06:54] * wgrant rolls eyes. [06:54] wgrant, here's a hint [06:54] https://edge.launchpad.net/~kamion/+related-software [06:54] Look closely at the PPA section [06:54] so really the bug is the other way around. [06:55] NCommander: Nothing wrong with that, AFAICS. It was later copied to primary, so became public. [06:55] Also, edit description/tags has the main page UI. Seems odd to have two different portlets for the same purpose. [06:55] NCommander: The only possible bug there is that the P3A is linkified. [06:56] * wgrant files two bugs about that page. [06:56] wgrant, it was on that page before it was copied to primary [06:57] wgrant, That's too many. You have to wait an hour :p [06:57] NCommander: Really? One would need to check with a security person when they next upload, I guess. === fabrice_sp_ is now known as fabrice_sp [06:58] wgrant, that's difficult because they can't say what packages they uploaded due to the embargo ... [06:59] NCommander: Unembargoed stuff is still uploaded to the P3A. [06:59] ah [07:05] * RAOF wonders exactly _how_ broken the nouveau branch supporting DRI2 & GL_EXT_texture_from_pixmap is... [07:05] Poor sejong... [07:05] RAOF: You probably don't want to try... [07:05] Crack is bad. [07:05] Pffft! [07:05] Poppycock! [07:06] Sure, it needs private branches of mesa, drm, and nouveau. What could /possibly/ go wrong? :) [07:06] Oh, and a newer x11-proto-dri2 than Intrepid has, apparently. [07:07] persia: Well, I didn't realise that mass-givebacks were so remarkably easy to achieve. [07:08] wgrant, The trick is apparently to ask at midnight on a holiday :) [07:08] Anyone have any good suggestions for http://launchpadlibrarian.net/19636265/buildlog_ubuntu-jaunty-lpia.mplayer-libpostproc_1%3A1.0-pre1.1_FAILEDTOBUILD.txt.gz ? [07:09] RAOF, What's your current confidence level about Jaunty? [07:09] persia, gcc-3 is still in the archive for QEMU, I recommend using it (you might need to fudge the configure scripts to find it however) [07:09] persia: With respect to? [07:09] RAOF, nouveau [07:09] persia: Tell upstream to die. [07:10] NCommander, Do you really think that's the right answer? [07:10] wgrant, I'm suggestive, but not that suggestive. [07:10] persia: My guess is nouveau will stay in my PPA, and we won't sync it from experimental. [07:10] persia, my main issue is that there are a lot of ways gcc 4 changed things [07:10] Isn't our archive nice and happy now: http://qa.ubuntuwire.com/ftbfs/ [07:10] It's pathetic it still doesn't support gcc 4 [07:10] RAOF, OK. I just like to check each cycle :) Maybe next time. [07:11] But gcc 3 -> 4 could introduce a lot of suitable regressions [07:11] persia: Failing that, I could _possibly_ dkms-ify nouveau's drm build, and we could include it. [07:11] wgrant, Well, sparc still needs help, and there's apparently no data for ia64, and hppa is still special, but very much so :) [07:11] My expectation is that there won't be a nouveau release during the Jaunty cycle. [07:12] I'd say the lack of a nouveau release during the beginning of the cycle was the key bit. The dkmsification sounds like seriously cut crack. [07:12] Right. dkms-ifying it would be possible, but it's a work-around for it not being ready. [07:13] Ready is better. Introducing buggy nouveau doesn't really fit with "just works" :( [07:13] That said, Jaunty should be one step closer to nouveau; it'll have a libdrm that should work with nouveau, so we'd _just_ need the kernel modules. [07:13] For the moment, of course, until they require new libdrm API ;) [07:14] RAOF, I could see about getting nouveau added to the ubuntu folder in the kernel if dkms isn't an option [07:14] If libdrm is compatible, why can't we include the kernel modules? [07:14] Or is it just that it's still trunk, which is all sorts of dangerous? [07:15] Well, libdrm 2.4.1 should support nouveau, so we _could_ include the kernel modules in l-u-m or something, actually. [07:15] There's no guarantee that nouveau won't require API breaking changes to drm, but that's settled down a bit. I guess until the memory-manager's ready. [07:16] So which is the missing bit? [07:16] The kernel drm.ko + nouveau.ko. I'll just check that Jaunty actually has a sufficiently-new libdrm, though. [07:16] * persia isn't sure about nouveau-by-default by nouveau-from-repo is awfully tempting [07:16] s/by/but/ [07:17] Yeah, it is a bit. [07:17] RAOF, the source package produces these kernel modules and libdrm does it not? why not do it like a normal package just with a dkms binary package for these kernel modules then? [07:17] you would be at least guaranteed that the kernel modules that were in the archive at the same time as the libdrm matched API wise [07:18] Jaunty doesn't yet have libdrm 2.4.1, but it presumably will at some point. [07:18] superm1: That would be possible, yes. [07:18] superm1, Do you think that's better than trying to get them in-tree? [07:19] persia: It'd be tempting to go nouveau-by-default on certain hardware; nv4x & nv3x spring to mind. [07:19] I suspect that upstream might not be terribly supportive of that, though ;) [07:19] well it sounds like everything is in flux right now. having an unstable driver in tree that could potentially break kernel builds doesn't seem appealing to me. the API breakage part too... [07:19] nouveau is bettern than nv for nv4x? [07:20] persia: In every way, yes. [07:20] persia: Supports xrandr1.2, has best EXA acceleration of any driver. [07:20] * persia has an nv4x sitting around somewhere, and gets tempted, but still doesn't like PPAs [07:20] Oh, and high-quality Xv :) [07:20] RAOF, so libdrm 2.4.1 has everything needed for nouveau? [07:20] How does it compare to nvidia for nv4x? [07:21] persia: Faster at 2d, pretty much. And dual-head sucks less. [07:21] Does 3D work yet? [07:21] Nouveau is faster at 2d, I mean [07:21] Hah! Not for any value of "work" that you'd want to rely on. [07:21] heh. [07:21] It may draw on the screen, but it won't look like anything? [07:22] For example, 3D will currently inexorably exhaust VRAM until it's all full, and then fall over. [07:22] * persia remembers watching renderings of glxgears that defied explanation [07:22]