[00:19] * jdong would like to point motu-sru and those interested in SRU's in general to read pitti's comment: https://bugs.edge.launchpad.net/ubuntu/+source/transmission/+bug/295040/comments/14 [00:19] Launchpad bug 295040 in transmission "multiple download works strangely" [High,Fix released] [00:20] I agree with the message wholeheartedly; it doesn't matter if something's called 1.34-0ubuntu1.1 or 1.35-0ubuntu0.1.... it's all about what it does and how it fits with the goals of SRUs === Elbrus is now known as Guest52612 === paul__ is now known as Elbrus [00:36] jdong: Sure thing. Look at what clamav we released Intrepid with and what it has now ... [00:36] * jdong nods [00:36] I'd like to do the same thing for VLC, but am wading through quite a bit of unnecessary or "unnecessary" packaging changes since 0..9.4 [00:37] the latter definition of "unnecessary" is probably 'it fixes some obscure bug I don't understand yet' [00:37] fixes/causes, but sure. [00:37] It is VLC after all. [00:38] meh I don't expect VLC users to find little bugs here and there to be a surprise anyway :) [00:39] or a security problem every other week... [00:39] so far thank goodness -fstack-protector has simply kept the bugs down to DoS annoyances. [00:40] <__iron> hi [00:40] <__iron> just a question to mailinglist [00:43] <__iron> is it desired to introduce himself on mailinglist ? [01:16] What is the rationale for there being an application that has source packages in Universe, but apparently no binary packages according to rmadison? Is this "normal"? (I'm looking at argus ) [01:17] * ScottK-laptop looks [01:18] jmarsden: Try rmadison argus-server [01:18] Ah... OK. Thanks. [01:18] The rationale is rmadison only looks up the package name you give it. If the binary is named differently, it doesn't show up. [01:20] OK. There's no way to search on partial package names (other than apt-cache search) ? [01:23] * jdong curses skype [01:23] [ 81.368501] type=1503 audit(1228608776.425:11): operation="inode_permission" requested_mask="::r" denied_mask="::r" fsuid=1000 name="/sys/devices/system/cpu/" pid=6648 profile="/usr/bin/skype" [01:23] please don't touch that.... [01:23] [ 81.780716] type=1503 audit(1228608776.834:12): operation="inode_permission" requested_mask="r::" denied_mask="r::" fsuid=1000 name="/home/jdong/Private/.mozilla/" pid=6653 profile="/usr/bin/skype" [01:23] or that either. [01:23] fortunately, it doesn't crash when I don't let it figure out what kind of CPU I have, my /proc/net/dev list, or my Mozilla profiles. [03:00] someone know in what package is Gtk.pm ? [03:01] ah found. [03:04] emgent: as a long-time contributor it's probably in your interest to keep apt-file around and updated on your machine :) [03:04] jdong: yeah found it [03:05] but my perl script was a little issue [03:05] heheh [03:05] now i found it. and i fixed perl script too. [03:07] ScottK-laptop: I wonder if we could package clamav in ubuntu to take advantage of upstart so that clamd-killing-DoS vulns just cause it to restart? [03:08] kees: do we have a set of packaging conventions yet how to or if to use upstart event files? [03:08] I'd like to see more upstart work done :) [03:08] *pokes UDS people* [03:09] jdong: all i have is examples from Keybuk's blog. :P [03:10] haha :) [03:10] that's a bit out of date-ish too :) [03:11] the job format AFAIK is due to change soon-ish [03:11] hence why I wanted to know what's the big-picture roadmap for adopting Upstart [03:11] me too. :P [03:11] I'll ask him at UDS [03:11] awesomeness [03:11] blame it on me if necessary, I just want to see more Upstart in jaunty! [03:12] hehe [03:54] kees: Interesting idea. === _Nicke_ is now known as Nicke [11:30] I don't know if this is the right place for my question - i will try it: Would it be O.K. to have a package of a p2p system (namely http://freenetproject.org ), that has an integrated update system and let it use this update system? [11:33] it's usually not OK [11:33] AFAIK :) [11:34] laga> the problem is that freenet always needs the latest builds to stay usable. and it's an anonymous network so every time a new build would come out, one would have to update through the package management, which is non-anonymous [11:35] zerwas: how often are there updates? [11:36] hm, depends. in the last time 3 times a week, sometimes a few weeks without updates [11:37] How would I go about actually getting involved with development? I've read the wiki about MOTU :) [11:37] it's still Freenet 0.7 though [11:38] zerwas: and how is getting the .deb initially "anonymous"? [11:39] it isn't, that's the problem [11:39] tombee: look for a bug and fix it :) [11:40] RainCT: I'm really a beginner to development :P looking to learn [11:41] Struggling to find an IDE I even like, used vim mostly before, but now my projects are becoming more complex it becomes more difficult to handle the files this way [11:41] tombee: do you want to contribute with packaging or coding? [11:42] Ideally coding, but I'm not sure my skills would be immediatly up to scratch. [11:43] tombee: for coding the best would be to choose a project to which you want to contribute and get involved there. MOTU is about packaging [11:44] Hehe I see ok :) Was just pointed in this direction with the 'beginning to get involved', thanks anyway :) [11:45] laga> so, what do you suggest in which way i should build the package? [11:46] zerwas: well, how is the problem "i can't download the package anonymously" different from " i can't update the package anonymously"? [11:49] laga> what i meant was: if one can see publicly when someone installs new build it might reduce the anonymity. But this problem is only second-tier. a package that would not use the update mechanism would be useless one week after jaunty got released [11:51] zerwas: yeah. maybe you can get a standing exception [11:53] that would be nice. i haven't found a better solution up to now [11:56] i'd suggest asking on the MOTU mailing list, explaining the problem etc. [11:57] okay. am i allowed to write on this ml without being a MOTU myself? [11:57] yes, but you need to subscribe AFAIK [11:57] if you don't subscribe, your mails will be moderated [11:58] i think ;) [11:58] k. thank you very much for your help so far :) [12:02] Hi ALL [12:02] Hi RainCT [12:02] hi :) [12:02] :) i found another one [12:02] yeah, I've seen [12:05] i have one question [12:05] a tool called nss-updatedb is designed to work with libpam-ldap and libnss-ldap [12:06] but they dont appear in suggests or depends [12:06] and it cant work fine without these libs [12:06] so, i want to make a patch for it :) changing dependencies+ [12:06] can you help me? [12:07] anakron: It's pretty much like your first patch. But I'd recommend asking in #ubuntu-server before you touch this (to be sure that the change is appropriate) [12:07] ok :) [12:28] RainCT, I can [13:21] Are there plans to backport lintian 2.0.1 from jaunty-> intrepid? Currently intrepid is using 2.0.0. [13:57] Sorry, I meant to say that the jaunty version of lintian is 2.1.0, not 2.0.1 [13:58] lo [13:58] I'm trying to package something which uses the CC-BY-SA-3 license, but it's not included in /usr/share/common-licenses [13:58] how should I handle this? [13:59] pmjdebruijn: include it in debian/copyright [13:59] you'll have to quote the whole license in debian/copyright then [13:59] verbatim? [13:59] yes [13:59] hmmm [13:59] isn't it about time CC licenses got included in common-licenses? [14:01] pmjdebruijn: No. There isn't a huge amount of software licensed under CC. The only real reason to add stuff is to save significant space in the archive. [14:01] ok === nhandler_ is now known as nhandler [14:36] sebner, Thanks for taking a look at cifer; I've fixed the issues you raised: http://revu.ubuntuwire.com/details.py?package=cifer . [14:38] DRebellion: np, changes look good so far, in the evening I'll do a second review and then maybe advocate it [14:45] hmmm, pbuilder included with intrepid, doesn't do jaunty... === nhandler1 is now known as nhandler [15:00] pmjdebruijn, enable intrepid-backports [15:01] DRebellion: I just did [15:02] pmjdebruijn, and it works now? [15:03] oh wait, I need to update debootstrap as well [15:03] pmjdebruijn, yep [15:04] it works now [15:14] one of the copyright holders of a package I'm trying to make, does not publish his email adres... should I include a link to his "contact page/form" online? [15:23] I would say ask him [15:58] help review iptux 0.4.2-0ubuntu1(new package): http://revu.ubuntuwire.com/details.py?upid=4186 === fta2 is now known as fta_uds [17:16] hi [17:27] hey [17:27] has UDS already started? [17:27] nope [17:27] Tomorrow. === fta_uds is now known as fta [17:28] sorry :) [17:28] fta: haha, one day to early :P [17:28] iulian: I know.. I'm asking for the case there's some timezone weirdness :P [17:28] fta: heh [17:28] that's the one nick for all channels effect ;) [17:29] RainCT: well California is -9h so it's also sunday there :P [17:31] It's Sunday, 9:30am currently. [17:31] And California is -0800 [17:31] sebner: ^^ [17:32] fta: is ogra about? [17:32] StevenK: well I'm not from the UK so -9h :P [17:32] sebner: It's -19h from where I live [17:33] * RainCT slaps sebner :P [17:33] lol [17:33] let's agree that it is "Pacific Standard Time (PST) -0800 UTC" [17:33] :P [17:33] * sebner hides [17:34] RainCT: math is calling :P [17:34] sebner: you can't hide from them, Google is watching you :P [17:34] meh === nhandler_ is now known as nhandler === nhandler_ is now known as nhandler [18:45] NCommander: aloha, is it allowed to add license headers with a patch(-system)? [18:45] sebner, w.r.t. to what? [18:47] NCommander: we don't accept source files with no license headers which means new upstrem release is necessary, I'm wondering if you can work around it with a patch (debian/pathes) which adds the license headers to the source files [18:47] I wouldn't think so unless they have been added in an upstream svn/git/whatever [18:47] I would REJECT if I was an archive admin [18:47] As a rule of thumb, unless there is a technical reason or a file is uncopyrightable, the headers should go in it [18:47] kay [18:48] If upstream is allowing you to add the headers and will add it in SVN/GIT [18:48] Repack the source tarball using DFSG, then note the reason iN README.source, and (optionally) in debian/changelog [18:48] *DFSG versioning [18:49] NCommander: I see, there is a bad boy with no license headers and after my complains (revu) he added them himself -.- [18:49] NCommander: where bad boy = upstream too [18:49] does anybody now documentation about how to do bootstrapping for packaging? I think bug 67544 needs that, and I can look somewhat into that if I find documentation. [18:49] Launchpad bug 67544 in fpc "PPC build of fpc fails" [Undecided,Confirmed] https://launchpad.net/bugs/67544 [18:50] it works in debian [18:50] (apparently [18:50] Elbrus: NCommander is the FTBFS guy :P [18:51] anyway thx for your help NCommander and JontheEchidna [18:51] fpc has issues on PowerPC last I saw [18:52] NCommander: but it looks like it works for Debian: http://buildd.debian.org/pkg.cgi?pkg=fpc [18:53] Amperage: -854 [18:53] now what would it take to mae Linux do that too? [18:54] jdong: you can make money that way, [18:55] I am guessing the equivalent Linux solution is get a bigger battery. [18:55] lol [18:56] AFAIK OS X isn't even a tickless kernel... I'm curious as to how it pulls off more than a 2W improvement compared to Linux [18:56] and that's after I've optimized my Linux setup the best i could; ASPM/ALPM [18:57] jdong, OS X has a lot of the default services disabled to prevent things from paging out and thus it can spin down the HDD [18:57] thus the better power usage curve [18:57] disk idling only results in about 0.4W savings here. [18:57] i.e. full spindown [18:57] I boot Ubuntu into casper to RAM [18:57] the disk is spun down 45s into initial boot [18:58] 11.5W wifi on, 11.2W wifi off [18:58] on OS X when I turn wifi off the battery meter jumps into the 6:30 arena [18:59] 22 minute uptime, currently at 92% [18:59] tat's roughly 300 minutes total runtime including the bootup flurry [18:59] so the battery meter isn't lying right now [19:06] sebner, hi! About the RPATH issue with cifer: neither i or my co-developer are running amd64 machines, so we can't use chrpath to test amd64 binaries from my ppa. Am I right in thinking that a simple call to chrpath like this, << chrpath --delete $(CURDIR)/debian/cifer/usr/bin/cifer >> will get rid of the RPATHs and solve the issue? [19:07] I guess I need to build-depends on chrpath as well? [19:08] DRebellion: right =) [19:08] sebner, great : ) [19:08] DRebellion: you don't need an amd64 machine. you can download the amd64 binary from your ppa, unpack it and when you run chrpath on the binary it'll complain [19:08] sebner, exactly [19:09] so i can't --list them [19:09] DreamThief: list? [19:09] sebner, I downloaded from my ppa, extracted, and ran << chrpath --list ./usr/bin/cifer >>. It said: simrun@simrun-desktop:~/cifer-amd64/usr/bin$ chrpath --list cifer [19:09] `cifer' probably isn't a 32-bit LSB-first ELF file. [19:09] elf_open: Exec format error [19:10] DRebellion: that means it has a rpatch issue, if you run chrpath on an i386 binary it won't complain [19:10] sebner, oh right. Ok then. [19:10] DRebellion: and you don't need the --list option :) [19:12] sebner, btw, I don't need to check this build with DH_VERBOSE=1 because you already have? [19:12] DRebellion: yes, it was just a side note for the future [19:13] sebner, ok, fixed those issues, now building. I'll let you know when its in revu again. [19:13] DRebellion: ok, you maybe again want to upload it to your PPA and recheck the amd64 binary [19:14] sebner, yep, just a slight pain as i'll have to fork into two packages to bump the version number for the ppa :( [19:35] did somebody pull Quake from the repos? [19:43] sebner, ok, the ppa build is published. Downloaded the amd64 deb, extracted, ran chrpath: [19:43] simrun@simrun-desktop:~/cifer-amd64/usr/bin$ chrpath cifer [19:43] `cifer' probably isn't a 32-bit LSB-first ELF file. [19:43] elf_open: Exec format error [19:43] are you sure chrpath built for i386 can read amd64 binaries? [19:57] I got a package in Debian called Cppcheck and I would like to package it for Ubuntu. Is there some easy way to re-using existing work, or do I need to read Ubuntu's manuals about packaging and re-do everything (possibly reusing existing files?) [19:57] I'm not afraid of work, just want to make sure before I start working that I'm not doing something stupid ;) [19:57] Aggro: If it is in Debian, it will get synced into Ubuntu [19:58] nhandler: I don't need to do anything? It is automated process? [19:58] nhandler: I am the package maintainer for it in Debian [19:58] Up until DIF it is automated. [19:58] nhandler: DIF= Debian import freeze??? [19:59] Correct Elbrus [19:59] After that, you have to manually request a sync [19:59] I made a bug report: https://bugs.launchpad.net/ubuntu/+bug/306042 [19:59] Launchpad bug 306042 in ubuntu "please sync package cppcheck from debian Unstable" [Undecided,New] [19:59] "please sync package cppcheck from debian Unstable" [20:00] Aggro: When did you upload it in Debian? [20:00] nhandler: It was accepted to Unstable yesterday I think [20:00] nhandler: But it has been in the queue for 3 weeks or so [20:00] Aggro: You don't need a bug report. The package should make its way into Ubuntu within the week [20:01] I already made a bug report, should I undo it? [20:01] The wiki page was a bit misleading [20:01] https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages [20:01] Aggro: I would just close the bug report. There is no need for it [20:01] "For packages in Debian, but not in Ubuntu file a bug..." [20:01] Where is that? [20:02] nhandler: The url was given in my previous message [20:02] Aggro: Yeah, the wiki page should probably be modified. I'll change it now [20:03] Aggro: likely will be synced within the next 72 hours [20:03] But the progress is automated? All are Debian packages in Ubuntu? I had a feeling that there were less in Ubuntu? [20:04] Aggro: just about every source from Debian is in Ubuntu. There are a few that are blacklisted. [20:04] Aggro: yes, up until DI, the process is automated (and thus the progress, too, I suppose). [20:04] nice [20:04] DIF* [20:06] nhandler: If I close the bug, what status should I set? [20:06] Aggro: I just updated the wiki page [20:06] invalid? [20:06] sebner, i'm going to go ahead and upload the updated package to revu, as i can't test if using chrpath was a success. if there is still a problem, let me know. [20:06] Yeah, invalid is fine [20:06] when do packages propogate from jaunty-released to jaunty? [20:07] s/released/release [20:07] jaunty-release? [20:07] Aggro: Could you take another look at the wiki page and let me know if it is more clear now? [20:07] that's where winff is https://launchpad.net/ubuntu/+source/winff [20:08] nhandler: You might want to clarify when is Debian Import Freeze (DIF), how does the person who is reading that know. [20:08] E.g. I have no idea when it is [20:08] Aggro: Good idea. I guess I can link to the Release Schedule for Jaunty [20:09] nhandler: What about if the person is ready to wait until the freeze is over? [20:09] nhandler: Then there is no need to submit a bug either? [20:09] Elbrus: that is jaunty proper. [20:09] Aggro: DIF is in effect until after the official release. [20:10] Aggro: right, but then it will take an extra release before it is available [20:10] If they are willing to wait until the next Ubuntu release, no bug is needed [20:10] Elbrus: I don't know if "release" has any meaning there [20:10] http://packages.ubuntu.com/search?keywords=winff doesn't show anything... [20:10] Elbrus: winff is in DEPWAIT: https://launchpad.net/ubuntu/jaunty/+source/winff/+builds [20:10] aha. [20:11] DRebellion: ok, and yes I'm sure that chrpath built for i386 can read amd64 binaries though it seems it wasn't sucessful in your case [20:11] hi geser = [20:11] =) [20:11] Hi sebner [20:11] Elbrus: and the successfull builds are in the NEW queue [20:11] geser: you mean everything except i386 and amd64? [20:12] yes [20:12] sebner, hmm, that's strange... anyway i've fixed all the issues it seems then. [20:12] lazarus-ide doesn't (or shouldnot) exist on ppc [20:12] if winff exist only i386 and amd64 you just need to wait till it gets NEWed [20:12] Aggro: The page now mentions when DIF is for jaunty [20:13] geser: well, it will build on all systems (I hope) where lazarus-ide builds... (Arch is any) [20:14] nhandler: Should the timeline (week)? be added there also? [20:14] nhandler: How long it should take before it is not normal [20:14] Aggro: I don't think the week will mean anything to most people [20:15] I think a date is fine [20:15] If they really care about it, they can click on the link to the release schedule [20:15] nhandler: I mean the "it should be there within 1 week" [20:16] Aggro: The one week thing isn't exact. It could be less/more than a week. [20:17] nhandler: So it is not a cron script? ;) [20:17] But it should be obvious enough not to fool me as it is now [20:17] Aggro: It might be a cron script, I honestly cannot remember how they handle the automated syncs. [20:18] nhandler: Thanks for your help, this was much simpler than I thought. I'm glad I didn't start making a package of it again ;) [20:18] geser: Any idea when you will be able to review my application? [20:18] Aggro: You are welcome. Glad to have helped === `Chris is now known as Chris60292 === Chris60292 is now known as `Chris === `Chris is now known as dotCYM [23:35] siretart: what are your opinions on simply copying VLC 0.9.8a into intrepid-security? [23:36] I've only briefly looked at the diff and it doesn't look too bad [23:53] Hm. Thinking of SRUs. Any motu-sru's around? It'd be nice to have some guidance on bug #287332 [23:53] Launchpad bug 287332 in evolution-sharp "beagle-backend-evolution cant find libedataserver-1.2.so.9" [Medium,New] https://launchpad.net/bugs/287332 [23:55] * jdong looks [23:57] jeez [23:57] gonna need a moment to ponder this one :) [23:57] Basically, there are two options: new upstream version, breaking API and ABI, or trying to patch in support for new e-d-s without breaking either. [23:58] primary rdepends seem to be Beagle and Tasque? [23:58] And gnome-do-plugins, and one other. [23:59] gfax, that's it. [23:59] mmmkay and have we tested whether or not those things migrate properly, like build against the new evo-sharp? [23:59] Not yet, actually. I'll do that now. [23:59] I see beagle and tasque tested [23:59] Pedro seems to have done those [23:59] Nifty. I'll do gnome-do-plugins. [23:59] if the other two work, I'll be positive on the idea :)