[00:01] _16aR_: into upstream author [00:03] <_16aR_> argh, someone just told me the inverse [00:04] <_16aR_> and to put the original maintainer of the project into upstream author [00:06] in Copyright: you need to put all copyright licenses of the source code [00:14] Quick question: Does anyone know how I would get dput to work through a proxy? [00:15] Megaqwerty: export http_proxy and ftp_proxy vars [00:15] fernando2: could you give me an example of the ftp_proxy var? (I know the http_proxy one is already set by Sys>Prefs>Network Proxy) [00:16] fernando2: nvm, found an example on Google [00:16] Megaqwerty: export http_proxy='http:/user:pass@10.10.10.10:3128" [00:17] =) [00:17] ftp_proxy follow same syntax [00:19] gn [00:24] _16aR_, by providing a patch the persons does not get copy rights over the entire source, unless the patch itself includes contents using a different copyright owner, on that case, yes you should list it on the copyright section also [00:25] but I guess, a 1 line patch will not be copyrighted :) [00:27] Or is probably not copyrightable. [01:02] umm, I have just brainfarted, who do I subscribe again for a sync request? :) [01:03] You're motu? [01:03] Sorry, I forget. [01:03] ya [01:03] ubuntu-archive [01:03] ahh, I was right..thanks [01:03] np [01:27] hey persia: i got your email on the MOTU list and i was wondering if there was anything i could do (without programming or packaging experience) to contribute to hardy development [01:27] i do have a powerful server with some bandwidth to spare [01:28] bmk789: In terms of contributing to development, the best way is really to work on code or packaging. In terms of supporting the development effort, there's a fair bit that would be helpful. [01:29] One thing that needs doing is to run the piuparts installation checker after the freezes. Dktrkranz is currently estimating time requirements, and might be a good person to ask about how more servers / bandwidth could help. [01:30] There's also some documentation things that would be helpful. One is looking at the list of software not in Sid from http://people.ubuntu.org.au/~fujitsu/motuscience/versions/universe.html, and discovering if there is a new upstream version available. [01:32] Another would be looking for software in the repository for which there are multiple versions (e.g. autoconf, python, wxwidgets, GTK, etc.). Lists of software that needs to be adjusted, along with pointers to migration guides could be useful. [01:32] Hm, I wonder if it might be a good idea to turn MDT's notes feature on (displays comments per-package from a wiki page). [01:32] Fujitsu: That might be useful. We'll need documentation on the comment format on the wiki page :) [01:32] I think the old wiki page is still there, even. [01:33] * Fujitsu looks. [01:33] It would be nice to have an mdt page in the style of ajmitch's RC bugs list, with a dynamic comment function. [01:33] thanks persia, ill look into those [01:33] yes, I was looking at doing that when I revamped the bug list [01:34] since the code for the bug list is partially shared with something ti did along the same lines of mdt [01:34] I guess it would be, yeah. [01:34] I'm also moving hosting of it off my home system :) [01:34] bmk789: And just because it's often forgotten: one of the best ways to support the developers is to look over the bug lists, and try to consolidate the various reports into only those for which we can prepare a solution. [01:34] ajmitch: Do you have a hosting site already organised? [01:34] i see [01:34] persia: I think so [01:35] ajmitch: Excellent. I look forward to not feeling guilty about polling :) [01:36] hrmm, I don't remember piuparts running so slow in the past [01:36] persia: yeah, it's a large page, and a slow DSL line [01:37] nixternal: How long do you think it should take to install/uninstall 20,000 packages? [01:37] I am not install/uninstall 20,000 packages, I am just doing 1 [01:37] Will piuparts use sbuild if it's available? That should speed things up significantly. [01:38] s/sbuild/schroot/ [01:39] nixternal: buy some 15K RPM hard drives & use them with a decent hardware RAID controller [01:39] it will use pbuilder if you tell it [01:39] then piuparts should be faster [01:39] sure, I will go do that right now [01:39] 15k SAS drives are nice and fast. Particularly in RAID10. [01:46] we replace iceweasel references with firefox right? [01:47] LaserJock: And hope it works, yeah. [01:47] LaserJock: Generally, but you might want to check with the #ubuntu-mozillateam folks, given that we also like gobuntu these days [01:47] We've only got a couple of packages broken because of that, IIRC. [01:47] hmm, I wonder if an | would work [01:48] right now I've got Depends: ${shlibs:Depends}, iceweasel | iceape-browser | xulrunner [01:48] * persia thought that should work unmodified, given xulrunner in hardy [01:48] but will that work for Firefox? [01:49] Isn't the plan for firefox to either provides: or depends: xulrunner? I forget. [01:49] Firefox 3 will be using xulrunner, but it won't work for current Firefox [01:49] persia: The latter. [01:49] Fujitsu: Hardy will have Firefox 3 by default, no? [01:49] persia: Presuming it will be released in time. [01:49] So we will soon be able to remove firefox without the world exploding :D [01:50] Hrm. Someone should get an official opinion from the mozilla team [01:50] Yeah. [01:50] Probably asac, really. [01:50] Fujitsu: It may be that there is already an official opinion, and we just don't know, so others could also share. [01:52] You probably want xulrunner-1.9 for the depend, don't you? [01:52] True, that's what Gran Paradiso uses. [01:53] RAOF: Why? Are there currently two versions of xulrunner shipping? [01:53] persia: Yes; xulrunner (which is 1.8 or 1.7) and xulrunner-1.9 [01:53] xulrunner is 1.8, xulrunner-1.9 is 1.9. [01:54] Right. Goal for next release (hardy+1): transition everything and watch it break :) [01:54] * ajmitch cheers [01:54] I thought that was a _Hardy_ goal [01:54] Fujitsu: do you want me to spend time on something for replacing mdt? [01:54] Since nothing currently depends on xulrunner, 'cause it does'nt work. [01:54] persia: Transition what? Only a Java plugin depends on 1.8. [01:55] RAOF: I doubt main will make it, and I'm certain universe won't. We'll transition a lot, but hardy is more about things working than pushing the newest, shiniest code. [01:55] ajmitch: If you want to, or I could try to post-exams. [01:55] the plan for Edubuntu was to ship Epiphany for hardy [01:55] no Firefox [01:55] well I've already got a steaming pile of code here to revive if it's needed [01:55] persia: A goal for Hardy is moving things off firefox and onto xulrunner-1.9. [01:55] Fujitsu: If it's just one package, why is there versioning for a transition plan? That's just silly. [01:55] * RAOF doesn't know, either. [01:56] persia: I guess to avoid messing with the package from Debian. [01:56] Fujitsu: Right. I meant *everything*, as in finish all the transitions in progress, and then spend four months trying to fix the resulting mess. [01:56] Ah. [01:56] but I need to figure out what to do with Gutsy so xulrunner is no help ;-) [01:56] (definitely a hardy+1 goal - hardy shouldn't be that broken) [01:56] LaserJock: What are you doing to Gutsy? [01:56] LaserJock: ping asac: he should have an answer you can trust. [01:57] Fujitsu: lots of things ... mwuahahahaha [01:57] LaserJock: Ah, for gutsy, yes. Firefox is the answer. [01:57] Fujitsu: gnome-chemistry-utils/gchempaint [01:57] LaserJock: Ah, messy. [01:58] tell me about it :-) [01:58] I spent the morning trying to figure out how to build stuff with static libs and misc other things [01:58] Heya folks. [01:58] ajmitch: A dynamically-generated, commentable, not-so-ridiculously-slow, likely more flexible mdt-like thing would be very useful. Particularly the commenting bit. [01:59] Hi TheMuso_Boston. [01:59] * persia seconds the call to ressurect ajmitch's super-mdt [01:59] versions2html is soooo slooow. [01:59] Fujitsu: and in ruby [01:59] which wasn't helping me [01:59] Fujitsu: ok [01:59] LaserJock: I'm fairly sure those things are interdependent. [02:00] not so sure about the 'dynamically-generated' bits though :) [02:00] * Fujitsu hacked it up a bit, even without any ruby experience... didn't break it tooo badly. [02:00] it could be expensive to do the version comparisons each time the page is displayed [02:00] ajmitch: What do you mean? [02:00] ajmitch: dynamically-generated commenting, etc.? perhaps. The raw data process might only refresh less often. [02:00] ajmitch: Oh, I didn't mean like that. [02:01] the rc bug list is a combination of processing a text file generated by a separate script, and comments stored in the DB [02:01] Just something better than the current comments system which scrapes from a wiki page hourly and gets caught in the next versions2html. [02:01] I'd probably do the same [02:01] ouch :) [02:01] yes, that's easy to fix [02:01] ajmitch: The same as rcbugs would be a vast improvement over the current. [02:01] I'm just trying to get mysql to cooperate on this system [02:02] it'll have to sit in the queue behind a plone site that I have to get done ASAP [02:02] hopefully not too far away [02:02] ajmitch: Thanks. [02:06] Hmm, I assume pitti is asleep at this time of day? [02:06] bddebian: He'd be in Boston, so probably not quite. [02:07] Gr, lintian is really annoying if the process gets interrupted mid-run. It doesn't bother to check what it has done when you restart it, so you need to manually mangle its status files to get it to redo the bits it missed. [02:14] persia: does http://motu.ajmitch.net.nz/rcbugs/ load any faster for you? [02:15] ajmitch: Fairly high latency still, but a lot faster. [02:16] ajmitch: Not noticeably, but I suspect that's a combination of Safari having a slow renderer and my not having loaded the previous page recently enough to be sure of my memory. [02:16] ajmitch: Seems faster to me than I remember before the Gutsy release. [02:16] it's in the US [02:16] it'd be hard to be slower, I think [02:16] That would likely help me... [02:16] wget says 3 times quicker. [02:17] the DB has just been copied, and this will probably be just for testing for now [02:17] so don't rely on stuff to stay around [02:17] ajmitch: Is that still targeting Gutsy? [02:17] yes [02:17] I just copied stuff for now [02:18] nothing more [02:18] Ah. Good. I was worried that the syncs somehow weren't including the bugs. [02:19] a minor rework of the code & I'll have lists for whatever distro [02:25] ajmitch: That would be extra cool for the SRU team. [02:25] * persia wonders who is a good contact for the SRU team [02:26] persia: There isn't such a team any more, is there? [02:26] Fujitsu: Well, there should be :) [02:27] e.g. someone should claim responsibility for trying to keep the current release working [02:29] so a team of people to do stuff, rather than just approve [02:29] Like we're meant to have for security, but motu-swat is sorta dead. [02:29] but being revived a bit [02:29] ajmitch: Well, maybe do stuff, but more 1) maintain a current release system to test things, 2) watch an RC bug list against the release system, 3) oversee and coordinate SRU efforts. [02:30] Hopefully, particularly with testing-security. [02:30] Is it? I subscribed motu-swat to a bug recently, and I'm pretty sure it got taken care of. [02:30] * tonyyarusso checks [02:30] Fujitsu: Is that what motu-swat was? [02:30] persia: motu-swat was for universe security updates. [02:30] Now that Debian tracks and handles security issues in unstable/testing, it makes that sort of thing easier. [02:31] Fujitsu: Ah. security only. I was thinking security + "cannot install", "segfault on start", "breaks on upgrade", etc. [02:31] "munches my system" [02:32] * Fujitsu takes a bite out of ajmitch's system(s). [02:32] hehe [02:32] yeah, bug #155990 - someone caught it [02:32] Launchpad bug 155990 in drupal5 "Several security updates and bugfixes in Drupal 5.3" [Undecided,Fix released] https://launchpad.net/bugs/155990 [02:32] is there a compiz team? [02:33] * persia thinks it's called something like desktop-effects [02:33] crack-fiends [02:33] hehe [02:34] becase THIS so called "addict" wants some more compiz packages [02:34] great [02:34] nosrednaekim: Best way to get them in is to package them [02:34] yeah, wellI have dial-up and so I can't do packaging very well [02:36] Hey guys, lamalex and Zelut are interesting in getting their feet wet in packaging-land, so you'll probably see them around a bit, and if you have time to offer some instruction/guidance give 'em a nudge. :) [02:36] indeed I am [02:36] lamalex , Zelut: welcome. [02:37] I've been lurking here a few days since UDS started.. just need to find some time [02:37] For people interested in starting, I'd recommend looking at https://launchpad.net/ubuntu/+bugs?field.tag=packaging. It's a nice list of how not to do things, and finding the solutions allows one to learn one thing at a time. [02:38] hehe, persia's making you learn and fix bugs at the same time! [02:38] crafty [02:38] Seriously though, it's a good point. [02:39] tonyyarusso: Not "making". Also, I think it's easier to fix a package that mostly works instead of trying to start from scratch. [02:39] persia: true [02:39] It's also of larger benefit to fix existing ones. [02:40] Because they're likely to be used, and don't cause a large maintenance burden afterwards. [02:40] night everyone, thanks for the help persia [02:40] * Fujitsu cringes at 639 Ubuntu-specific packages. [02:40] Zelut: good, you can take over the selinux stuff then [02:41] * ajmitch can give up on it for good [02:41] Hi Hobbsee. [02:41] Fujitsu: I was thinking, do they all have watch files? If so, perhaps they're not so bad... [02:41] TheMuso, TheMuso_Boston: I was looking at merges and I noticed that you are the uploader of axel. Is it ok if I submit this merge? [02:41] persia: Do any of them have watch files? [02:41] hiya [02:42] I wonder if I can pipe that list into DEHS... [02:42] * persia thinks requiring watch files should be a REVU approval requirement [02:42] ajmitch: heh, I'll do docs and testing but that might be a bit greedy yet [02:42] persia: That's a good idea. [02:42] * persia goes to find the wiki page to make it official [02:42] persia: Why? [02:42] Zelut: nah, you've been soloing selinux so far, go for it [02:42] * Hobbsee curses disappearing irssi and screen sessions. [02:42] * ScottK is gonna disagree. [02:42] Zelut: are you not the guy who does ubuntu-tutorials? [02:43] hey Hobbsee :) [02:43] ScottK: So that we have some chance of identifying packages that need a refresh early in the cycle when we're not synchronising from Debian [02:43] hi ajmitch! [02:43] nosrednaekim: I am [02:43] persia: OK. Got it. [02:43] Jazzva: I didn't touch it. [02:43] I only uploaded it. [02:43] Zelut: loved your latest article, but thats a bit off-topic :) [02:43] persia: I missed the distinction between requiring it for packages and requiring it for new packages we weren't getting from Debian. [02:44] ajmitch: hopefully the ubuntu-hardened list keeps picking up and we can get the policy working.. then I'll think about it. [02:44] persia: I do think that a process change must be agreed at a MOTU meeting though. [02:44] ajmitch: selinux has a way to go before its functional.. we had a sprint at UDS about it this week. [02:44] yes, I know you did [02:44] ScottK: Ah. Sorry about that. I'm just thinking the REVU guidelines: the other 13,000 packages should have one, but it's not as important. [02:44] nosrednaekim: thanks, glad to hear people still read the blog :) [02:44] ScottK: You're right. I'll add it to the agenda. Thanks for the reminder. [02:44] Jazzva: As in, I only sponsored the upload for someone else. [02:44] Debian is getting watch files progressively - a lot do have them. [02:45] persia: For REVU, I agree. Good. [02:45] persia: One of my goals for involvment in this cycle is to be a hardass about unagreed process change. [02:46] joy [02:46] ScottK: I appreciate that. Having someone watch the process change and make noise helps my goal of ensuring there is sane and progressive process change. [02:47] TheMuso_Boston: I see... I'll ask the person last mentioned in the changelog then :). Thanks. [02:47] Jazzva: No problem. === superm1_ is now known as superm1 [02:47] For those interested in watch files (persia and maybe Fujitsu) you might enjoy reading lamont's rationale for won't fixing the please add this watch file for postfix. [02:48] ScottK: reference pointer? [02:48] * ScottK looks [02:48] persia: What is your opinion on packages like bkp? [02:48] (note last upload, and popcon) [02:48] (and not being in Debian) [02:49] * persia is bothered by the lack of an Ubuntu platform, and hunts [02:49] https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/129316/comments/7 [02:49] Launchpad bug 129316 in postfix "New watch file" [Undecided,Won't fix] [02:49] persia and Fujitsu ^^^ [02:49] persia: Ubuntu platform? [02:49] ScottK: Thanks, looking. [02:50] ScottK: That reason isn't valid for most of our Ubuntu-specific packages, which don't have a maintainer (or anybody at all) watching over them. [02:50] Fujitsu: Agreed. I just thought it was an amusing counterpart to the watch file parade. [02:50] Fujitsu: My current client is an Apple shop, and requests onsite presence. As a result, I am limited. [02:51] ScottK: Yeah. [02:51] persia: Oh, lovely. [02:55] Fujitsu: That's why we need watch files. Compare with http://opensource.polytechnique.org/debian/bkp_0.6.3-2.dsc === mekius_ is now known as mekius [02:56] persia: Yeah, i saw that yesterday, but do we even want to keep it? Nobody uses it, and nobody has complained that it's three years out of date. [02:57] We can maintain the extra packages, or remove them if nobody uses them and there's little benefit. The latter is more efficient. [02:57] ScottK: Actually, when a maintainer is as active as postfix's, I don't mind that attitude. This is especially true for packages well maintained in Debian. On the other hand, for leaf packages in universe with maintainer as MOTU, I demand watch files as otherwise we forget. [02:57] persia: I think that makes complete sense. [02:57] Fujitsu: I agree, but I don't trust popcon. [02:59] Fujitsu: I think the policy for when to dispose of Ubuntu-only stuff likely needs some definition. It might be nice to also apply those criteria when accepting new random stuff. Personally, I'd like to see a very small amount of REVU activity that wasn't linked to some active external community. [02:59] persia: Right, same with me. [02:59] We do need a policy, or we accumulate enormous amounts of unmaintained... crap. [03:00] Fujitsu: If you have some ideas for such a policy, raising them for the 9th November meeing might be a good time: we'll only have had one REVU day, so people shouldn't be too in practice :) [03:00] what time is the meeting on the 9th? [03:01] ajmitch: 20:00 UTC [03:01] * TheMuso_Boston should send out a reminder... [03:01] ah, 9am on the saturday morning [03:01] I may be awake if I'm lucky [03:01] TheMuso: So soon? I'd wasn't expecting one until this weekend. [03:01] 7am on Saturday, should be doable. [03:01] It's 5am here, which is annoying [03:01] yikes [03:02] * persia tends to go to bed early before such meetings [03:03] persia: Well, yes, and I'll do one mid next week. [03:04] * persia thanks TheMuso_Boston for dedication to the MOTU Meeting process [03:05] persia: As much as I don't always enjoy doing it, I do it because it ensures that it gets done, and announcements are sent out, etc. === Hobbsee is now known as LongPointyStick [03:05] uh oh [03:05] * ajmitch hides from the LongPointyStick [03:05] TheMuso_Boston: That's why you got a "Thank you". If you enjoyed it, we'd all just think you were a bit odd. === LongPointyStick is now known as DeadlyLongPointy === DeadlyLongPointy is now known as DeadlyPointyStic [03:05] persia: ah ok. [03:06] * persia suspects there is painful prodding happening somewhere else === DeadlyPointyStic is now known as DeadlyPointStick [03:06] persia: yet at the same time, I don't want people to start assuming I'll do it. [03:07] TheMuso_Boston: You keep volunteering first :) === DeadlyPointStick is now known as Hobbsee === apachelogger_ is now known as apachelogger [03:07] heh [03:07] Yeah I know, but I don't want people to start thinking "Luke will do it, I need not worry" === Hobbsee is now known as LongPointyStick [03:08] persia: If you have noticed, I have been saying lately that I'll do it if nobody else wants to. [03:08] persia: no, there probably will be in future. [03:08] TheMuso_Boston: I don't think you need worry. At least I'll do it if I'm attending and you don't. Further, there are usually other volunteers when you don't make it. [03:08] Ok fair enough. [03:09] Hobbsee: Just flexing then? [03:09] * TheMuso_Boston tries not to think about that in a dirty way. [03:09] TheMuso_Boston: that's a wise choice [03:09] TheMuso_Boston: Think about intimidation [03:10] persia: If I'd not had a few beers earlier, it would be easier than it is. [03:10] TheMuso_Boston: Right. Timezones. My sympathies. [03:28] we don't have a mozilla package? [03:29] what's our equivalent to iceape [03:30] LaserJock: We killed off mozilla a couple of releases ago. I think we have iceape. [03:30] !info iceape hardy [03:30] !info seamonkey hardy [03:30] iceape: The Iceape Internet Suite. In component universe, is optional. Version 1.1.4-1ubuntu2 (hardy), package size 29 kB, installed size 84 kB [03:30] Package seamonkey does not exist in hardy [03:30] hmm, ok [03:35] !info internet-explorer [03:35] Package internet-explorer does not exist in gutsy [03:35] ;-P [03:40] * bddebian kills the conversation again... [03:41] that's ok, we're used to that [03:41] Aye :'-( [03:52] * TheMuso_Boston is outa here. Night folks. [03:53] bye [03:53] Night TheMuso_Boston. [04:01] Gnight TheMuso_Boston === evand_ is now known as evand [04:52] I'm making a moodle-standalone metapackage. Should I be editing the debian/control file of the moodle package, or of a new package that only contains a debian directory? [04:54] LaserJock: ^^^^^^ [04:54] LaserJock: and hi! [04:55] moquist: It depends on several factors. What is moodle-standalone intended to do? Does it require any extra code beyond that in moodle? Is there a reason it would be easier to maintain the package external to moodle? [04:56] persia: not necessarily. I'm just having trouble with it and wondered if the metapackage was supposed to be created separately. [04:57] persia: the 'moodle' package by itself will not install mysql-server or postgresql, and you must have one of them if debconf is going to successfully configure moodle for you. [04:57] moquist: That sounds to me like a problem with either the recommends: or the postisnt. [04:57] persia: so moodle-standalone-mysql will depend on moodle and mysql-server, and moodle-standalone-postgresql will depend on moodle and postgresql. [04:58] moquist: Does moodle recommend: mysql | postgresql ? [04:58] hehe... "postisn't" [04:58] persia: yes. [04:58] But we want the administrator to be able to choose a single package for installation and get a working configuration. [04:59] moquist: I'm not sure I see any benefit to moodle-standalone. Unless the user specifically requests otherwise, a database engine will be installed when moodle is isntalled. [04:59] well ... [04:59] * persia seems to be having issues with sn vs. ns [04:59] persia: the background is we're going to be shipping moodle in Edubuntu [04:59] so we need a good way of doing this at installation [04:59] LaserJock: you are now. :p [05:00] without messing up everybody else [05:00] LaserJock: I don't think -standalone is necessary for installation; preseeding can solve that [05:00] LaserJock: Can Edubuntu not just seed a preferred database? [05:00] (unless I'm mistaken, which is very possible) [05:00] that could be [05:00] Recommends: is just for the administrator to read and respond to, yes? [05:00] * persia generally disapproves of more package names: it tends to confuse people [05:01] but we still were concerned about having a package for people to install [05:01] moquist: Not quite. the package installation tools install all recommends: unless specifically told not to do so (this wasn't true for feisty) [05:01] so *we* need to pick a db but people have a choice [05:01] a problem has been that there were too much debconf questions [05:02] persia: I ran 'apt-get install moodle' on a fresh gutsy the other day and it didn't work because it didn't install a database server, and Recommends: postgresql | mysql-server. [05:02] and not everybody is going to have a db engine install prior [05:02] persia: The lintian run finally finished, and it looks like the results might actually be sort of sane. [05:02] LaserJock: Right. So if moodle recommends mysql | postgresql, and edubuntu recommends: moodle. mysql then most users will get a working moodle/mysql, and picky administrators will get a working moodle/postgresql [05:02] but Recommends are installed [05:03] *aren't [05:03] moquist: For which apt? apt-get only got updated recently. aptitude and the GUI tools have been doing the right thing a little longer. [05:03] * moquist checks [05:03] persia: "right" is debatable ;-) [05:04] right now in synaptic and apt recommends are only installed for metapackages [05:04] LaserJock: http://lists.debian.org/debian-devel-announce/2007/08/msg00000.html [05:04] persia: yes, I know, but that's not Ubuntu [05:04] LaserJock: Yet. [05:05] LaserJock: I was fairly sure that Michael intended to also implement it here [05:05] We pioneered recommends-by-default, so why wouldn't we follow the completion of it in Debian? My *our* apt maintainer? [05:05] *By, damnit. [05:05] LaserJock: it sounds to me like the -standalone packages aren't necessary, if apt in hardy will support Recommends:. [05:07] it would appear not [05:07] moquist: Well, Recommends: by default, but not enforce it. Still, meets your use case. [05:07] we still need simplified debconf though [05:07] s//install/ [05:08] LaserJock: Yes, and I think that's a separate issue. [05:10] bah. apt-ftparchive sources . complains "moodle has no source override entry / moodle has no binary override entry either". I've been reading the man-page but I don't grok it yet. [05:10] moquist: Your Section doesn't match expections, likely [05:11] moquist: You need to specify an override file, with lines in the form `package priority section' [05:12] Fujitsu: I can't fix this just by fixing the Section: line under Source: moodle? [05:12] * moquist notes that this seems to be a change in gutsy [05:12] I didn't get these errors (warnings?) in feisty. [05:12] Fujitsu: Thanks for running that. How bad do we look? [05:12] moquist: You might be able to, but I'm not sure. [05:12] * moquist nods [05:13] persia: We have around 70 more sources with issues, but 220 fewer binaries. [05:14] I'll publish the results in a sec and set it to run regularly. [05:14] Fujitsu: That's excellent. To be honest, I'm actually more concerned with the binary packages. [05:14] persia: Right, they're what matter to most people. [05:15] Of course, most people seem to mostly run lintian agaisnt source packages, but that's another issue, for another day... [05:15] It looks like a lot of people don't run lintian against their packages at all, but.. [05:16] * moquist installs lintian [05:16] * Fujitsu blinks. [05:16] Why do I see a maintainer "Maintainer: Ubuntu MOTU Developers " [05:16] moquist: Install linda as well. She looks at slightly different things, and doesn't whine as much. [05:16] * persia hides in shame [05:17] persia: is there one that fixes all the problems for you and cleans up your desktop icons too? [05:17] persia: heh. thanks...I think. [05:17] jdong: Not yet, but if you have a candidate, I'd be happy to review :) [05:17] * Fujitsu growls at dholbach. [05:18] Fujitsu: It wasn't me? I thought I typed that once. [05:18] oh wow, 3 each of lipia, amd64, and i386 for PPAs [05:18] We have a few variants on our maintainer: [05:18] Ubuntu MOTU Developer [05:18] Ubuntu MOTU Developers [05:18] * persia wants an ARM ppa [05:18] Ubuntu MOTU Devolopers [05:18] LaserJock: Yeah, but only the old two are operational at the moment. [05:19] * persia votes for Ubuntu MOTU Developers [05:19] huh? Never mind. [05:19] ubuntos -- the brown mentos! [05:34] * LaserJock pokes PPA with a stick [05:36] LaserJock: Why? [05:40] I've got two packages I'm trying to get built tonight [05:41] and they're stuck in "needs building" [05:41] Ah, yeah, the buildds weren't doing anything for several hours earlier. [05:42] I suspect something on cesium fell over when the new buildds appeared. [05:42] hmmpf [05:42] * persia suspects that the concentration of sysadmins in a single geographical location reduces uptime [05:42] persia: Not everyone is at UDS. [05:42] I was going to announce my packages to the forums this evening [05:42] Spads isn't, IIRC. [05:43] Fujitsu: Ah. In that case, I'm wrong. Hurrah! [05:44] samarium looks toasted [05:44] but thallium says Idle [05:44] as is iridium [05:45] LaserJock: They're manual, no? [05:46] bah, yes [05:47] alrighty, I guess I'll give up on that for today [05:47] Unfortunately, everybody will be asleep now, including those in London. Convenient. [05:47] the forums will just have to wait another day ;-) [05:48] Fujitsu: Is there normally a sysadmin on this side, or are they all European/American? [05:49] who's American? Spads? [05:49] * persia thought there was someone in the Montreal office [05:49] persia: AFAIK they're all in London. But I could be wrong. [05:49] * Fujitsu checks. [05:50] Montreal is not America ;-) [05:50] LaserJock: Yes it is. [05:50] * persia used to live in the Americas, and is fairly well versed in the corrent and annoying inerudite meanings of "America" [05:50] I think that's highly debatable [05:50] s/ent/ect/ [05:50] * ajmitch hugs Hobbsee [05:51] hello [05:51] persia: They're all listed as being in London, except elmo, and I know he is. [05:51] LaserJock: Yep. Highly so. Still, timezone-wise, it applies. I don't consider African vs. European sysadmins to be meaningfully different [05:51] Fujitsu: Ah. Interesting. Thanks for checking. [05:52] Oh, I see that that bhavi guy who tried to join every team in existence also tried to join ~canonical-sysadmins. Nice. [05:53] * Hobbsee hugs ajmitch. hiya! [05:53] Fujitsu: bhavi? you mean there's another one? [05:54] persia: if you think Montreal is in "America", you have serious issues [05:54] Hobbsee: Yeah, but this was a few months back. [05:54] ah, right [05:54] Yay, http://people.ubuntu.org.au/~fujitsu/lintian/universe/. [05:54] It seems to have actually worked. [05:55] Burgundavia: I'll claim São Paulo is in America as well :) [05:55] it is in the Americas, yes, but not in America [05:55] * persia doesn't understand Maintainer: (unknown) [05:57] persia: Neither. [06:00] that's what we should do for MOTU :-) [06:01] * Fujitsu notes he missed several DebianMaintainerField variants before. [06:01] * persia considers bumping the upload count to consolidate all the errors [06:02] Aha, gtkgo is the one causing ubunto-motu@lists.ubuntu.com [06:02] * Fujitsu thinks people should check that sort of stuff on upload. [06:03] it's easy to glance at & miss [06:03] Fujitsu: people? Why not tools? Add a lintian rule that complains if one uses the case-insensitive string "motu" in Maintainer, and doesn't use the appropriate string (same for "core", I'd think). [06:03] i'm surprised that LP doesnt have a filter set up to reject those mails [06:03] persia: That's a good idea. [06:03] sorry, that the MOTU ML [06:03] Hobbsee: Which mails? [06:03] oh, my bad. [06:04] i'm misreading - thought you were talking about accepted mails to the list [06:04] persia: dput hook :) [06:04] * persia suspects mail in the queue of unaccepted mail [06:04] refuse to upload if X,Y & Z conditions are not met [06:04] ajmitch: That's harder. What about things like the creation of the Ubuntu MOTU Torrents Team as a maintainer? [06:05] Should dput first be patched? I'd prefer advisories. [06:05] what about it? just have a blacklist of common problems [06:05] of course, some of it are legitimate uses of not having the MOTU as the maintainer [06:05] for stuff like siretart's xine-lib, which the recent mail was about. [06:05] yes, but misspellings are not legitimate [06:05] Hobbsee: Right, which is why we grep for motu first. [06:05] oh, of course. [06:06] I particularly like Maintainer: Maintainer: Ubuntu MOTU... [06:07] heh [06:07] yes [06:10] Fujitsu: Likely just cut & paste. I know I've done that (although I am glad I don't appear to have uploaded the results) [06:11] update-mime-database is run by dh_instalmime isn't it? [06:12] LaserJock: I think so. [06:12] It is. [06:12] LaserJock: You may also want to run update-desktop-database, for the MIME representations, depending on your MIME type. [06:12] this package has a postinst and prerm script that looks like it just has the dh_* stuff in it [06:13] so I'm thinking I should just get rid of them [06:13] LaserJock: Does the package also use the dh_* calls? Are the final results broken? Sometimes a maintainer decided dh_foo wasn't flexible enough, or hand't heard of it. [06:14] they use dh_* [06:14] it looks like maybe the added dh_* later and didn't realize they didn't need their maintainer scripts anymore [06:14] * persia still suggests inspecting the resulting binaries [06:15] man this stuff takes so long [06:15] it's gonna take me all week to get one package done [06:17] Haha, in the lintian source: [06:17] # Wookey really only has one name. If we get more of these, consider [06:17] # removing the check. [06:17] They've got an exception for this one maintainer who has just one name. [06:19] That's the spelunking software, isn' it. Hrm. I should look at that again: it needs porting to wx2.6 [06:20] * RAOF is a millionaire base-jumping spelunker [06:20] RAOF: Do you use any cave mapping software with Ubuntu? [06:21] persia: Yeah; I've got an integrated tablet PC built into my suit. [06:21] RAOF: Which package do you use? [06:22] Um, I can no longer continue the charade. [06:22] * persia has been duped, and gives up on building a moral lcase for RAOF to do the port [06:22] You obviously didn't get the initial movie reference :) [06:23] Is it python? [06:23] NO! Resist! [06:23] Which port is this? [06:24] * RAOF really has to learn to not overcommit quite so much. [06:26] Fujitsu: survex-aven needs to migrate from wx2.4 to something more recent (2.6 is preferred by the aforementioned single-named DD so that it may be adopted by Debian). The trick is that the survex maintainer doesn't want wx strings in the survex code, but only in survex-aven because of the ugliness of WX unicode handling. [06:27] persia: Ah. [06:27] * Fujitsu must depart now. [06:27] heh [06:28] * RAOF thinks it would be awesome if all cross-platform stuff currently using wx* was magically converted to cross-platform gtk [06:28] RAOF: converter scripts (yes, even in python) welcome :) [06:29] ello all [06:29] Again, with the learning to not overcommit. The correct response is *not* "hm... I wonder if that would be possible"! [06:30] * persia thinks that's an excellent response. Perhaps followed by "Let me see..." [06:30] possible sure, gtk ? ugh, qt == <3 :P [06:31] How cross-platform is QT? [06:31] imbrandon: While I'm willing to believe the possibility of WX -> GTK semi-automated port, the backends of QT and WX are just far too different. [06:31] RAOF: More than GTK, and for longer [06:32] I knew it started out as more cross-platform. It's just that I don't think I've *ever* seen a windows QT app. [06:32] RAOF: Internet Explorer? [06:32] What, really? [06:32] Heh. Cross platform *with* integration :) [06:32] RAOF: qt was not free on windows until qt4 [06:32] RAOF, ther are tons of windows QT apps [06:32] opera is another good one [06:33] * RAOF has been insulated, obviously. [06:33] RAOF: Now, here's the trick. Find a closed-source non-Java non-QT app on Windows [06:33] but RAOF is right in that there were not Free QT apps until recently, as you needed a QT license to use QT on platforms other than windows [06:33] linux, rather [06:33] personally, I think the KDE people are chasing a rathole with KDE-on-windows [06:34] Burgundavia: No. You could use the free QT license to develop for windows, as long as you wrote free software. [06:34] Burgundavia, kinda, you could use the cygwin qt3 [06:34] to write gpl stuff [06:34] Burgundavia, why? i run KDE ( native ) on OSX daily [06:35] why not windows [06:35] because it is a lot of development work for little benefit [06:35] native == !X11 port, but native QT on OSX [06:35] Burgundavia, nah it is actualy very little changes, and most are in mainline kde svn [06:36] initial porting was probably easy [06:36] now have fun with all the corner case bugs that are going to popup [06:37] you got to think, the base was already done for many many releases, QT, all that needed porting was a few things in ldelibs, then every kde apps works [06:37] kdelibs* [06:37] umm, right [06:37] software development doesn't work that way [06:37] kde apps very very very seldom work below the QT abstraction layer [06:38] Burgundavia, ummm sure not all, but in this case yes, think how long QT has been on windows, almost 11 years if not more [06:38] its not a "new" thing [06:45] * RAOF wonders if hitting his students with sticks would prevent them from trying to integrate discrete varables. [06:45] unlikely [06:45] see, this is why i dont take maths. [06:46] * RAOF wonders if hitting his students with *Hobbsee* would prevent them from trying to integrate discrete variables. [06:46] You come in an easy-to-wield pack, right? :) [06:48] and fourrier transforms into a size suitable for storage in your backpack [06:48] As long as you cutoff the infinite tail? [06:49] Or is Hobbsee infinite in space and time? :) [06:49] infinite in length but not area :P [06:49] RAOF: of course i'm infinite :P [06:49] RAOF: infinte, by the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! ™ [06:50] * persia suspects the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! ™ is not infinite [06:50] * RAOF imagines a museum exhibit... "Hobbsee over the ages" [06:50] Hobbsee: aren't you studying computers or something at University? [06:50] pwnguin: yes. [06:50] pwnguin: although currently i'm doing physics, optoelectronics and computing subjects :P [06:51] optoelectronics surely counts as maths [06:52] pwnguin: Only for {} values of "maths" [06:52] GAH! This student has treated the continuous variables as discrete, and the discrete variables as continuous! [06:52] set values of maths? [06:52] Empty values of maths [06:52] * RAOF lets fly a mighty roar [06:52] RAOF: Just assume a regular pattern of reality shifts :) [06:53] well, ive seen my roommate's optoelectronics book, and i declare it to have enough formulas to be math-worthy [06:53] pwnguin: Formula's aren't math. Thinking about tea is math. [06:53] I'll never understand australians [06:54] Formulas are almost anti-maths. [06:54] Also, 0^(-1/2) is not 0. [06:54] heh [06:55] nullity [06:55] I wonder if these people keep a specially insulated "test brain" in a sensory deprivation tank and only take it out in order to write stupid crap that I have to mark. [06:56] pwnguin: very rarely. [06:56] pwnguin: in so far as using a calculator, yes. [06:56] my roommate had an entire sheet of formulas he took into the test [06:56] in rather small handwriting [06:56] i dont pretend to know EE [06:56] there are forumulae, though [06:57] pwnguin: This is indicitive of them knowing what the hell is going on, not their ability/need to do maths. [06:57] when did math become plural ? heh [06:57] imbrandon: Always in !USA :P [06:57] imbrandon: its a british thing [06:57] and australian, by transitive properties [06:58] pwnguin: In the same way that it's American by transitivity? :P [06:58] you clearly dont understand the Algebra of Nations [06:58] pwnguin: Any time that you're working in a field where they know enough to make quantitative predictions, there'll be huge, ugly formulae. This is not maths :) [06:59] RAOF: also, remember that students likely spend more time in the test than they give themselves for the homework. "oh crap, that's due in 50 minutes from now" [06:59] pwnguin: Homework? _What_ homework? We don't give any homework. [06:59] tutorials? [06:59] Tests, and more tests! Then exams! [06:59] which must be predone? [06:59] well that makes sense now [07:00] your students are idiots because they've never had to take the time not to be [07:00] Hobbsee: For a value of "pre-done" which closely approximates "glanced at the book that contains it" [07:00] haha [07:00] RAOF: Isn' t that just extra work for you? You could send them home with tests, and make them mark it at the next recitation. [07:00] * RAOF suspects this appoximation is exact as the number of students approaches infinity. [07:01] "oh look, why did everyone get full marks?" [07:01] heh [07:01] we had someone do that for a psych recitation class [07:01] What's even better is that someone has done this test quite well... and not put any identification on it _at all_. [07:01] the dumbass TA basically brought the whole class before the honor board when they did the enevitable [07:02] Ah, teaching. [07:02] RAOF: oh, i've been known to do that - although that was only including my student #, and not my name [07:02] the algebra of nations: America + Britan == 0 [07:03] its very similar to the algebra of computer design [07:03] Intel = -Motorola [07:03] whenever intel makes a design, motorola sees that and does the opposite [07:03] pwnguin: So, which nation is 0? [07:04] it may have been wrong of me to bring up things like numbers [07:04] Indeed. Also, is it an actual algebra, a ring, or a field? :P [07:04] but ... antartica? [07:04] its probably a field [07:05] because if you take something and add america to it, it gets smaller ;) [07:05] actually, i havent studied number theory enough to know the difference aside from the math nutters nearby joking about it [07:05] So it's isomorphic to a Z mod p, or Z mod p^n :) [07:06] * imbrandon explodes [07:07] anyways, im tempted to say that austrialia is zero, because if you add britian and australia, you wind up with britain again [07:07] spelling is not my strong point, i dont think [07:08] Actually, all the elements are idempotent: country + country = country. [07:09] you heard it here first: RAOF declares Austrialia idempotent [07:09] RAOF: i should dig up some code people submit in undergraduate Operating Systems [07:10] they have four weeks per project and still go wildly wrong in some cases [07:10] That at least has the benefit that it compiles, surely. [07:10] It's at least syntactically correct. [07:10] well, one hopes [07:10] its -30 percent if it doesnt [07:10] and you likely wont be getting full credit in such a case even if it DID compile [07:11] my favorite was the "use a Condition Variable as part of a condition variable" [07:12] so what does new Condition() do? it sets up some local variables, and then calls new Condition() [07:12] Stack space is for pansies, I say. [07:12] Terminating recursion is boursoise. [07:13] there you go [07:13] * RAOF is utterly incapable of spelling that. [07:13] the compiler can do some pretty good optimizing tricks [07:13] * Hobbsee attempts to figure the gnome-hearts merge. [07:13] but it cant optimize away an infinite loop [07:14] Hobbsee: gutsy gnome-hearts doesn't work at all: please fix it when you merge :) [07:14] persia: yeah, i just noticed it didnt work in gutsy [07:15] persia: looks like we can take debian's, which will likely break again, or go with upstreams. [07:15] but, i thought the gnome people put the same packages into debian and ubuntu [07:15] or at least, close to it [07:15] Hobbsee: I suggest going with upstream, as we've upstream gnome-games for the cards, but I hope you'll keep the rules change for the jack of diamonds. [07:15] persia: the round the moon? [07:16] Hobbsee: Right. Last I checked (several months back), upstream penalised you for jack of diamond for round-the-moon. [07:16] persia: ah right - so the cards package is in our gnome-games, and not accidently synced from debian? [07:17] Hobbsee: I thought so, but my memory is fuzzy, and I was only working on the code by proxy (for someone who is now no longer active) [07:17] ...why are there no icons on my desktop? [07:17] because you asked it to hide them? [07:17] Because you're using nouveau & a composite manager? [07:17] or perhaps nautilus crashed [07:18] Hobbsee: Open up somewhere from Places... : it might just fix it. [07:18] ah, so this was a mistake in stopping nautilus from starting up [07:19] Hobbsee: Well, unless you don't want a desktop shell :) [07:20] wow multiarch live boot cd's ? nice [07:20] well, i'd like my dsektop icons. i'd guessed it was a preloading thing for nautilus [07:31] Hi all === asac_ is now known as asac [08:40] right. a non-broken version of gnome-hearts. [09:22] hello please synchronise my keys so that I can start uploading packages [09:22] hello please synchronise my keys so that I can start uploading packages [09:22] coolbhavi: You've joined the team? [09:23] Does it echo in here? [09:23] yup contributors of ubuntu universe [09:25] coolbhavi: Great. Unfortunately, most of the REVU admins aren't around right now. I'd suggest asking for a keyring sync in either 4 or 12 hours (unless someone wants to contradict me) [09:27] Ok some days back I had asked the same and they told it would be over by an hour [09:27] coolbhavi: In that case, it's probably done. Have you tried to upload your candidate? [09:27] How to check the keyring sync? [09:28] coolbhavi: Checking is really frustrating, and only admins can check. It7s very rarely done - it's easier to sync again. Try uploading. [09:29] Whats my login? [09:29] and my pass [09:29] * ajmitch can sync now [09:29] coolbhavi: Your login will be assigned to match the email in your changelog when you upload. Once you've uploaded, you can recover your password with your key. [09:30] ok can i login with my mail id and password? [09:30] keyring will take a few minutes to sync, just started it now [09:30] coolbhavi: What did you upload? [09:31] * persia thanks ajmitch [09:31] I want to upload a package apt write [09:32] How to do it? Please help [09:32] coolbhavi: Have you read the wiki page about uploading? [09:33] No Link please [09:35] coolbhavi: https://wiki.ubuntu.com/MOTU/Packages/REVU [09:35] coolbhavi: Use RAOF's link :) [09:36] * RAOF suspects he just beat persia to the punch [09:37] I already have the deb package then what to do? [09:38] coolbhavi: Ubuntu doesn't accept binary uploads. You'll need to upload the source. That wiki page explains how. [09:39] wow , qemu without acceleration on a p200 is painfull [09:39] Ok source means I have a perl script.. again Should i rebuild? [09:39] coolbhavi: You'll want to build a source package. `debuild -S -sa` [09:40] imbrandon: What are you emulating? [09:40] x86, just tesing a livecd [09:40] err live-iso [09:40] :P [09:41] * persia imagines imbrandon wrestling with a wrathful plastic disc, intent on having him for dinner [09:41] heh [09:41] imbrandon: For special pain, emulate a PowerPC and test the liveCD :) [09:41] i think i'm gonna call it a night on it though, i just got dropped to a busybox tem on boot [09:42] persia, hehe i have before, infact ... [09:42] imbrandon: On your PII200? [09:42] i have setup a scratchbox env to build deb packages using qemu-ppc emulation to cross compile [09:42] is a P1 200 [09:42] yes [09:43] * persia thinks imbrandon needs the build farm back [09:43] lol the scratchbox was on the build farm [09:43] it was just to see how hard it would be to make ppc packges on a x86 [09:43] not very fun [09:43] Right. Umm. Magic better build farm? [09:44] :) [09:44] its slowly getting back there [09:44] i have some hardware laying arround and some more on the way [09:44] i'm takin my time this time though to make sure it dosent all blow up overnight like last time [09:44] Ok got it.... If we want to upload a update of an existing package What to do? [09:44] and actualy DESIGN the network and infra [09:45] coolbhavi: In that case, you probably want to upload a debdiff to a bug. See https://wiki.ubuntu.com/MOTU/Contributing/ [09:46] Got it [09:46] Thanks [09:49] imbrandon: No rush. Something good is far better than something now. [09:49] yea thats my thinking , last time it wasent [09:50] imbrandon: At the time, I suspect something now was better than something good: wasn't that prior to REVU, PPA, and all the other nice things we have now? [09:50] no i mean last time, i just threw some things up, not worring about quality as much [09:51] and yea it was prior to PPA and much of the new scripts but not [09:51] REVU [09:52] ugh, live-helper is great but .... ummm ... a bit buggy [09:52] probably works great for Debian, not so much if you plug ubuntu packages in [09:57] persia: Hello [09:58] persia: nice to meet you again [09:58] s1024kb: Hello. I'm about to head off: if you seek something specific from me, please tell me now :) [09:59] persia: excuse me, what did you mean?:) [09:59] persia: i am very happy to meet an old friend (old enough? haha) here [09:59] s1024kb: My apologies for the confusion. Nice to see you again. [10:01] persia: imagine when a person knows nobody in IRC... when he/she meet one who he/she had ever chatted with, he/she will feel very happy...:) [10:01] persia: It's afternoon here in China, i had just finished my job. [10:02] s1024kb: Ah. I understand now. It's a bit later here, so I'm just leaving. Have a good evening. [10:32] ...we're doing what now? [10:32] as if MOTU didnt already have enough to do [10:32] http://www.mikesplanet.net/2007/10/ubuntu-forums-ubuntu-development-programming/ [10:34] Hobbsee: with more people, we'll have less to do :) [10:34] jpatrick: yeah, but i'm interested in using our resources for people who can be trained usefully. [10:35] Did I miss the bit where we were told this might be happening? [10:35] as in, get useful people, rather than people who either a) drain MOTU, or b) give up, when they realise that it's hard. [10:35] Fujitsu: it's as good as done. the expectation will now be on the forums, and the MOTU will get bitched at for not answering all the packaging queries. [10:36] all discussed with...it seems...1 member of MOTU? [10:36] based on how they go for testing stuff out, and providing useful things on the forum for that (or not), i cant see the packaging would be any better, when it's an order of magnitude harder. [10:37] Hobbsee: One member of MOTU, or just dholbach? [10:37] Fujitsu: dholbach is a member of MOTU [10:37] He's.. sort of special, though. [10:37] Sorry, what? [10:38] Fujitsu: yeah, but he cant make a commitment on what the MOTU will do like that. [10:38] The forums don't seem like a particularly awesome place for that sort of stuff. [10:38] with any sort of real expectation that we'll jump on board. [10:38] RAOF: yeah. just read the link. [10:38] RAOF: You'd think not. [10:38] Hobbsee: That's what I meant. He's not exactly representative of the MOTU community. [10:38] Fujitsu: oh, indeed, but i think he's attempted to act as one there [10:39] ah, here's the implementation: [10:39] Implementation [10:39] * [10:39] * Fujitsu is reading it now. [10:39] Possiblity of some approved MOTUs to moderate the packaging forum. [10:39] * [10:39] Scott Ritchie (YokoZar) has volunteered to moderate the forum [10:39] * [10:39] Provide a link to the forum in the MOTU IRC subject topic [10:39] Steps for moderation: delete, delete, delete, delete. [10:39] a) no one will do it [10:39] b) great. there's 1. [10:39] Erm... [10:39] c) everyone will ignore it. if they cant get new packages done off revu, what chance do we have of forums stuff? [10:39] Why the heck do we want to send people *to* the forum? [10:39] hahahah :) [10:40] because the forum sheep refuse to come to us. [10:40] I do my share of pointing. [10:40] see, this is the problem - we dont just want to recruit people - we need to recruit *good* people. [10:41] and doing it in a forums place is definetly not a good medium for that. [10:41] Not Joe "wooot i'm going to package new compiz on crack" Random. [10:41] exactly [10:41] Maybe a forum *could* be a good place for some form of mentoring, though. A nice shared place with easy markup, etc. [10:41] oh, why does it break when i do it with checkinstall? [10:41] Indeed. [10:41] RAOF: doesnt help much when people don't search. or RTFM. [10:42] Or use checkinstall. [10:42] even when pointed to the page. [10:42] Most of the people on the forums don't want to make an Ubuntu-quality package. [10:42] Fujitsu: they think all packaging gets done with checkinstall [10:42] They just want their stuff, *now*. [10:42] RAOF: most? i'd guess for all [10:42] exactly [10:42] * RAOF was on the forums first. [10:42] RAOF: You seem to have recovered well. [10:42] oh, that nutter is posting about his new distro again [10:43] * Hobbsee flamed the hell out of him when he queried her :) [10:43] What, he queried you? [10:43] It seems totally misjudged. [10:43] oh yes [10:44] Hobbsee: Who? [10:44] he queried a whole bunch of people, who were prospective developers [10:44] Fujitsu: http://ubuntuforums.org/showthread.php?t=598026 [10:44] Ohhh, forums. [10:44] samfisher - when he had no forums post at all [10:44] I haven't read them in a long time. [10:44] So nothing good will come of it, basically. The best we can hope for is for it to distract people who would otherwise distract *us*. [10:44] Um, lovely. [10:45] Sounds really productive. [10:45] Heh: "Poll: is SMART data reliable". Well, that seems like the proper use of democracy :) [10:45] well, they have a wallpaper! isnt that the start of *any* perfect new distribution? [10:45] raof: Haha [10:45] Fujitsu: Indeed. Also, absolutely, totally unlike Debian. [10:45] Hey, the Ubuntu wallpapers were good marketing for Ubuntu! [10:45] The reason I am not working on Ubuntu is because there are numerous problems that are difficult to resolve and integrate because it is already there and stable, if you know what I am trying to say? I'm not sure if that is very clear though... [10:46] The nerds will come to you but you’ve got to work your ass off first. No one, absolutely no one, who is any fucking good will come near your project if its nothing more than a few airy ideas. [10:46] Poll: is rainy a weather? [10:46] Also, will use RPM for KDE, and dpkg for Gnome (because apparently KDE is made by redhat) [10:46] RAOF: That's what I thought when I saw the poll, yeah. [10:46] exactly. [10:47] Ooh, I want to join the project as an assembler! [10:47] heh [10:48] RAOF: oh *nice*. i never got that far. [10:48] *snort* === chuck is now known as zul [10:48] Hobbsee: I have a low interest threshold when marking. [10:48] what are we bad mouthing now? [10:48] * Fujitsu laughs at the Contact page. [10:48] zul: desktop-linux [10:48] RAOF: ah url? [10:48] `Web Help' is a decent subject for a support email? I see. [10:49] desktop-linux.org [10:49] zul: the forums, us helping them package, and desktop-linux [10:49] zul: which is from the forums, and just says there will be a perfect linux distro, with no details as to how. [10:49] Must... implement... SIGECUTE... [10:49] Hobbsee: But they have a wallpaper! [10:49] Fujitsu: and that's what *really* matters [10:49] Hobbsee: Or even what perfect means, in this context. [10:50] ajmitch: Duh. [10:50] why would you need "Assemblers"? [10:50] Oooh, their main focus is installation! [10:50] Or even what current distros do badly. [10:50] Our Linux project aims to fix all the problems of other distributions and still be a powerful Linux. Our main focus will be on installation. [10:51] because ubiquity sucks, right? [10:51] Haha: [10:52] Poll: [Idea] Can we lay off the polls? [10:52] ajmitch: Obviously. [10:52] Heh. Everyone should build stuff as root, all the time. [10:52] RAOF: you don't? [10:52] what is this world coming to? [10:52] i like their announcements [10:52] RAOF: now go read my reply [10:53] * ajmitch hunts for a link [10:53] http://ubuntuforums.org/showthread.php?p=3683057#post3683057 [10:54] Hobbsee: Ah, a sane response in that downgrading thread! [10:54] Fujitsu: it was first via a privmsg - and then the guy started the thread. [10:54] harsh [10:55] ajmitch: better harsh now, and them not poaching devs, and getting people to go do something useful instead [10:55] although, Kmos might like it - lots to do, no mention of QA. [10:55] heh [10:55] probably no trouble with getting upload rights at all. might be a good fit. [10:56] Hobbsee: what? [10:56] Kmos: see http://ubuntuforums.org/showthread.php?p=3683057 [10:57] Kmos, ignore it, is the always funny *i know it all*, *you suck* mentality [10:57] now, i wish i knew it all. but i dont. [10:58] I found this on their forum: "I personally like Ktorrent. I am not sure if that relies on KDE though." [10:58] just has funny and smart as the new desktop-linux.org [10:58] jpatrick: yay. well, that's very legitmate - because they're probably not sure what their definition of kde is, too. [10:59] Hobbsee, anyway, you like to pick someone to show you know *more* [10:59] "To work perfectly, we will be using a scratch system." [10:59] lamego: hehe [10:59] lamego: sorry? [10:59] * zul ducks [10:59] On the other hand, scratch apparently doesn't include package management. [10:59] AUTOMATIX FTW!!! [10:59] this is automatix v3 under another name? [11:00] "Yes, I think one of the main things keeping users away from Linux is package systems. " - idiot [11:00] Hobbsee: Yay! [11:00] Awww, it's so cute: http://desktop-linux.org/forum/directx-10-gaming-for-linux-t39.html [11:00] "We should totally implement directX 10" [11:01] would be nice. implement it somewhere useful, like in wine. [11:01] jpatrick: Oh? I know all the people I introduce to Linux from Windows would prefer to locate and compile their own software from scratch. Don't you? [11:02] Hobbsee: They're already on it, thankfully. [11:02] Fujitsu: my dad is quite happy with apt since he started Kubuntu 4 days ago :) [11:02] RAOF: yay! [11:02] Hobbsee, your particular non sense of inserting Kmos into your own jokes, could be interpreted as lack of respect, but because we all signed the CoC, I am sure and it was just bad humour :) [11:03] Hobbsee: In fact, I think that the wine guys are going to try to do DX10-on-Windows, too. [11:03] lamego: not at all. i know Kmos likes being im multiple projects, and that may be one that he's interested in - based on how he's been acting in debian and ubuntu so far. [11:04] lamego: would be the kind thing to do to pass it on, if i suspect he's something he's interested in, no? [11:04] * Hobbsee counts. RAOF, jpatrick, zul, Fujitsu, ajmitch...how about we all hit the sponsorship queue? [11:04] get it down to a reasonable size again [11:05] * ajmitch is crashing [11:05] * Hobbsee ponders....does respect for people also mean that they follow their processes? [11:05] Hobbsee: You'd think so. [11:05] Hobbsee: You can count me in on Sat, but for now, I really need to enter marks, go home & sleep [11:06] hmmmm [11:06] RAOF: okay. you're still at $work? [11:06] zul: you have no excuse :) [11:06] $uni, yes. [11:06] RAOF: where your $workplace == $uni :) [11:06] Hobbsee: I have the excuse of it being after midnight [11:06] Hobbsee: sure I do, A. I just woke up B. Im still not dressed C. I have to feed liam D. I have to go to work, take your pick ;) [11:06] Hobbsee, let me interpret your question, Ubuntu and Debian can be compared to desktop-linux or whatever, as a motivation for someone to participate at ? That was you reasoning ? [11:07] Hobbsee: Yeah. [11:07] Hobbsee: could you +1 aplg's squash on revu? [11:07] ajmitch: indeed. have a good sleep [11:07] zul: sigh. you people make bad excuses :) [11:07] night [11:07] Hobbsee: heh [11:07] lamego: nope. === Kmos_ is now known as Kmos [11:08] lamego: and to be honest, i'm rather sick of you attempting to paint the worst picture of me that you can - when it's not true. [11:08] oh crap... [11:08] * zul ducks and cover [11:08] uh, sorry " because the forum sheep refuse to come to us." [11:09] meeee [11:09] lamego: oh, are you a forums person? [11:09] I am not painting anything, i am being factual [11:09] Hobbsee, I was, for support, when i had the time [11:09] lamego: i didnt realise. by "forums sheep", i actually meant those who are on the forums only, and who believe that everything is done on ubuntu in a forum - albeit a hidden one. [11:09] lamego: based on the fact that your'e ehre, i doubt that's you. [11:10] i'd say most of us likely started on the forums, and then left it for bigger and better things. [11:10] Hobbsee, ok, so I should feel better now, unlike last year which I was a sheep :) [11:10] lamego: well... :) [11:11] lamego: you're doing getdeb. you're still stacks ahead of most people, in actually doing productive things in the area of ubuntu [11:11] lamego: how many posts do you really think could have been avoided, on teh forums, if people had searched first? [11:12] * persia thinks that's the nature of forums [11:13] Hobbsee, well, how many quetions would have been saved if all people knew how to use google ? That is human nature, something you can't change accord yo your own experience [11:13] according [11:14] why does my own experience tell me that you cant change human nature? [11:14] i seem to have missed that part, and your arguments seem to be mighty weak. [11:14] but this is true. googling is a skill, and i wish more had it. [11:14] or learnt it. [11:15] you are somehow classifying forums as a "lower" resource, more likely to attract less skilled people [11:15] have you seen evidence to the contrary? [11:16] no, I totally agree with you, however, less skilled, also means, hopeful skilled people [11:16] which, unfortunately, means that they need to make the jump between forum, and non-forum mediums. [11:17] lamego: Hopefully skilled is great, and learning is great, but doesn't it make sense to learn by fixing some of the open bugs, rather than arbitrary packaging and forum discussion? [11:17] skilled people is already "in use" :P [11:17] (because they will have to at some point, as we cant implement all development stuff effectively on the forums) [11:18] persia, actually I don't agree with packaging & bug fixing as a common task, packaging is for packages, distribution integrators, bugs, are for upstream providers, developers, which care about their core (the app) and not about the integration with a particular distro [11:19] there are skilled people in many places. those who know how to prioritize, learn, etc, tend not to be on forums - or active on forums - as they dont post, due to searching. [11:19] mornin' ubunteros [11:19] hiya deadwill [11:19] developer skills are usefull for packaging, but not a key requirement, understanding makefiles and install process is not app evelopment [11:19] lamego: Ah. My experience is that many bugs are related to packaging, and the rest are small. Feeding patches upstream is one of the ways I define "skilled". [11:19] Hobbsee, :) [11:19] heh the forum users should just fork everything [11:19] zul: forumbuntu? [11:19] ubuntu forum remix? [11:19] Hobbsee: sure whatever turns your crank [11:21] zul: it would be interesting to see how far they got though. [11:21] Hobbsee: sure i wouldnt use it though [11:21] you make the assumption that it would release. [11:22] * zul must go do option C [11:22] Ah, the not-awesome part of webmail. When it breaks into hundreds of shiny, sharp pieces and all I want to do is *go home*! [11:22] muhahahahaha. [22:17] yada has to die, its worse than old debmake [11:23] * Hobbsee agrees! rid it from debian, so we can easily rid it from ubuntu! [11:23] Fujitsu: perhaps someone should introduce the concept of yada on the packaging forum? :) [11:23] RAOF: no ssh into uni? [11:23] Hobbsee: Yes! [11:23] * Hobbsee waves to EtienneG [11:24] Fujitsu: which will have nice side effects, of course. [11:24] hello Hobbsee ! [11:24] Like causing all the forum packagers to die? [11:24] Fujitsu: haha. no [11:24] Hobbsee: Am in uni. Plenty of SSH out, and in, but it doesn't help when I was *composing* a message. [11:24] RAOF: ah, true [11:24] * RAOF makes a run for it anyway. [11:24] RAOF: was thinking if you went home, and didyour uni work from there [11:25] Fujitsu: no - it just wouldnt ever build in ubuntu - nor get accepted due to it. [11:25] EtienneG: at UDS again? [11:25] persia, packaging bugs are most likely caused by less skilled people, the forum type of people which does not have an use for that particular problem, if they become experienced, then they will leave the forums and help you with the bug fixing [11:25] Hobbsee: Ah, true. [11:25] Does anyone happen to know the dctrl-tools magic to generate a list of reverse build-depends? [11:26] persia: erm, let me look [11:26] Hobbsee, not this time [11:26] Junior teams are very important, even for major all-star senior teams :) [11:26] Hobbsee, are you ? [11:26] EtienneG: oh, i thought you were an employee [11:26] EtienneG: nope [11:26] lamego: assuming they actually get good, at some point. [11:26] Hobbsee, yes I am, however, I am not a dev (support analyst) [11:26] EtienneG: ahhhh. [11:27] EtienneG: so you work with kurt? [11:27] Only distro/Launchpad is at UDS, right? [11:27] lamego: I'm not sure I agree with forum people == less skilled people, but that aside (and no, I don't want to discuss that uncertainty), I'm not sure of the value of any packages produced by individuals for whom one cannot be confident that packaging bugs can be fixed. [11:27] Hobbsee, hopefully, I will participate once a year, but since I was in Seville, I passed on this one [11:27] Hi TheMuso_Boston. [11:27] Hobbsee, well, if you don't get juniors, you never get seniors, unless you expect someone else to handle the juniors for you :) [11:27] Hobbsee, yep, I am Kurt's colleague [11:27] persia: grab http://damianv.com.ar/downloads/rbuildepend [11:27] EtienneG: [11:27] EtienneG: " You Poor Bastard" [11:27] :) [11:28] Hey Fujitsu. [11:28] Hobbsee: Cool. Thanks. [11:28] Fujitsu, yes, pretty much, although we have a couple of support people from Mtl there too [11:28] lamego: yes, but it's not a grading. [11:28] Not long got up, and doing my morning mail session. :) [11:28] persia, ah, and you believe that you (the team) can actually provide fixes for the entire *universe* ? [11:28] * persia waits for the transpacific lines to cleear [11:28] persia: the grep-dctrl lingo i can never remember, although it says in here. [11:28] and i think i wrote a rune for it, in my list of useful runes [11:28] lamego: I believe the team can do that, but I also believe that the team is constantly growing. I don't see value in division: we are all one team. [11:29] The team has to, and the team normally does. [11:29] Hobbsee: Yep. That's my problem too. I have a list of useful arcana, but still treat it as a grimoire [11:29] hehe [11:29] * Hobbsee greps it. [11:29] Fujitsu: in conjunction with debian [11:29] Hobbsee: True. [11:29] Hobbsee: Absolutely [11:30] persia.meet( luk__ ) && luk__.meet( persia ) [11:30] luk__: Hi! Nice to meet you :) [11:30] luk__: have you seen persia's recent mail on QA to the motu mailing list? === luk__ is now known as luk_ [11:30] persia, at the cost, of out-dated packages :) [11:30] hi persia [11:30] yes, I should still answer something I guess ;-) [11:31] lamego: That's the nature of division. If everyone packaging was packaging towards the same goal, that problem wouldn't exist. [11:31] persia: luk_'s one of the debian release managers, and interested in qa collaboration between debian and ubuntu. [11:31] luk_: Actually, that mail was more targeted towards getting tools to get a handle on the problems. We're still a long way behind when it comes to understanding what needs to be done :) [11:32] lol [11:32] persia, not really, the goals are not always compatible, and there are not enough resources to cover all the goals [11:32] lamego: there rarely are. although ubuntu+debian don't do too badly. [11:32] luk_: In terms of sending back, I'm still trying to think of a good model: monolithic packages isn't scaling, and telling everyone who submits a patch to Ubuntu to also submit one to Debian is pushing a lot of useless / meaningless patches into the BTS. [11:33] btw lucas did some piuparts run for Debian, but I still need some time to coordinate filing the bugs [11:33] and getdeb, etc, is a help [11:33] assuming people want to go browsing for each new version of each new app that htey want [11:33] In terms of pulling from Debian, I'm hoping that once we can track stuff, we'll be able to adopt more of the existing Debian fixes, which should go a long way towards freeing resources to actually test stuff, and develop useful patches. [11:34] Hobbsee, I am not saying we are bad, I am just saying we can be better, we as, in ubuntu/debian, insert your prefered distro here :) [11:34] lamego: agreed. we can always do better :) [11:35] lamego: Well, I'm uncertain about resources. I agree about goals. However, I argue that separation of focus leads to inadvertent duplicate work, which means that someone's effort is wasted. By coordinating more closely, a greater total sum is accomplished. [11:35] that's why I'm interested in coordination of the efforts [11:36] * persia notes that my argument with lamego is in miniature a reflection of Debian's argument with Ubuntu, in some ways [11:38] persia: That's true, to an extent. [11:38] I do have that Debian vs Ubuntu in my pocket for some future getdeb flamewar :P [11:38] persia: excluding those who attempt to go back and fix it each time. [11:38] luk_: As I see it, there are a few things to consider: 1) How to preserve valid Ubuntu/Debian variation without increased confusion; 2) How to make sure that QA efforts on both sides are shared smoothly; and 3) How to avoid culture clash (maintainer respect vs. raw collaboration) [11:39] bdmurray: ping when you wake up. [11:39] bdmurray: i'd like a bughelper rune done please. [11:39] Hobbsee: I'd disagree. Even where the Ubuntu and Debian packages are managed by the same person, there is frequently duplicated work due to the intentional differences between the distributions. [11:39] persia: as in sync requests [11:39] yes, perhaps. main, more so, due to the rosetta exports [11:39] There was actually a discussion about this sort of colaboration between MOTUs and Debian at Fosscamp on the weekend. There were a lot of people involved, including people from core-dev, slangasek, and one or two people who are involved in Debian. [11:40] Hobbsee: Main more so, yes. Parts of universe in reflection, and parts of universe due to attention. [11:40] TheMuso_Boston: i'm oh so glad that this was a public discussion, able for anyone to attend :) [11:40] TheMuso_Boston: did you have a list of things from it? [11:40] persia: well I want to focus on point 2 for now... [11:41] Hobbsee: Not really, it was just an informal discussion. Nobody was taking notes or anything, and unfortunately there was no outside discussion via VoIP afaik. [11:41] luk_: I'd agree that is the appropriate focus for our discussion, I just wanted to make sure that the other two were mentioned towards an understanding. [11:41] TheMuso_Boston: *nods*. thought that might be the case - like the launchpad discussion in sevilla. [11:43] luk_: From the Ubuntu side, a lot of our coordinated efforts currently surround FTBFS, NBS, and unmetdeps. I'm hoping we can expand that to piuparts stuff for this cycle, but I'm not confident we'll get much farther. [11:43] NBS? [11:43] luk_: not built from source [11:43] Our uncoordinated efforts are much wider, but given that they are uncoordinated, I'm less sure how to develop a plan to share without running into other issues. [11:43] (binaries) [11:44] luk_: NBS: leftover binaries due to library soname transitions, architecture changes in control, etc. [11:44] luk_: In terms of those coordinated efforts, how can we best feed you? [11:44] I guess in Debian they are taken care of by a decruft run by ftp-masters [11:45] luk_: We also do decruft, but as we don't have sid/testing we need to make sure there are no rdepends first, so there's a bit of API porting, etc. [11:45] ah ok [11:46] what do you exactly mean with feeding me? results/patches of test runs or do you mean tools/people? :-) [11:48] luk_: I wasn't thinking specifically of anything: more that we generate variance to fix FTBFS, port rdepends for NBS, and various adjustments for unmetdeps. This variance can be expressed as patches. It might also be able to be highlighted in some way for attention. How would Debian QA most like to receive this work? [11:49] luk_: Also note that not all of it applies to Debian. Examples include python2.5, WX2.8, kernel variations, etc. [11:49] https://wiki.ubuntu.com/QATeam/Specs/DeveloperWeatherReport is starting ot look interesting. [11:51] * persia hopes universe is reported (perhaps on a second page) [11:52] i think they're still trying to figure out *what* to do [11:52] well knowing where to look for particular kind of issues would be a start, in Debian most of these are found on http://svn.debian.org/wsvn/collab-qa and http://qa.debian.org/debcheck.php [11:54] luk_: For debcheck, we usually target http://alt.qeuni.net/~william/debcheck/, although historically `apt-cache -i unmet` is more common. If Ubuntu has a fix for Ubuntu, should that be a BTS entry? Should someone be notified? [11:54] gst.ElementNotFoundError: playbin <- any idea ? [11:55] debcheck is mostly used for Recommends and Priority, though the last one lacks manpower [11:55] lamego: The pipeline is broken, and can't figure out how to play the stream. [11:55] hum, I am running inside a schroot [11:57] If there is a fix for a Debian issue, a bug report with a patch attached would mostly be appreciated [11:57] luk_: http://svn.debian.org/wsvn/collab-qa looks like a collection of tools to me. I'm happy to try to organise running them against Ubuntu, and getting people to patch stuff, but that comes back to how to get stuff back. [11:58] yes, it's a collection of tools which are run mostly by lucas [11:58] Hmm, I have a question about contributing packages to the universe repository. [11:58] luk_: That's actually where we're lacking people most. From what I understand both the DCT and Utnubu teams get excited each Debconf and UDS, but have difficulty coordinating closely (Utnubu tends not to be MOTU and DCT tends not to be DD), and fail to find the time to actually troll through the variance. [11:58] I packaged my game- i think I did it correctly. [11:58] I used dput to upload it [11:59] Repsa_Jih: See Preparing new Packages in https://wiki.ubuntu.com/MOTU/Contributing [11:59] It returned 'Succesfully uploaded packages' and then 'Not running dinstall' [11:59] if we would have some central repository where we can track version information next to the issues, it might be easier to coordinate the fixes [11:59] Yeah, I read most of that. [12:00] luk_: There are a few factors at work: 1) testing Ubuntu fixes against Debian, 2) sending the patches, 3) getting them applied to Debian (at least from this perspective) [12:00] Repsa_Jih: That's the expected output. It looks like the upload worked. It should show on REVU in about 10 minutes. [12:00] Oh, allright :) Thanks :) [12:01] Another, thing, are there any 'lists' or 'requests' of applications that need packaging or upgrading? [12:01] luk_: That actually sounds great. Ideally something that could grab different types of bugs from both LP and the BTS, organise by package, and allow for dynamic commenting. [12:01] persia: in general yes, though for most of the issues of these runs it should be trivial to see if they fix the issue in Debian AFAICS [12:01] Hobbsee: The MOTU/Debian discussion was part of fosscamp. It was public to everyone at fosscamp (I was there too). [12:01] Repsa_Jih: https://launchpad.net/ubuntu/+bugs?field.tag=needs-packaging [12:02] Thanks [12:02] Repsa_Jih, what is your game ? [12:02] persia: yes, that would be great to have [12:02] Annchienta, http://annchienta.sf.net/ a adventue 2d rpg [12:02] luk_: Depends. If the package has no variance, testing the patch against sid is easy, but the solution may need to be different for Debian, given different base packages. If the package has variance, the patch needs to be altered to apply to the Debian package, and then again may not work. [12:02] *adventure [12:03] * persia seeks a volunteer to draft a base spec (no, not a blueprint) on how a LP & BTS collaboration report site might work [12:03] persia: But this is not the usual case. [12:04] Lamego: sorry I can't seem to send private message because I am not registred here. [12:04] ah [12:04] I'll register, hang on. [12:04] ok :) [12:04] ScottK: I'm not sure about that. Trolling the RC buglist right before release, I found that only about 50% of the Debian patches solved the issue for Ubuntu. I'm not sure it wouldn't be the same in the other direction. [12:04] or just provide me a link for your building rules :) [12:05] lamego: Wait a few minutes, and it will be public on REVU :) [12:05] persia: we are only talking about FTBFS and unmet dep issues, right? [12:05] persia: OK. Most of the time when sending stuff back to Debian, I know up front if it's a good fix for them or not. [12:05] ScottK: right. which no one was told about prior to fosscamp :) [12:06] luk_: I'd think also NBS, just to speed your various library transitions, but sure, we can only talk about FTBFS and unmetdeps. [12:06] Hobbsee: fosscamp didn't have a plan in advance. Each day people just wrote on the board what they wanted to do. [12:06] Hobbsee: fosscamp deliberately didn't have an agenda. Some people there decided to talk about that. [12:06] persia, depending on the package complexity and quality I may be publishing it at the same time it gets the first comment on REVU :P [12:06] fair enoguh [12:07] Hobbsee: It was mostly getting to know each other kind of discussion. [12:07] ScottK: guess a mailing list post wouldnt have been appropriate, about "we're having a discussion on this now" either - too many people == unproductive discussion [12:07] unmetdeps should be mostly trivial and FTBFS that are not toolchain specific should also mostly be trivial to see if they would apply for Debian or not, no? [12:08] lamego: See, that's an example where collaboration could be useful: if it met the requirements for distribution, having you add a +1 would get it in faster. If it doesn't, having you add the first comment explaining why would get it in faster. Having you publish it means that someone else still has to do what you did. [12:08] The most useful thing I got out of it was the notion that when dealing with Debian, you aren't dealing with an organization, but a bunch of individuals, so how you approach it and how it goes will vary widely. [12:08] ScottK: right, yes. [12:08] Hobbsee: I also got a DD to agree to sign my key so I can start NM. [12:08] lol [12:09] you said. well done :) [12:09] * ScottK is now feeling motivated. [12:09] luk_: The operative word is should. While many of us are likely to make best efforts, I'm just worried about a flurry of random "Doesn't work with python2.5" bugs from those who aren't as careful. [12:09] As, right. Forgot. [12:09] As/Ah [12:09] yes, Debian is mostly a bunch of individuals, though luckily there are also some teams ;-) [12:09] persia, I am not a MOTU, I am reviewing every getdeb package, a la getdeb, which may is not Ubuntu QA, the packages which I am 100% to be Debian QA, are merges [12:09] * ScottK goes to make coffee. [12:09] for those, there is not much to review :) [12:10] persia: well you said something about faster library transitions ;-) [12:10] lamego: Right. That's good work. Doing it for Ubuntu would be better, as it frees up more resources for more people. [12:11] persia, Right, but I prefer to do it for getdeb, because I can do more things, and I have a greater control of the entire release cycle [12:11] what's a getdeb package? I guess I should read some more documentation :-) [12:11] luk_: While it doesn't always work, we tend to try to port things to newer APIs sooner. That's an area where I'm more worried about cultural clash: we tend to work well with Debian teams, and some maintainers, but others tend to be vocal. [12:12] luk_: An unofficial repo with newest upstream compiled against most recent stable release Ubuntu. Policy compliance is variable, but the packages tend to work. There's a small team maintaining it. [12:12] lamego: Sure, it's just that when you do it that way, your effort has no benefit to Ubuntu. [12:14] persia, let's not go into the "outside of the community" again, how does an Ubuntu user using getdeb differs from a Ubuntu user using the repositories ? [12:14] persia, why not ? the building rules are all available, that is the packaging work [12:14] lamego: From a user perspective, not much. [12:15] persia, from a developers perspective, the work is available, it may not be good enough for some projects, it may be for others [12:15] lamego: Because it still needs the reviews, etc. Further, often things don't work against the newest development stuff (because they are targeted at the released version). Lastly, there often appears to be duplication of work done in Debian, which makes for double review. [12:15] you are not talking about work, you are talking about labor [12:15] i mean, MOTU labor [12:16] lamego: from a user perspective, the ability to get automatic program and security updates. [12:16] Hobbsee, that is an acknowledge limitation, being worked [12:16] lamego: Right. That's why I said you would contribute more to Ubuntu by commenting on REVU entries: that means more hands, more can get done. [12:17] lamego: Essentially, if we're all one team, keeping all of universe in shape is easier. [12:18] persia, universe aims development, getdeb aims current release, there is no enough people giving attention to the "current" release, from an users perspective [12:19] persia: is there some documentation about all the tools used for Ubuntu QA and where to find them and their results? [12:19] packaging is not all about a distro upgrade and security fixes, not from a end users perspective [12:19] lamego: I agree that not enough people are following the current release. On the other hand, I think I like the method backports uses better: first get it into the development release, then compile against the current release, then get a couple people to test it, then put it on everyone's workstation. [12:20] lamego: No, that's a small portion of packaging. packaging is about making sure users have good software to use, and that the software can be installed and uninstalled cleanly, and that the software is well integrated with the rest of the system. [12:20] persia, I don't have numbers to argue on this, but I am not sure how efficient back ports are, from a throughput perspective [12:22] luk_: Not really. The closest would be the thread starting https://lists.ubuntu.com/archives/ubuntu-motu/2007-October/002600.html, although we've a couple more bits filtering in. I'll likely update https;//wiki.ubuntu.com/MOTU/TODO (or some subpage) with a more complete list this weekend. [12:22] lamego: As I understand it, that's largely a matter of 1) not having very good advertising, and 2) not having very many testers. I think backports needs a good web interface, some publicity, and a bigger testing team. [12:23] Having backports easily enabled, and not upgrading to backports packages by default, would be a good start. [12:24] persia, I agree, if that happens getdeb can focus only on emerging packages, which are not going into the dev release [12:24] Fujitsu: Wasn't someone looking at setting the right variables in Release.gz? [12:24] persia: We know the variables to set, but it will require going through a couple of years of Soyuz quarantine, probably. [12:24] lamego: That only creates differentiation. Why not also get the packages into the development release, and perhaps also into Debian (if they are interested)? [12:25] Fujitsu: years? That's painful. [12:25] anyway, the concerns for packaging into dev, are very different, there you need to care about toolchain changes, policy changes, a lot of changes you dont need to address when packaging for current [12:25] persia: You know how quickly LP moves, particularly new features suggested from the outside. [12:25] a backport can be much more time consuming then just packaging for current [12:25] lamego: Actually, the toolchain changes tend to be minor, and the policy is there for a reason: we really don't want to break things (including the law) [12:26] Policy isn't just there for the sake of being there. [12:26] * persia seeks a report from a backporting MOTU regarding the relative difficulty of backports [12:26] persia, because, providing the same QA levels, with the current small team (was 1 person at the beginning) would mean, 1 release/week or/day, something which is not compatible with a software portal [12:26] lamego: So don't duplicate the work. Join the normal team? [12:26] lamego: Right. You can't do it alone. Join the team, and we'll do it together. [12:26] persia: It's generally quite easy. [12:26] persia, I mean, packaging policies, like moving to python-x.y, dropping php4, etc [12:27] persia: Where it gets tricky is packages with lots of rdepends. [12:27] persia, I am not alone any longer, a few people have joined [12:27] lamego: bring them all: we can certainly use the help. [12:27] persia: ok, I'll try to create a complete list of tools used and their results and issues within Debian QA during this month [12:28] lamego: One of the things I'd really like to see for Hardy is a team focused on making sure that it gets a full suite of support, including security, SRU, and backports. Currently, there have been no volunteers to drive this. [12:28] persia: because its a lot of work? [12:29] people love SRU [12:29] :D [12:29] luk_: That would be great. If you could tell me where it ends up (mail is fine, if IRC is awkward), I'll try to get you a list of equivalents (or get them created). [12:29] The Debian security tracker should be able to be integrated-with, which will help with security support. [12:29] uff, I give up, the differences are so clear, and you keep looking at it is the same work but just done on a different team :P [12:29] SRUs, well... we need a million people to triage bugs. [12:29] lamego: There are differences, but there is also overlap. [12:30] zul_: It's not actually that much work, it's more that most devs run the development release. Having active people using the current release (and, even better the LTS release) makes it fairly easy. [12:30] what are the issues with SRU? [12:31] luk_, is not an easy/practical task to deal [12:31] luk_: Well, we need to identify the issues and work out if they're SRU-worthy, and then actually do them. [12:31] luk_: It's not unusual for an SRU to sit in proposed for a long time due to lack of testers. [12:31] persia, I don't find such work appealing, specially SRU which is great for enterprise managed environments and for core components, but an adoption blocker for home users universe [12:31] ... how does SRU block adoption? === zul_ is now known as zl === zl is now known as zul [12:32] lamego: Sure. It needs more people. Like I said, security, SRU, and backports. I suspect you'd be of great benefit in backports, and would have good advice for those working on SRUs as to whether the new upstream fixes the issue properly, or it needs a target patch. [12:32] ScottK: where can I see what issues are identified and what issues need testing etc? [12:32] Fujitsu, when you can't provide users with key required features which were introduced after the release freeze, because of processes or because of lack of human resources to handle such upgrades [12:33] or because they may break other things. [12:33] you bough this new gadget yesterday, which is only supported by the new upstream release X.Y, that will not go though SRU [12:33] which is why the SRU is in. [12:33] sure, but there are backports. and that sounds kernel-ish. [12:34] luk_: Look for bugs tagged verification-motu-needed to see where Universe SRUs need testing. [12:34] luk_: https://launchpad.net/ubuntu/gutsy/+bugs is an example URL for gutsy. Adjust the URL to suit. It's not a perfect list for various reasons, but it's fairly close. [12:34] Hobbsee, right, I trust more on some upstreams than I trust on some SRUs, it all depends on who manages such upgrades, it depends also on the upstream QA :) [12:34] lamego: indeed. which is why we test too - for the case where upstream's QA fails. [12:34] lamego: When was the last time an SRU was published and caused regression? [12:34] if upstream's QA is good, then it should go fairly well. [12:35] and quickly [12:35] particularly universe [12:35] lamego: Actually, for universe packages, gadget-foo only supported by upstream X.Y is sometimes considered, especially for upstreams with good QA. [12:36] persia, sure, the cost to develop a specific patch for an SRU, versus adopting the new upstream release which includes much more, is sometimes much higher compared to the effort of fixing any regression that you may be afraid to introduce [12:37] specially, being an universe package, and a non disruptive or blocking regression, which you would identify during the package validation, or, on a timely manner [12:37] lamego: It's better to not have regressions at all, rather than be trying to fix them later. [12:37] lamego: Depends on the upstream. We often publish new upstream versions (especially in stable release series) for SRUs. What we try to avoid is changes in behaviour - we don't want to break the user workflow. For new features, we use backports. [12:37] Fujitsu, I could argue that, you don't have regressions, you have tons of bugs which were fixed upstream :) [12:38] lamego: Right, then you find the patches that fixed them. Look at them. Note lack of regression potential. [12:38] how do you handler for example, game upgrades, which include the core network game changes ? is anyone insane enough to provide such a patch without going through an upstream release backporting ? [12:38] No. [12:39] Backports handle that. [12:39] I don't think I've seen an SRU for that sort of things. [12:39] *thing [12:39] lamego: Those are generally cases where we want to push a new upstream. Depending on the available servers, that may be a backport, or it may be an SRU (usually backports, as the process is faster) [12:39] right, on this particular case (there are others), SRU will keep a dead application on the repositories :) [12:39] I mean dead, because game servers, and windows gamers, move to the next version ;) [12:40] replace windows with others, to avoid OS comparison :P [12:41] lamego: Why? If the change to the network protocol is small enough to warrant SRU (or even -security, in some cases), I don't see how it would be dead. [12:42] persia, the network changes may not be small, and usually depends on other game features = new upstream release [12:43] anyway, this was just an example on for several cases, SRU may be a limitation, from an user's perspective, I clearly understand it's purpose from a QA perspective, specially if you are aiming enterprise [12:43] lamego: Right. If it's too big for SRU, we use a backport, and integrate for the next release. [12:43] lamego: The important point is that *both* SRU and backport should be available, to reach all audiences. [12:43] persia, you could do it, but it is not being done, on a proper published form, it is not reaching the users [12:44] lamego: Right. We need advertising and testing. Wanna help? [12:45] persia, I am doing it already, at the cost of the things that you get from backports, like working first on the dev release, do you want to help :) ? [12:45] are the packages listed on http://people.ubuntu.com/~ubuntu-archive/pending-sru.html#universe the ones that need more testing? [12:45] /m/msg Hobbsee around still? [12:45] doh.. [12:45] luk_: Quite possibly. I hadn't seen that page previously. [12:46] luk_: They could well be. I'm not sure how often that gets updated, and it doesn't reflect things that were rejected, but haven't been pulled from -proposed. [12:46] I have to go, bye [12:48] persia, and don't get me wrong, I hope backports get into shape, there is a lot to be done on Ubuntu, it getdeb becomes irrelevant, next :) [12:48] lamego: Actually, I'm fairly poor at packaging new software: I'm not sure I'd be a good candidate. [12:49] I have seen there are some blueprints for Hardy which aim to improve Ubuntu's software distribution [12:50] lamego: I'm not sure I agree that getdeb should become irrelevant. You've built a really nice UI, and a strong mirror system. I'd just like to see more integration. Specifically, 1) getting all the new stuff in getdeb into the repos & policy compliant, 2) making sure there is infrastructure to support security for getdeb, and 3) sharing resources with backports. [12:50] This release of the ATI Catalyst™ Linux driver introduces the following new features: [12:51] # Support for Accelerated Indirect Rendering (AIGLX) [12:51] wowww [12:51] finally [12:51] :) [12:51] persia, the problem is just one, lack of time and resources, but yes, we are working on it: https://wiki.ubuntu.com/GetDebPlan [12:52] deadwill: that was 2 weeks ago O_o [12:53] hellboy195, heh, i only see that right now [12:53] persia: why are rejected items still mentioned is that a bug in that page or are rejeced packages still in -proposed? [12:53] lamego: I like to see that. I'd encourage you to look at pushing all the stuff not in Ubuntu into REVU (multidistrotools might help), and pulling from backports where possible to leverage those efforts. [12:54] deadwill: ^^. another 2 weeks and the new one arrives ;) [12:54] luk_: Proposed generally doesn't get cleaned out. Rejected stuff is generally not in *-proposed, but often stuff that's already been published is. [12:54] hello All. Can someone please tell me why I get this error during a pdebuild. I suppose I have libxft-dev and the necessary dev packages mentioned int he control file http://pastebin.ubuntu.com/1569/ [12:55] the control file is pasted here http://pastebin.ubuntu.com/1570/ [12:56] luk_: As ScottK said, but also that removal from -proposed requires archive-admin attention, which is not always as available as we might want :) [12:57] (and people forget to file removal bugs to ask for the attention) [12:57] hmm that feels like home (read Debian) :-) [12:58] luk_: Yep. For any distro, only so many people can actually have that level of access, or it all breaks down. Unfortunately, there's not enough of them (and a fair number seem to be shared between us) [13:01] somebody aroud? === fernando2 is now known as fernando [13:02] persia, we use a different approach for reviewing, http://wiki.getdeb.net/Automated_Build_System for the building, and launchpad bug records for the reviewing process communication [13:02] Hi any MOTU's doing review on the REVU server today? [13:02] tuxmaniac: Sorry. Too many things at once. I'm not sure of the specifics, but it looks like a library split. Look for a libxext (or similar) library. [13:03] persia, no problem [13:03] :) [13:03] StevenHarperUK: Yes, but you're unlikely to have easycrypt reviewed. Your last request was < 15 hours ago, and the previous < 8 before that. Please request less often, or wait for a REVU day. [13:03] tuxmaniac: i wonder if you actually need libxft* itself - not the dev package [13:03] persia: yeh I asked 2 times yesterday as the channel was so quiet [13:04] persia: this is my once only request today [13:04] persia: thanks for checking thou :p [13:04] StevenHarperUK: Check irc.ubuntu.com :) [13:06] StevenHarperUK: Also, to be fair, I'm in a different timezone than you, so my day doesn't match yours : [13:06] ) [13:07] persia: I am sure my persistence will pay off, I am trying to contribute [13:07] lamego: I think that's a great model, and likely results in good packages. I was really just hoping to see that once you'd accepted something, if it wasn't in the archive, it also went to REVU so it could be included. [13:08] StevenHarperUK: You just showed up at a bad point in the release cycle. It'll pick up in the next week or two. [13:08] need to go now, I hope to continue this conversation other day :) [13:08] StevenHarperUK: Your contribution is appreciated. However we impose the 1/24hr rule (which sometimes means less than once a local day) in order to keep from being inundated with requests. Persistence is good, but so is patience. [13:09] lamego: OK. I'm really interested in coordination (although I can't help with that stuff much), so please ping me anytime to continue. [13:09] ok :) [13:10] Ok waiting...... [13:10] hey jono [13:12] StevenHarperUK: Thanks. Personally, I think the package is getting in much better shape, and that it may well likely get approved in the next REVU day (as long as you don't bump into the "too many requests" rule) :) [13:12] hey zul [13:12] Although asking more often (after you've fixed stuff) during a REVU day is generally OK. [13:13] persia:its only improved because of how helpful you motu guys are. [13:13] Ah. Yes. ScottK has a point. During REVU day, anyone with an updated package should ask for each update. [13:16] Is it Nov the 5th : the next one? [13:16] If that's Monday, then yes. [13:17] Ace I can't wait. [13:20] how can I tell if my package has been imported from debian? :) [13:21] porthose: rmadison vs rmadison -u ubuntu does a good job. [13:21] porthose: You could also check http://people.ubuntu.org.au/~fujitsu/motuscience/versions/universe.html [13:22] persia: thanks [13:28] can anyone tell me why I can tab-complete a kernel-patch-openvz package but when I try to 'show' or install there is no such package available. [13:28] How can I get in touch with the person who built GIMP for Gutsy? [13:29] Zelut: What does apt-cache search kernel-patch-openvz report? That might have a hint. [13:30] MarcC: You can't: everything was built automatically. What would you ask them if I had a different answer (perhaps we can help) [13:30] persia: I get this: vzctl - server virtualization solution - control tools [13:30] weellll...actually I thought that GIMP wasn't correctly finding the number of CPUs on a system [13:31] but now it turns out the upgrade to Gutsy lost one of my cores :-/ [13:31] persia: and if I 'show' on that package I see this in the long description: [13:31] OBSERVE! You need a Linux kernel patched with openvz support. You can use the package kernel-patch-openvz to build your custom Linux kernel. [13:31] ...since GKrellm and Java both report 1 processor now too [13:33] MarcC: That sounds more like a kernel issue or a BIOS issue (or possibly a hardware issue, although I doubt it). Were I you, I'd report a bug. [13:33] MarcC: You probably want #ubuntu for support. [13:33] thanks persia [13:34] ScottK: I asked there but honestly, it's too crowded, my question got lost I think. But I know this is not a support channel. [13:35] MarcC: If a CPU is missing, then it's likely kernel. If you want to hang out on a relevant development channel, that'd be #ubuntu-kernel, but I'd suggest spending some quailty time with Google before asking there. [13:35] Thanks ScottK [13:38] it turns out that menu.lst for GRUB got changed so that the correct Kernel is no longer default. Thanks for the help. [13:38] No problem. [13:39] Zelut: My apologies: I'm not finding the LP page I want. It's somewhere around https://launchpad.net/ubuntu/+source/vzctl/. There should be information about binary packages; I suspect the control file needs a patch. If you can fix it, please submit the fix. [13:45] Zelut: the kernel-patch-openvz not included in Ubuntu (like other kernel-patch packages) as it won't apply on the Ubuntu kernel and Ubuntu doesn't want to maintain those patches that they work with the Ubuntu kernel [13:46] Zelut: you are better getting the sources from upstream [13:47] especially for openvz [13:47] persia: as the openvz isn't in the Ubuntu kernel (I haven't checked if it is or not) should we still ship such tools in hardy? [13:47] or wait for hardy [13:48] i think there is a bof for that doday at UDS [13:48] geser: I think the confusing thing is that tab-complete finds a kernel-patch-openvz package, yet nothing is there. [13:49] Zelut: I guess it's because it is mentioned in Suggests for vzctl [13:50] geser: Hrm. That's an interesting question. In some ways, I'm in favor of shipping foo-source, so that users can compile it against the kernel headers if they wish, but we should at least make the documentation clear. [13:50] or they should be removed from universe [13:52] zul: That's the other possibility. It depends on the view of universe. Do we provide everything else, or a useful set of software? If the latter, what is our inclusion policy? [13:53] persia: kernel-patch-* are different from foo-source as the first is a kernel patch (you need to build your own kernel) and the second is only a kernel-module (the kernel-headers should be enough) [13:53] kernel-patch-* are already on the sync blacklist [13:54] geser: Ah. Right. In that case, I'd argue for the removal of foo-tools where it requires kernel-patch-foo, based on the guideline that everything should be useful. [13:54] (of course, if there is a foo-source for modules, I argue for inclusion) [13:56] no, then they would break everytime the kernel ABI changes [13:57] zul: Right, but the kernel ABI almost never changes for a real release. [13:59] persia: it somtimes does, there were a couple of times during the dapper release cycle [13:59] Heya gang [14:00] persia: the ipw2200 sources should be removed as well [14:00] Hi bddebian [14:00] zul: Were any of those prior to Edgy release? I'd think that LTS users who relied on module sources could be trusted to recompile. Alternately, making a better hook for the automatic module tools might be nice. [14:00] persia: yes in dapper [14:01] zul: I completely agree with that. The mainline support for .24 is much better. I've been waiting for the official results of the kernel-team decision on .23 vs. .24 [14:01] zul: Ah. That's not desireable. Better tools are needed, I guess. [14:01] its going to be .24 most likely [14:02] zul: Has that been confirmed? I thought the security team was still in hot debate. [14:04] persia: i think 2.6.24 is being rebased now by the kernel team [14:05] zul: So fast? I'm glad to hear it, but it definitely highlights how hard it is to follow things from the other side of the globe :) [14:06] zul: If yuou can confirm that, please file a removal bug for ipw2200 [14:06] sure [14:08] zul: Thanks. [14:08] Heya geser [14:30] siretart: I see still some references in https://wiki.ubuntu.com/MOTU/Merging to motu-tools and multidistrotools. They are obsolete now right? [14:35] norsetto: we still have some mdt setups but the mdt page is outdated [14:36] geser: right [14:36] * persia notes that http://people.ubuntu.org.au/~fujitsu/motuscience/versions/universe.html is being updated hourly by a cron job. [14:38] what's DIF, I guess a Freeze, but which kind? [14:39] Debian Import Freeze [14:39] no auto-syncing of Debian packages anymore (only on request) === effraie_ is now known as effraie [14:43] norsetto: sorry, no idea right now [14:44] siretart: ok, thx [14:51] norsetto: motu-tools is replaced by ubuntu-dev-tools. multidistrotools is active, but not packaged. See the URL I posted a bit back. [14:54] persia: Right. What would be the alternative to lpbugs.py then, if any? === apachelogger_ is now known as apachelogger [14:55] norsetto: thekorn made a really nice python program, with optional GUI. Unfortunately, while he told me the name, I've forgotten, and haven't found it. If you can't catch thekorn, dholbach might remember the name. [14:55] persia: ok, I remember using some tools from thekorn too [14:56] norsetto: If you find it, please let me know. I really want to be using it for hardy, but... [15:07] persia: so when will you file a backport for gnome-hearts? [15:07] you'll have to do the testing for it, too [15:08] Hobbsee: Backport? Is there no SRU option? It completely fails, so there's little downside risk (not that I'm a good judge of SRU stuff). [15:09] persia: pitti bought off on a new upstream version of Azureus due to not working at all, so it seems reasonable. [15:09] for SRU [15:10] ScottK: That's what I was thinking. Essentially, due to differences between Debian and Ubuntu gnome-games and gnome-cards, gnome-hearts in gutsy is broken. Hobbsee fixed it for hardy by pulling a new upstream and patching it wildly, but someone with a better SRU idea than I should review for gutsy. [15:11] * persia 's one and only SRU attempt, fixing a FTBFS + fail to run for feisty was rejected because it apparently didn't work despite local testing. [15:11] bummer [15:12] persia: new upstream version. might do a sru. [15:12] persia: well, no, i pulled the debian version, adn pulled the troublesome patches. [15:12] because they looked useful [15:13] old code got mostly rewritten anyway - looks like debian's redone most of their packaging - adn they only had 2 patches anyway [15:13] (originally) [15:13] Hobbsee: Thank you. The "crashes fro crack" bit is flipped on my worksttion, so things that work for me don't always seem to work for others, and I usually crash every few hours until the first dev kernel release for each new official stable release. [15:14] Hobbsee: s/adn/and/ or are you talking about the IRC nick 'adn'? [15:14] luk_: no, it's the fact that i cant type for shit, especially after 2am :P [15:16] !ohmy | Hobbsee [15:16] Hobbsee: Please watch your language and topic, and keep this channel family friendly. [15:17] hehehe [15:17] * ScottK moves to the other side of the room from LaserJock [15:17] LaserJock: as i kept saying to our oscilloscope on monday, "die". [15:17] :P [15:17] * persia decides that November 2nd should start later... [15:18] to saying that, not for you yourself to die off [15:18] perthe comments referred to the old version, btw [15:18] bah === _czessi is now known as Czessi [15:35] hey LaserJock, hi! [16:16] hmm, I thought DaD was going away? [16:20] LaserJock: After perhaps MoM provides equiavlent functionality. [16:21] That part hasn't got done yet. [16:22] hmm [16:22] hopefully that gets done soon === bear42 is now known as bear [16:22] it's really no fun looking at multiple places :/ [16:23] LaserJock: Unfortunately we are dependent on Canonical people to decide to pay attention to it. They haven't yet. [16:23] ScottK: do you know if anybody has submitted a patch or anything? [16:23] Personally, I don't think comments are *that* useful. [16:23] LaserJock: How could they? No one has the MoM source. [16:24] StevenK: I agree, but I don't want people getting mad at me cause I didn't look at DaD [16:24] ScottK: I thought there was an agreement about that [16:24] * StevenK doesn;t. [16:24] (Look at DaD, that is) [16:24] LaserJock: There was discussion. AFAIK, no source actually got provided, but Adri2000 or Lutin would know better. [16:24] k [16:24] we should wrap that up as a part of the MOTU process review [16:25] * ScottK tends to look at DaD (it updates more frequently anyway) and then use whichever proposed merge seems cleaner. [16:26] I just can't ever remember the URL for DaD so I go with MoM [16:26] LaserJock: ^^^ /topic [16:26] DaD's got a pretty slick look though [16:27] yeah, well, with irssi I don't really see topics [16:27] Ah. [16:27] but yeah, that's true [16:27] If I actually understood the color coding scheme on MoM, I might be more likely to look there. [16:28] yeah, I've never understood it, but it doesn't matter to me [16:28] I just merge stuff with my name on it then start looking for other things to do [16:28] Speaking of which ... [16:28] fernando: How goes courier? [16:31] ScottK: http://www.nerdgroup.org/fernando/files/courier_0.57.0-1ubuntu1.debdiff [16:34] fernando: Why did you add Depends openssl to courier-pop-ssl? [16:36] fernando: Or is that a previously existing difference that you've just documented? [16:40] fernando: Looks pretty good. Would you please file a merge request bug, attach that to the bug, and subscribe UUS? [16:55] anyone here knows the differences between the light and dark green packages in MoM? [16:58] norsetto: i was told that the colours were something to do with priority. [16:58] TheMuso_Boston: ok, so light lower and dark higher I assume !? [17:02] norsetto: I don't know. [17:02] TheMuso_Boston: np, thanks :-) [17:04] You guys may want to check https://wiki.ubuntu.com/MOTU/Merging; I have made extensive modifications and tried to bring it up to date with current tools and practices [17:04] hmmm, better link here https://wiki.ubuntu.com/MOTU/Merging [18:14] norsetto: I made some minor adjustments on the merges page. It looks pretty good. [18:14] ScottK: thx, I think that was really needed. [18:16] The one change I made that is probably significant is the bit about filing bugs if you are working on a merge. If you are the previous uploader, I don't think it's needed and I don't recall any MOTU meeting where it was agreed to. [18:18] scottK: ah, well, in my mind that page is for new contributors, I assume MOTU know how to merge [18:19] Hi, I would like to have a merge upload reviewed, is there a pointer to documentation about getting a review I can read? [18:19] norsetto: Right, but I don't want anyone to assume that the lack of a bug means it's a free for all. [18:19] james_w: https://wiki.ubuntu.com/MOTU/Merging covers this. [18:20] ScottK: ok, let me check then, perhaps I misunderstood you [18:20] ScottK: did you have already time to look for a motu that decided on gimp (we talked about it yesterday). If not I could also search for one by me own ;) [18:24] scottK; well, contributors anyhow have to file the bug even if they were the previous uploaders [18:25] hellboy195: No. Gimp is in Main, so it would have been a core-dev, not a MOTU. [18:26] norsetto: Agreed, it's just a question of making sure lack of a bug isn't thought to be meaningful. [18:26] ScottK: I mean the decision to put it NOT into updates but in backports [18:27] hellboy195: Once again, not a MOTU, core-dev because the package is in Main. No. [18:27] doko: what are we gonna do in Ubuntu to get swt-gtk v3.3? I'm looking to sync Azureus 3.0.3.4 from Debian for Hardy and need swt-gtk 3.3 to continue (not high priority) [18:28] ScottK: ok than I have to look for a core-dev. thx anyway [18:28] Why would we put a new gimp into -updates? [18:28] What is wrong with rc3 that justifies it? [18:28] hellboy195: ^^^ [18:28] thanks ScottK. [18:28] If you say version number, that is *not* justification. [18:28] james_w: You're welcome. [18:28] the number is higher so it must be good [18:28] jdong: build eclipse? [18:29] * StevenK kicks zul [18:29] StevenK: ehehe.. [18:29] ScottK: !? [18:30] StevenK: oooh...shiney.. [18:30] doko: :( is that going to be nontrivial? [18:30] hellboy195: Look at what StevenK said just above my highlighting you and you'll have your GIMP conversation started. [18:31] ScottK: A thx. I only focused on you [18:31] doko: why don't we use separate source packages for swt-gtk like what Debian does? [18:31] StevenK: 2.4 final isn a new version. final is FINAL and I think everbody prefers a final and not a RC [18:32] * norsetto relax and watch the show [18:32] hellboy195: Which is version number. And not justification. === neversfelde_ is now known as neversfelde [18:32] jdong: Building eclipse is impossible with < 1GB RAM. 1GB RAM will get it done in ~18 hours due to disk thrashing. More memory gets it done a lot faster. [18:32] scottk, jdong: confrmed :-( [18:32] StevenK: that mean the RC3 is the same then the final? [18:32] that sounds a bit silly to me.... why don't we split out swt-gtk into its own source package [18:32] like how Debian's been doing it [18:33] jdong: because the "swt-gtk like" packages don't work for eclipse [18:33] hellboy195: I'm not certain, which isn't the point. My point is we won't put a new upstream release into -updates. [18:34] doko: ok, so it will cause trouble when we upgrade eclipse to 3.3? [18:34] in the "Ubuntu QA for hardy" thread it was mentioned that the archive should be linda & lintian clean. How strong do we want this? I'm doing a merge now and have the choice to sync or introduce new changes to fix lintian warnings. [18:36] StevenK: from RC3 to final is a new upstream version???? shouldn't ubuntu be stable and RC IS unstable to take it exact and final not. besides that already a bugfixrelease of gimp has been released [18:36] How is the RC unstable? [18:36] jdong: you need to package it. your next challange ;) [18:36] heh [18:36] Just because the version jumped from 2.4.0~rc3 to 2.4.0 means nothing. [18:37] hellboy195: If you haven't looked, you need to look at the actuall bugs (if any) that were fixed to see if they are important. [18:37] how is rc3 not stable? [18:37] StevenK: partially. but most times bugs from rc3 are fixed in the final [18:37] doko: would it be a bad idea to do what Debian does, ship libswt3.2-gtk for Eclipse that comes from Eclipse and libswt-gtk-3.{2,3} for other apps that use SWT? [18:37] hellboy195: maybe if you provided a diff between releases that suggested some fixes.. [18:37] hellboy195: Fine. I need examples, Launchpad bugs and *justification* [18:38] StevenK: the most justification is that final looks more stable and better than rc3 ;) [18:38] That isn't justification. [18:38] jdong: yes, if you do include the osgi bits [18:38] looks more stable [18:38] That's conjecture [18:39] jdong: and no, the debian packaging is insane, as man-di told you as well [18:39] hellboy195: I'd suggest get some specific details and come back to speak with StevenK later. He can probably fix it for you if he's convinced. [18:39] doko: got it, you don't think Debian packaging is done right :) [18:39] hellboy195: aside from vague gimp developer assurances that final means stable, is there any proof that final is MORE stable than the rc in Ubuntu? [18:39] ScottK: ok, I think I understand what you are aiming at now. I'm just afraid that this could confuse new contributors in the unlikely case they have already worked on the previous case. [18:40] jdong: are you going to visit us anytime soon? :D [18:40] jdong: the debian packaging for swt-gtk (and azureus); btw, you did want to re-add the missing patches, didnt you? [18:40] pwnguin: ScottK StevenK : well guys I didn't want to grumble or things like that. Sry for that. I was just wondering [18:40] joejaxx: probably Friday [18:40] hellboy195: If there's a real justification for it, fine, but just it's a later release, isn't that. [18:40] jdong: oh ok :D [18:41] doko: I have good reason from upstream to conclude that the native tabbingtheming patches are in part responsible for its instability in Ubuntu [18:41] ScottK: well 2.2 to 2.4 isn't the same like a 2.4RC3 to 2.4 [18:41] hellboy195: If there is proof, MOTU can consider that. but it just looks like an obsessive compulsive need to have the latest [18:41] doko: so I don't really see the sense in adding them back in when without them Azureus works perfectly fine [18:42] "good reason" is a vapour statement [18:42] hellboy195: but without specific evidence, you're risking the current package quality for the reward of fixing nothing [18:42] hellboy195: Agreed, but to make any change at all to a release requires technical justification. [18:42] 2.4.0~rc3 to 2.4.0 is still a new upstream release [18:42] Both are distinct releases. [18:43] pwnguin: ScottK okthx [18:43] hellboy195: like world nuclear politics, the best course of action in upstream release engineering is "trust, but verify" [18:43] StevenK: ok. and what about the the bugfixrelease 2.4.1? [18:43] doko: an Azureus developer in #azureus the other day said that Debian, Ubuntu, and Fedora apply patches to swt theming that causes SWT to segfault.... [18:43] actually, i take back what i said about MOTU considering it. i meant core-devel [18:43] doko: I am just taking their word for it... [18:44] MOTU aren't allowed to accidentally break something as important as GIMP. [18:44] jdong: nevermind, I'll restore them after uds [18:44] hellboy195: Once again, look at the specific changes and see if there's something critical. [18:44] pwnguin: GIMP is in Main, so we can't upload it anyway. It happens StevenK is also core-dev. [18:45] Don't dob me in. :-P [18:45] ScottK: http://developer.gimp.org/NEWS-2.4 some minor but also things like fixed another crash with broken plug-ins (bug #490617) [18:45] hellboy195: alternatively, you could just build it yourself, or use launchpad PPAs if you think others might want it [18:46] doko: well it'll probably be irrelevant as we get 3.0.3.4 into Hardy... it seems like Mandriva has a pretty decent collection of patches for icedtea built Azureus 3.x.x.x; for now I just want working and noncrashing packages for SRU to Gutsy [18:46] pwnguin: getdeb.net ;) hmm no. I was just curious [18:46] doko: if the native theming patches are important to you, I can try applying them and asking the testers to give it a shot [18:46] hellboy195: I'm trying to help you understand what needs to be done. Please don't confuse that with me caring deeply about the issue. It might be useful to find the patch for the crash fix and maybe put that in an SRU. [18:47] The dh_iconcache man page says "This script is going to go away." Is there an alternative to use, or just drop the invocation? Or maybe, is this information correct? [18:47] james_w: dh_icons [18:47] ////////////win 2222226 [18:47] StevenK: thanks. [18:47] gah [18:48] ScottK: hm I'm new to that things and I also thought that the newest is always the best. Used to long windows ^^ [18:48] james_w: dh_iconcache was Ubuntu only - dh_icons is available in both Debian and Ubuntu, so if we have to put it in, suggest it to the Debian maintainer. [18:48] hellboy195: It's a critical difference. We try to make sure stuff works and then keep that exact thing until the next release except for critical fixes. [18:49] ScottK: yeah windows and debian sid confused me ;) [18:50] if you just want the latest and greatest at all costs, debian sid provides in most cases [18:51] StevenK: Have you got a moment for some library advice? [18:51] pwnguin: yeah but I tried it and I don't like sid. too buggy for me. Only Ubuntu rulez ^^ [18:52] ScottK: Surely a library is close by. :-P [18:52] hellboy195: if you want the latest and greatest then you would be running something like hardy [18:52] StevenK: I merged https://launchpad.net/ubuntu/+source/dkim-milter/2.0.2.dfsg-1ubuntu1 which now provides a separate lib package, which (I now see) has a conflict: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440577 - It's not sorted out in Debian. Should I make the two libraries conflict? [18:52] Debian bug 440577 in dkim-milter "libdkim-dev: Package namespace conflict" [Serious,Open] [18:53] ScottK: Give me a moment === davromaniak is now known as Mi === Mi is now known as davromaniak [18:54] hellboy195: ubuntu's quality comes at the price of careful consideration. developers have to weigh the risks of regressions and new bugs in new code against value of improvements. [18:54] zul: yeah the thing is that hardy is too unstable for me the first stages. and second also hardy will have a package freeze and is outdated very fast. but trust me. mostly I'm satisfied with ubuntu [18:54] StevenK: Thanks. Researching further, I see there is a version in New that fixes it http://ftp-master.debian.org/~ajt/new/dkim-milter_2.3.2.dfsg-1_i386.html [18:55] StevenK: Looks like I can just wait on the ftpmaster and it'll get cleared up. [18:55] pwnguin: I always thought. New version = new bugs, old bugs fixed, new features --> 2:1 for an upgrade [18:55] hellboy195: Plus also thinkos and regressions sometimes added too. That's the worry. [18:56] hellboy195: the best ive seen in practice is to steal the patches from the new version that fix code, and skip on the new features that come with new bugs [18:56] pwnguin: oh. but new features are cool too ^^ [18:56] ScottK: yeah I understand [18:59] hellboy195: you also need to check if all packages using libgimp2.0 still work [19:02] geser: but whatabout a autosync to debian gimp with manuell editing? [19:02] hellboy195: if packages had more automated tests, pushing those kinds of changes might go faster, but that spec isn't implemented yet [19:02] pwnguin: ok [19:11] ScottK: Hard. [19:11] ScottK: And I don't want to step on people's toes. [19:11] StevenK: OK. I'll wait and see what happens when the new version gets out of NEW. We have time. [19:11] StevenK: Thanks for looking. [19:18] Where should I put the debdiff once I'm done with the merge? [19:20] anybody know who is responsible for the kde4 beta packages? [19:21] Jazzva: just like normal sponsoring, open a bug (if none exists), attach the debdiff and subscribe ubuntu-universe-sponsors [19:21] geser: Thanks :) [19:31] 3~/c [19:32] * ScottK waits for the ugh... [19:35] heh [19:35] I didn't notice I did that till just now. [19:39] Hello [19:40] I am using tar to make backups , but I wonder if there is an option to prevent TAR to backup twice the same file if I give it as an entry [19:41] like I want to backup /dir, exclude /dir/foo and include dir/foo/toto [19:41] I am ending with /dir/foo/toto twice [19:43] wattazoum: Sounds like you ought to be in #ubuntu for support. [19:44] well, as it's in fact for development :-) I am developping a backup software that uses TAR [19:44] ScottK, I thought it would be a nice place to ask [19:45] wattazoum: If someone wants to answer, sure, but this channel is more about devloping Ubuntu than stuff that might go in Ubuntu at some point. [19:46] ScottK, Ah, oki , thank you [19:47] does somebody know if adding -fno-stack-protector is really the right fix for bug #155522? [19:47] Launchpad bug 155522 in etoken "[patch] unknown symbol in libetoken binaries" [Undecided,New] https://launchpad.net/bugs/155522 [19:49] one hopes not [19:50] good morning [19:51] Hi ajmitch [19:52] geser: it tends to be the fix of choice for such issues [19:54] geser: only way to find out is to test yourself [19:54] hey ajmitch [19:54] I think the issue is not whether it works, but whether it's the best thing to do === impec is now known as erable [19:56] hola, anyone know when we'd likely see a package for gimp2.4.1 out? obviously 2.4.1 was updated last night but I'm just curious about the lag time things usually take? [19:56] zul: I have no such token to test it. I just wanted to ACK the sync for hardy and checked if there are any other bugs which could get fixed. [19:56] AWW FEW [19:56] FER, even [19:56] StevenK: here, have a beer [19:57] later.. [19:57] I think I need something stronger [19:57] geser: https://wiki.ubuntu.com/GccSsp [19:58] it's pretty much assumed that you should use that flag to turn off the changed gcc behaviour [20:00] ok good thanks [20:03] ajmitch: thanks, will do a "merge" for etoken instead of a sync [20:06] quick question, when an md5 in our repos doesn't match an md5 from debian, we should request a "fake sync" correct? [20:06] just makin' sure this hasn't changed since..umm. dapper I think was the last time I ran across this [20:08] geser: you got some time to check the ddclient debdiff? [20:09] Kmos: not yet [20:09] ok [20:10] nixternal: yeah, and they can't really be requested :) [20:18] https://edge.launchpad.net/ubuntu/+source/xdx [20:18] http://packages.qa.debian.org/x/xdx/news/20071021T173203Z.html [20:18] i think this one can be synced [20:18] what motu members think ? [20:19] ajmitch: speaking of fake-syncs, could you sponsor bug #157672? [20:19] Launchpad bug 157672 in sqlite "[Fake sync] sqlite 2.8.17-4build1" [Undecided,New] https://launchpad.net/bugs/157672 [20:21] Kmos: if it builds in a hardy chroot, you can file a sync request [20:21] or a hardy pbuilder [20:22] geser: ok [20:27] geser: 1.5MB debdiff? seriuosly? [20:27] thats a big debdiff. [20:27] ssh is so very lagged today, someone must be downloading [20:28] ajmitch: from diffstat: configure |28157 ++++++++++++++++++++--------------------- [20:28] yes, I just saw that [20:29] the other are <= 500 changes [20:29] but can you please just provide the sane debdiff against debian? [20:29] sure, if you prefer that [20:30] * ajmitch may be able to do something with it then [20:31] ajmitch: http://launchpadlibrarian.net/10242659/ubuntu-changes-only.debdiff === Lure_ is now known as Lure [20:41] * ajmitch needs to get a proper hardy build setup working [20:42] Did anyone in here here s.th. from \sh in the last two weeks? (by chance) [20:44] pkern: I think I last talked to him right before the Gutsy release. [20:44] pkern: IIRC he was about to go on vacation. [20:45] ScottK: How much time has passed since Gutsy's release? One and a half weeks? [20:45] Two I think. [20:45] Yes. Two weeks. [20:46] Ah it's Thu. [20:46] pkern: How come Gobby flashes at me from the task bar every time ANYTHING happens no matter how trivial? [20:46] pkern: Is it configurable somewhere? [20:46] ScottK: Because users wanted exactly that. [20:46] ScottK: It wants to make sure you're aware. [20:46] Because Gobby is crap === TheMuso_1oston is now known as TheMuso_Boston [20:47] * ScottK wonders if StevenK knows who the Gobby upstream is ... [20:47] them's fighting words, better not let upstream here them [20:47] Probably he does. [20:47] s/here/hear/ [20:47] I don't, actually [20:47] ScottK: Don't know, no env to check :-P [20:47] pkern: It'd be nice (please consider this a feature request) to be able to configure it. [20:47] ScottK: Maybe I implemented that when somebody poked me. [20:47] pkern: Poke [20:48] I'm on a stupid OS X box. ;) [20:48] Hard time... [20:48] As long as it's fixed before the next UDS I go to, I'll be happy. [20:48] It's trivial. [20:49] pkern: Please for Hardy.... [20:49] As said it's trivial. [20:50] Which is not quite the same thing as saying you'll do it. [20:50] you could dive into the code, ScottK [20:50] m_btn_urgency_hint( [20:50] _("Highlight the window on incoming chat messages") ) [20:50] It's already configurable? Or is the urgency hint set on document modifications? [20:51] set on modifications, iirc [20:51] (Appearance FWIW) [20:51] Will it was flashing on people joining and leaving. [20:51] it's been awhile since I've used it [20:51] * ScottK looks [20:51] ScottK: That's a chat message \: [20:52] If it was actual content it wouldn't be annoying, but at UDS, people join/leave about every 5 seconds so it just flashes all the time. === adanoszombie is now known as adanos [20:52] ScottK: If you open a ticket about that I'll fix it. [20:52] pkern: Where? [20:52] ScottK: gobby.0x539.de [20:53] * ScottK looks [20:53] pkern: you mean you don't use launchpad for bugs? :) [20:53] ajmitch: Correct. [20:53] ajmitch: Launchpad is vendor lockin. [20:53] ajmitch: Just Rosetta. [20:53] shocking [20:57] pkern: Filed - http://gobby.0x539.de/trac/ticket/320 [21:01] ScottK: Thanks. [21:01] pkern: Thank you. It's a useful tool, but that just drove me nuts. [21:02] ScottK: Then turn it off, the option's there. ;) [21:02] We did not use it at huge "parties" so even simple joins were interesting for us. [21:02] (i.e. rejoins after disconnection) [21:04] afternoon all [21:04] pkern: Well I found it this time now that I know it exists. When I was at UDS going nuts, I didn't see the option. [21:05] * tonyyarusso is more than a bit annoyed that LP is _still_ closed source [21:06] * ScottK is more annoyed about it being frustrating to use, but that too. [21:06] their roadmap for open sourcing it has always been 5+ years, so _still_ might not be a good term [21:07] man, the day it goes open [21:07] imbrandon: How said "still"? [21:07] i'll have to start triple checking updates for hax [21:08] pwnguin: uh, why? :) [21:08] imbrandon: They want to provide software as a service, so they won't open source it. [21:08] Affero GPL ftw [21:08] pkern, sure they will , it IS in thier roadmap, just not soon [21:09] meh. it either happens or it doesn't [21:09] plans are like excuses [21:09] everyone has one [21:10] * pkern looks at Debian's plans... [21:10] I see world domination there! :-P [21:11] imbrandon: Have you seen this roadmap? [21:11] imbrandon: I am very wary of Canonical. [21:11] pkern: Why? [21:11] ScottK, sure, lemme find the text quoted [21:11] pkern, why? [21:12] * ScottK isn't 'very wary', but does keep in mind that they are a profit making institution and can reasonably be expected to behave a such. [21:13] As such entities go, they are better than most (recent changes in the PPA ToS as evidence for that). [21:13] When you see the profit point you are fine. Working for Canonical for a living is fine. [21:13] There are good sides and no so good sides. [21:13] But, as they should be, they are out to separate organizations from their wallets. So it pays to be careful. [21:13] ScottK, here is one snipit, i know there is more i need to dig a bit deeper [21:13] https://help.launchpad.net/FAQ#head-34295746b9c12bbe42eee4a9bd5e2656306fd796 [21:14] One of the good sides is you have a bunch of people that are paid to make Ubuntu rock, and help with community stuff, and generally be available. [21:14] Agreed. [21:14] * pwnguin has no idea how / if canonical makes money [21:14] I may outline my points somewhere in the near future. I had some strong feelings about two weeks ago, but lost track the last two weeks having not been in touch with Ubuntu at all. [21:14] imbrandon: I've seen that, but don't particularly buy it. [21:15] pwnguin, they make money in much the same way redhat does, through service contracts [21:15] * persia suggests that everything we use today in LP will become open source in a few years, and that launchpad itself will be much larger at that point. [21:15] I've also seen sabdfl say it'll be Free when it's successful. [21:15] ScottK, not beleaving something and it not being stated is very diffrent [21:15] that can't be enough to cover costs [21:15] Personally, I don't see it being successful unless it is Free. [21:15] pwnguin, sabdlf has stated a few times it dosent , and dosent expect it to for 7 to 10 years === superm1__ is now known as superm1 [21:15] There are some paths Canonical persues to get Ubuntu in markets to earn s.th. [21:15] no doubt [21:16] pwnguin: It's currently in market acquisition phase. Wait for progress on our first bug, and the strategy will show [21:16] imbrandon: That's a corporate statement of intent, not necessarily their actual roadmap. I doubt anyone outside Canonical and it's contractors have seen the roadmap. [21:16] heh [21:16] ScottK, its already successfull, if you mean "everyone is happy aobut it" that will never happen [21:16] how do I go about requesting an initial mentor? [21:16] imbrandon: No, it's not. How many Linux distros not downstream from Ubuntu use it? [21:17] ScottK, it dosent matter when ubuntu's install base is 9 million plus, i consider that successfull [21:17] o_O [21:17] imbrandon: I think he may have been talking about LP? [21:17] imbrandon: Ubuntu yes, but we are talking about Launchpad. Different product with different success criteria. [21:18] when LP has a large enough user base, there's little incentive for people to setup their private copies [21:18] ScottK, somewhat but not really , LP success greatly dependsw on Ubuntu's success [21:18] exactly ajmitch and thats when it will be opened [21:18] ajmitch: I want to get information into LP and *out of LP* in a sensible way. [21:18] pkern: and there are concrete plans to improve that a lot in the next few months [21:18] pkern: +1 [21:18] Some companies realize that opening up their service get them more users then keeping it closed. See gmail with IMAP. [21:19] Many kudos to Google for that. Now I actually recommend this service. [21:19] also see how long ti toook gmail to implment imap [21:19] imbrandon: Correct. [21:19] imbrandon: im not quite sure how canonical could ever plan to spend 250 dollars even fixing just one bug at a profit... [21:20] so i fail to see a "problem" also if you have digged a big LP caode can be worked on by community members [21:20] even now [21:20] pwnguin, huh ? i totaly missed your point there [21:21] the majority of people with support contracts will have them for multiple installs, and will have few problems [21:21] they're paying for the availability of canonical to fix problems should they arise [21:22] support is an insurance plan so you don't get fired, essentially [21:22] all companies pay for it because that's the culture [21:22] at least as they're written now, canonical's contracts don't appear to stop me from buying after ive found a problem [21:23] right, but that would be the minority of contracts, i'd say [21:23] but i guess that's their problem [21:23] pwnguin, but how many do you see actualy doign that ? and canonical is prepared to take that risk too saying hey wont turn a profit for 7 to 10 years [21:24] they* [21:24] imbrandon: i see a lot more people doing that than choosing to buy support up front... [21:24] the people who buy support up front don't necessarily talk about it :) [21:24] it's just what they do [21:24] companies buy support not people [21:25] exactly [21:25] and companies have unlimited money (well not unlimited but they are more than willing to pay large sums of money) [21:25] hell, ive considered spending 250 dollars to see what canonical will throw at a bug ;) [21:25] pwnguin: In that case you've not been involved in vendor approval cycles for large firms. Given that it can take 6+ months to get approval to pay a new vendor, it's lots easier to just pay for support at the beginning, as otherwise it's painful. [21:25] if you have a number of critcal servers running ubuntu, you're not going to wait for a problem & then spend time getting a contract signed [21:25] look how much they pay for all the windows boxen....especially servers [21:26] they buy windows server, sql server, connection licenses, etc, ends up costing at least 10k per server when all is said and done, plus they pay per year for support [21:26] (typically) [21:26] pwnguin, sure but your not canonicals main customer or target, IBM , Yellow Freight, Applebies , home depot , etc are [21:27] if you have the problem so do they [21:27] how much is canonical charging for support? [21:27] the contracts ive seen are 250 dollars per year [21:27] a single server iirc is 250 a year [21:27] that's really cheap [21:27] and is it good support or what? [21:27] I thought servers were more [21:27] yea [21:27] and desktops? [21:27] ajmitch, servers might be more, i know it starts at 250 [21:28] there are differing levels of support, including response times [21:28] noolness, 24x7 phone and developer support [21:28] ah [21:28] is one [21:28] http://www.ubuntu.com/support/paid [21:28] paid support is probably one of the key things that people need in order to support linux in the enterprise [21:29] not bad although the desktop prices are quite high, depending on the situation [21:29] ahhh 3k per year for server 24x7 [21:29] i guess they took down their sample contracts [21:29] the server pricing isn't bad though, i would pay that (i mean if i was at a company) [21:30] lamalex: why do you think you need a mentor? [21:31] i bet you can work out a deal with them though if you just want the support sticker on a bunch of desktops, ie volume licensing [21:31] heh [21:31] since the amount of support calls they would get would be dramatically less [21:31] at least on the contracts i saw [21:31] unlimited seats [21:31] right, I'd expect that for ubuntu [21:32] the whole point of this is Canoncial makes its money on those, not LP, it never inteneded to make money via LP closed source its keeping it closed source untill suffcent mass is built up using it so as not to make 1000000 LP clones on the net [21:32] oh you just pay 250 bucks for desktop support period? [21:32] heh [21:32] for a year [21:32] 900 if you want "24x7" [21:32] so wait that is total support, i could have 1000 desktops and 10 servers? [21:33] noolness: keep in mind there's also limits on the number of tickets filed [21:33] pwnguin: yeah i know...but still that is pretty cheap [21:33] noolness: It is also support bandwidth. If you pay more, you can speak to more people at the same time, and more people in total. [21:33] actually amazingly cheap [21:34] noolness: which is in part why i sort of imagine this being not very profitable... [21:34] pwnguin: yeah i agree [21:34] and i don't think trying to make money with launchpad is good either... [21:34] that's that thing from linspire right? [21:35] (or am i mixing things up) [21:35] they arent trying with LP [21:35] see my last statement [21:35] ah [21:35] someone on #fluxbuntu claimed they didnt pay for souyez [21:35] * ajmitch has no ideas what contracts may go on in the background [21:35] pwnguin, why would they pay for souyez ? [21:35] ive never set up an LP project or Distro, so i took them at face value [21:36] imbrandon: i assumed because canonical charged for it? [21:36] well if they are just selling support like on that page...well...i think they will have problems making enough money to support the project [21:36] pwnguin, no [21:36] but...i am sure they know what they are doing [21:36] imbrandon: Instead of pissing off lots of people, why don't they just write code that would allow all Launchpad clones to share information? [21:36] So I can ask Canonical to add a distro for me? [21:36] they have been pretty darn successful so far [21:36] tonyyarusso: 'just' [21:37] tonyyarusso: because it's a rather large task to decentralise all this stuff? [21:37] tonyyarusso, thats a tall order, and in the end i'm sure there will be [21:37] it's better to have one trusted source [21:37] you assume that they're not already working towards that [21:37] True [21:37] pkern, sure, fluxbuntu , xubuntu, ubuntustudio have all done so [21:37] LP is the linspire thing correct? [21:37] no [21:37] no [21:37] launchpad is canonical bug tracking software [21:38] LP -- LaunchPad.net [21:38] I just don't like the double standard of "We promote software that's open and lets you watch or get involved in the development process, but when it's our own we keep it secret." [21:38] Makes no sense. [21:38] oh shoot i was thinking of something completely different hehe [21:38] well, its more than bug tracking. it's software tracking software [21:38] !launchpad [21:38] Launchpad is a collection of development services for Open Source projects. It's Ubuntu's bug tracker, and much more; see https://launchpad.net/ [21:38] i was thinking about that linspire "you have to pay for stuff" package manager [21:38] tonyyarusso, if you listen to what sabdfl has said on the subject it make alot of sense [21:38] click 'n' run [21:38] yes click 'n' run [21:38] imbrandon: I've tried to, but it still rubs me really wrong to say one thing and then do another. [21:39] CC:by-nc-sa is a 'free licence' right? Even with the noncommerical element? [21:39] Daviey: Not for Debian(tm). [21:39] launchpad sounds like they are trying to have a common place where people can barter for work [21:39] pkern: but fine for us? [21:39] afaik, cc-by-sa itself isnt dfsg [21:39] tonyyarusso, LP isnt trying to make money its trying to gain mass [21:39] For multiverse perhaps. [21:39] rwith bounties and such? [21:39] Daviey: -nc- makes it nonfree. [21:39] pwnguin: I thought 3.0 should be? [21:39] imbrandon: I know that. [21:39] persia: hmm.. what should i do? [21:40] pwnguin: (But take it with a grain of salt, I have no clue) [21:40] noolness, bounties failed misserbly [21:40] ah [21:40] nobody did the bounties i bet ;) [21:40] pkern: i also know very little about it :( [21:40] Daviey: non-commercial dooms it to multiverse here. [21:40] no one ponied up money for bounties [21:40] sure they did [21:40] Daviey: It can go to multiverse, or you can coordinate with upstream to see if they would permit it to be sold (essentially, universe ends up on the DVD, which gets sold, so that's commercial) [21:40] noolness: many trivial things were put there, there was no moderation of it [21:40] ScottK: ok thanks [21:40] ah that sucks [21:40] launchpad just sucked promotion and cooperative bounties [21:41] people should have had to pay their money up front [21:41] there'd be a bounty with zero dollars, and people come along and pledge money too [21:41] bounties aren't a particularly easy social problem to solve :) [21:41] and there should have been a minimum amount [21:41] persia: naa.. the author doesn't want it to be non-nc (heh, double negation) [21:41] yeah there are a lot of issues [21:41] Daviey: OK. In that case, we can't put it in universe, as otherwise people couldn't sell DVDs. It would have to be multiverse or nothing. [21:41] it's easier to have a way to find people to do work, and then bargin with them [21:41] the nouveu fund worked out okay [21:42] with bounties it sucks for both sides, because if you don't finish the work fast enough you lose [21:42] as far as the money ponying goes [21:42] siretart: You around? [21:42] persia: ta [21:42] noolness: you could take a darpa grand challenge approach [21:42] pwnguin: I'd suggest the initial bounty requires a committment to pay: otherwise you end up with a bounty for each bug. [21:43] persia: sounds good. minimal committment 5 dollars? [21:43] persia: my beef was just that people would want to fund the bounty extra and LP didn't track that [21:43] i would say more like 50 bucks [21:43] id say 20% of the bountie pledge or similar [21:43] there were initial bounties of 10 that rolled to 150 or more [21:43] pwnguin: I don't have an opinion on minimums: standards of living vary too widely internationally, and I haven't done the research to determine the optimin for bandwith/processing vs. cost of skilled time. [21:45] someone would probably do well to setup a "bounty server" [21:45] there's a few [21:45] with a home brew'd system [21:45] pwnguin: Are any worthwhile? [21:45] imbrandon: Just send me the money. I'll hold it for you. [21:45] ;-) [21:46] it takes a big committment to make something like that work. like aj said, there's social issues [21:46] ScottK, hehe thats the major problem i see with commitments, who holds the cash [21:46] bddebian: yeah, sort of [21:46] you need buyers and sellers [21:46] bddebian: what's up? [21:46] * persia thinks that if ScottK can demonstrate appropriate bonding to act as an escrow agent, he might collect significant interest on the float [21:46] and enough cash to break the chicken / egg problem [21:46] pwnguin: the nouveau fund never 'worked' as such [21:46] escrow and dispute resolution is another problem [21:47] ajmitch: at getting money or getting money _to devleopers_? [21:47] pwnguin: people pledged money, the money has not got to developers [21:47] so it was good at getting people to pledge, at least [21:47] which is non-binding [21:48] Daviey: what are you trying to use> [21:48] it also got a lot more publicity :) [21:48] Burgundavia: a theme/artwork [21:48] siretart: Just wondering what's up with scorched3d. Why it never got uploaded? [21:48] * imbrandon thinks [21:48] Now apparently 41.1 is out [21:49] ajmitch: i simply used nouveau as an example of getting people to front the money. non-binding isn't great, but thats fixable [21:49] Daviey: nc and nd are veyr much non-free. Try and get the artist to relicense [21:49] bddebian: you mean in the games team? [21:49] Burgundavia: tried.. ah well thanks [21:49] Daviey: artists like to use nc and nd without realizing the consequences [21:50] siretart: Aye [21:50] Daviey: I would explain what you want to do with it and why their current license is bad [21:50] bddebian: please ask Fuddl for current status [21:50] Burgundavia: It's a mythtv theme, and the author doesn't want people making mythtv boxes and selling his theme... can't blame him really [21:50] * persia looks forward to a scorched3d sync [21:50] persia: :-) [21:51] bddebian: he should be online right now [21:51] siretart: OK, sorry. Thanks. [21:51] Daviey, i dont blame him either but that shouldent be in the ubuntu repos [21:51] imho [21:51] siretart: I don't think I've ever seen him "talk" in #d-games :-) [21:53] Daviey: create a theme contest [21:53] end result must be cc by sa [21:53] bddebian: I did [21:53] :) [21:53] Daviey: if you really want to get clever, try to convince him to publish it as an Advertisement for his work that mythTV vendors might see and commission him to do a custom theme for them [21:54] Burgundavia: good idea ... but not sure i can be bothered now - might just squeeze it into multiverse [21:55] Daviey: Is there a critical use case? I think we've a few mythtv themes already, and stuffing more in multiverse isn't ideal, considering our goals of providing free software. [21:55] persia: yeah.. want some that look good :) [21:56] persia: but i see your point.. could just provide them in a private repo [21:56] Daviey: you have lots of time until hardy [21:56] Daviey: Ah. That's a good goal. A private repo might work, but I think I'd second the suggestions that better free themes should be sought. [21:56] great time to run such a contest [21:57] :).. thanks [21:57] siretart: I guess no one loves me there either :'( [21:57] unfortunately in this case, the author makes some of the best themes out there. [21:58] is he opposed to the act of working for money? [21:59] you could buy a theme off him, with the understanding that the price includes the license you need [21:59] well he already went the extra mile and relicensed and custom did a theme for us [21:59] (for no charge) [21:59] but he feels strongly upon these other ones that they are nc [22:00] then i woudl say we have no choice but to not distribute them, not when there are tons of free alternatives [22:00] ship a mythbuntu-themes-extras [22:00] in multiverse [22:00] universe and main we can distribute [22:01] we also say others can do the same [22:01] multiverse and restricted we say "you can mirror, but if you want to redistribute, read the license" [22:01] imbrandon, mythtv is already in multiverse, so its not really making that much worse of a situation [22:01] i cant find it now, but im pretty sure in the past the fsf / gnu pages used to say they didnt advocate Free for works of art [22:02] at least in the sense, its no worse than if the theme was shipped directly with the mythtv package [22:03] * siretart gives bddebian a big *HUG* [22:03] Burgundavia, the plan is a source package for each of his themes with a meta package similar to mythbuntu-themes-extras, probably mythtv-themes-nonfree though [22:03] siretart: :-) [22:04] Later folks, heading home [22:05] imbrandon: when you set up dual boot between different releases, where is grub's config stored? [22:06] depends on where the mbr points [22:06] normaly the last installed OS's /boot [22:06] if everthing is default [22:07] e.g. hd(0,0) /boot/grub/menu.lst etc etc etc [22:10] its surprising, but apparently gstreamer doesnt support .s3m [22:11] imbrandon: maybe i should set up a chainloader system. have the mbr chainload to another bootloader for each install [22:11] the amiga format ? [22:12] trackers are bigger than just the amiga [22:12] pwnguin, yea i've often thought about installing a small ~100MB linux base install just for a "cutom boot loader" on hd0,0 [22:12] just never took the time to do it [22:13] imbrandon: nana. you can have grub install to the first sector in the partition [22:13] would be nice for system recovery etc too [22:13] so each install has its own grub.conf to use, and then put one in the MBR that just selects among partitions [22:14] no i mean one that would house the main /boot i use and chainload the rest [22:14] im saying you can do the same thing without the 100mb base linux install [22:14] kinda like a home brewed Norton Boot Manager or similar [22:15] pwnguin, i know you can but i would like trhe flexability of a full linux install for recovery and other tasks too [22:15] ah [22:15] thats what cds are for [22:15] heh [22:15] unless you're use very advanced footrests [22:16] cd's are slow [22:16] but yes, .s3m is a MOD, similar to the amiga stuff [22:17] man i need to stop tinkering and get some merges done, i was just looking at a x86 pxe serving ppc clients [22:22] Kmos: your ddclient merge looks ok [22:28] Hi I was wondering if I could offer a addition to the firehol init.d script? The try option is not available. [22:30] people still use firehol? I thought that had a lot of problems that the author of which didn't have the time to fix? [22:35] heya rob [22:35] hi imbrandon [22:40] * LaserJock waves [22:41] hello LaserJock [22:41] my brain is going to explode [22:41] why so? [22:41] but the good news is my advisor has a dissertation chapter to thrash === bmk789_ is now known as bmk789 [22:42] ajmitch: just met with my advisor, spent a long day with LaTeX [22:43] ah, painful [22:43] I'm glad to hear you're making progress & will be back to ubuntu development shortly ;) [22:43] * Fujitsu waves too. [22:43] heh [22:43] I think I'm gonna have to make another attempt at leaving [22:43] morning Fujitsu [22:43] Soyuz being reliable as usual, I note. [22:43] 4th time lucky? [22:44] Hi ajmitch, LaserJock. [22:44] commiting Ubuntu suicide just isn't that easy [22:44] *committing I think [22:44] * ajmitch hasn't even managed to sever all ties yet [22:45] My announced absence I think lasted like three weeks. [22:45] I just need like a month of no IRC, no email, no Fridge or Planet of forums [22:45] * elkbuntu clings to LaserJock and howls 'NOOOOOOOOoooooooooooooooooooooooooooooooooo'! [22:45] *or [22:45] elkbuntu!!! [22:46] I haven't seen you in a long time [22:46] :D [22:46] See, if even she manages to be here, you can. [22:46] hey elkbuntu :) [22:46] elky was even on IRC with dialup [22:46] LaserJock: only a month? [22:46] * tonyyarusso knows that pain - especially when in #ubuntu-trivia [22:46] LaserJock, yeah well... blame life. tonyyarusso i thought we agreed never to remind me of those weeks :-/ [22:46] elkbuntu: oh, whoops [22:46] ajmitch: a month would be good [22:46] LaserJock: sounds like you need a wire cutter :) [22:47] geser: well you know, that's part of the problem [22:47] I need to have my computer and Internet to work on my dissertation [22:47] so I can't just turn the darn thing off [22:48] well... we could ban you from everywhere :Þ [22:48] elkbuntu: Hahah. [22:48] Good idea. [22:48] well [22:48] Fujitsu, i think the good man might be cluey enough to work around them [22:48] I would rather have self-inflicted banishment [22:49] elkbuntu: you should probably do the same for me [22:50] ajmitch, i should probably do the same for me too. i need to find a goddamn job, and quick [22:50] I'd just end up on OFTC where those .... other people live [22:50] heh [22:50] elkbuntu: I need one soonish too [22:51] it's wonderful being practicaly unemployable [22:51] except when the landlord wants his rent money [22:51] I was scouring every national lab, Department of Defense, and Department of Energy website looking for jobs yesterday [22:51] LaserJock: but you'll be educated! [22:52] Piled Higher and Deeper ;-) [22:52] LaserJock: hehe [22:52] well, time for class... :( [22:53] pffft [22:53] what doesnt help is that i'm determined to keep a promise and talk in brisbane in the last week of this month [22:53] people take classes these days? ;-) [22:53] elkbuntu: that really interferes with starting a job [22:54] ajmitch, yeah, but im not going to miss out on being a plenary speaker for some stupid job [22:54] like dudes, im even on the website front page :-/ http://www.osdc.com.au/index.html [22:55] impressive [22:55] yeah [22:55] now if only that could get you a job in that field [22:56] ajmitch, would be nice :Þ [22:56] it's not a bad idea [22:56] just end your speach with a "I'm currently available for employment, thank you" [22:57] lol [22:57] or you could have a tip jar [22:57] "If you liked my speech please drop $100" [22:57] LaserJock: the problem is food, rent, etc until the talk :) [22:57] * elkbuntu nods at ajmitch [22:57] well, there are ways ... [22:58] luckily i have mum and dad, but the novelty will wear off for them rather quickly [22:58] crash at hobbsee's place? :) [22:58] ajmitch, brisbane is a little further north than hobbsee's place [22:58] oh yeah ... I was thinking something else [22:58] I know [22:58] I've been there before :) [22:58] it involved rifles, ammunitions, and lots and lots of duct tape [22:58] LaserJock, i dont think i wanna know [22:59] i think i thought right :Þ [22:59] he worries me [22:59] I'm from Montana, we know how to "live off the land" ;-) [23:00] yeah, via some methods that aren't entirely legal in other countries [23:00] and by land I mean banks and rich people's kids ;-) [23:00] anyway ... [23:01] spot the desperate student [23:01] now that the NSA is tracking me [23:01] I should maybe get back to the dissertation [23:01] hehe [23:01] and I'd better head off for lunch [23:01] back later [23:16] rob I love firehol, it is still on Freshmeat [23:16] May 20, 2007 FireHOL R5 v1.255 released. [23:17] How do I go about adding a script addition that is what I am looking for, help in helping ;-) [23:20] can someone help me with an error? i'm trying to follow the guide to package gnu helo [23:20] im getting this " dpkg-buildpackage -S -rfakeroot [23:20] parsechangelog/debian: error: unrecognised line, at file debian/changelog line 3 [23:20] dpkg-buildpackage: unable to determine source package is [23:20] " [23:21] lamalex: What is line three of your debian/changelog? [23:21] lamalex: how did you edit changelog? [23:22] g'night gents [23:23] norsetto: vi [23:23] * New upstream release with lots of bug fixes [23:24] lamalex: You should probably use dch - that ensures the format is correct. [23:24] lamalex: Use dch -e to edit an existing changelog entry, or dch -i to create a new one. [23:24] In this case, you've probably left out the indentation. [23:25] i used a tab [23:25] but thanks for the dch tip [23:25] that should be in the tutorial [23:25] lamalex: You need to use two spaces. [23:27] can someone look at http://pastebin.mozilla.org/232753 and give me a hand fixing those errors (i would rather not have to chmod debian/rules (using ubuntus fakeroot version gives same errors [23:27] fujitsu: thanks [23:27] gnomefreak: Er, debian/rules must be executable. [23:28] How did you extract the source package/ [23:28] *? [23:28] Oh, using bzr.. [23:29] gnomefreak: If you really don't want it executable (it does have to be for things to work) you can `fakeroot make -f debian/rules sometarget' [23:29] But I don't know why you'd want to do that. [23:29] /usr/bin/fakeroot: 166: debian/rules: Permission denied [23:29] ? [23:29] (sorry if these are super basic questions) [23:29] this is my first attempt at packaging [23:29] lamalex: This is what we're discussing here, actually. [23:29] ah perfect! [23:29] lamalex: You need to make debian/rules executable. [23:29] :) [23:29] so should that go in the make file? [23:30] or be done by hand [23:30] Just chmod it by hand. [23:31] problem is rules file is only 103 lines and no clean target set [23:31] chmod a+x rules? [23:31] i just did +x [23:31] and it worked [23:32] ok ty [23:32] gnomefreak: Yes. [23:32] :) [23:32] ok trying again [23:32] i have never had that before [23:32] thats what i get for packaging for debian :( [23:32] It's the same in Ubuntu... [23:34] damn it did work that was almost too easy [23:34] thank you Fujitsu and lamalex [23:35] iceowl+bzr has taken me 2 days to get to work bzr being 99% of the time [23:35] sad part i already have sunbird for hardy built [23:35] gnomefreak: iceowl... is that Sunbird? [23:35] yep [23:35] are hardy repos open? [23:35] It'll be nice to have that in the repos. [23:36] lamalex: yes [23:36] Fujitsu: sunbird is in gutsy [23:36] 0.5 in gutsy [23:36] 0.7 going into hardy and sid [23:36] is iceowl a free version a la iceweasel? [23:36] Is it? Hah, I've been keeping up to date. [23:36] gnomefreak: when you call dpkg-source -x an.dsc, it does tar xzf .orig.tar.gz, patch it, chmod +x debian/rules [23:36] ah [23:37] the same happens when you use apt-get source package [23:37] lamalex: yes [23:37] very cool [23:37] geser: yeah but i didnt do it that way (that would have been too easy) [23:38] !info sunbird gutsy [23:38] sunbird: Sunbird stand-alone Calendar. In component universe, is optional. Version 0.5-0ubuntu4 (gutsy), package size 7506 kB, installed size 22304 kB [23:38] since upstream killed seamonkey calendar we needed a cal app so me and asac got sunbird ready [23:39] gnomefreak: it's good to know such things when you need to do a fake-sync and dpkg-source complains that the md5sum of the .orig.tar.gz doesn't match [23:39] true [23:39] damn why would i think my job was done [23:39] hi [23:40] Hi proppy. [23:41] bleh.patch is quilt? [23:41] or can be almost anything [23:46] If I'm preparing a merge/sync from Debian and if the only thing that needs to be kept from Ubuntu's package is the maintainer field, should I report it as a sync? [23:46] Jazzva: That would be a sync, yes. [23:46] Hi TheMuso_Boston. [23:47] Ok. Thanks, Fujitsu... [23:49] Hey Fujitsu [23:53] thanks for your help :) [23:53] just finished my first package build [23:53] lamalex: What are you packaging? [23:56] just following the gnu hello howto in the ubuntu docs [23:57] Ah. [23:57] yeah [23:57] want to learn packaging