[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:20] <jdong> 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
[00:36] <ScottK-laptop> jdong: Sure thing.  Look at what clamav we released Intrepid with and what it has now ...
[00:36]  * jdong nods
[00:36] <jdong> 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] <jdong> the latter definition of "unnecessary" is probably 'it fixes some obscure bug I don't understand yet'
[00:37] <ScottK-laptop> fixes/causes, but sure.
[00:37] <ScottK-laptop> It is VLC after all.
[00:38] <jdong> meh I don't expect VLC users to find little bugs here and there to be a surprise anyway :)
[00:39] <jdong> or a security problem every other week...
[00:39] <jdong> 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] <jmarsden> 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] <ScottK-laptop> jmarsden: Try rmadison argus-server
[01:18] <jmarsden> Ah... OK.  Thanks.
[01:18] <ScottK-laptop> 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] <jmarsden> OK.  There's no way to search on partial package names (other than apt-cache search) ?
[01:23]  * jdong curses skype
[01:23] <jdong> [   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] <jdong> please don't touch that....
[01:23] <jdong> [   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] <jdong> or that either.
[01:23] <jdong> 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] <emgent> someone know in what package is Gtk.pm ?
[03:01] <emgent> ah found.
[03:04] <jdong> emgent: as a long-time contributor it's probably in your interest to keep apt-file around and updated on your machine :)
[03:04] <emgent> jdong: yeah found it
[03:05] <emgent> but my perl script was a little issue
[03:05] <emgent> heheh
[03:05] <emgent> now i found it. and i fixed perl script too.
[03:07] <kees> 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] <jdong> kees: do we have a set of packaging conventions yet how to or if to use upstart event files?
[03:08] <jdong> I'd like to see more upstart work done :)
[03:08] <jdong> *pokes UDS people*
[03:09] <kees> jdong: all i have is examples from Keybuk's blog.  :P
[03:10] <jdong> haha :)
[03:10] <jdong> that's a bit out of date-ish too :)
[03:11] <jdong> the job format AFAIK is due to change soon-ish
[03:11] <jdong> hence why I wanted to know what's the big-picture roadmap for adopting Upstart
[03:11] <kees> me too.  :P
[03:11] <kees> I'll ask him at UDS
[03:11] <jdong> awesomeness
[03:11] <jdong> blame it on me if necessary, I just want to see more Upstart in jaunty!
[03:12] <kees> hehe
[03:54] <ScottK> kees: Interesting idea.
[11:30] <zerwas> 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] <laga> it's usually not OK
[11:33] <laga> AFAIK :)
[11:34] <zerwas> 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] <RainCT> zerwas: how often are there updates?
[11:36] <zerwas> hm, depends. in the last time 3 times a week, sometimes a few weeks without updates
[11:37] <tombee> How would I go about actually getting involved with development?  I've read the wiki about MOTU :)
[11:37] <zerwas> it's still Freenet 0.7 though
[11:38] <laga> zerwas: and how is getting the .deb initially "anonymous"?
[11:39] <zerwas> it isn't, that's the problem
[11:39] <RainCT> tombee: look for a bug and fix it :)
[11:40] <tombee> RainCT: I'm really a beginner to development :P looking to learn
[11:41] <tombee> 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] <RainCT> tombee: do you want to contribute with packaging or coding?
[11:42] <tombee> Ideally coding, but I'm not sure my skills would be immediatly up to scratch.
[11:43] <RainCT> 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] <tombee> Hehe I see ok :) Was just pointed in this direction with the 'beginning to get involved', thanks anyway :)
[11:45] <zerwas> laga> so, what do you suggest in which way i should build the package?
[11:46] <laga> zerwas: well, how is the problem "i can't download the package anonymously" different from " i can't update the package anonymously"?
[11:49] <zerwas> 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] <laga> zerwas: yeah. maybe you can get a standing exception
[11:53] <zerwas> that would be nice. i haven't found a better solution up to now
[11:56] <laga> i'd suggest asking on the MOTU mailing list, explaining the problem etc.
[11:57] <zerwas> okay. am i allowed to write on this ml without being a MOTU myself?
[11:57] <laga> yes, but you need to subscribe AFAIK
[11:57] <laga> if you don't subscribe, your mails will be moderated
[11:58] <laga> i think ;)
[11:58] <zerwas> k. thank you very much for your help so far :)
[12:02] <anakron> Hi ALL
[12:02] <anakron> Hi RainCT
[12:02] <RainCT> hi :)
[12:02] <anakron> :) i found another one
[12:02] <RainCT> yeah, I've seen
[12:05] <anakron> i have one question
[12:05] <anakron> a tool called nss-updatedb is designed to work with libpam-ldap and libnss-ldap
[12:06] <anakron> but they dont appear in suggests or depends
[12:06] <anakron> and it cant work fine without these libs
[12:06] <anakron> so, i want to make a patch for it :) changing dependencies+
[12:06] <anakron> can you help me?
[12:07] <RainCT> 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] <anakron> ok :)
[12:28] <anakron> RainCT, I can
[13:21] <DRebellion> Are there plans to backport lintian 2.0.1 from jaunty-> intrepid? Currently intrepid is using 2.0.0.
[13:57] <DRebellion> Sorry, I meant to say that the jaunty version of lintian is 2.1.0, not 2.0.1
[13:58] <pmjdebruijn> lo
[13:58] <pmjdebruijn> 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] <pmjdebruijn> how should I handle this?
[13:59] <RainCT> pmjdebruijn: include it in debian/copyright
[13:59] <azeem> you'll have to quote the whole license in debian/copyright then
[13:59] <pmjdebruijn> verbatim?
[13:59] <RainCT> yes
[13:59] <pmjdebruijn> hmmm
[13:59] <pmjdebruijn> isn't it about time CC licenses got included in common-licenses?
[14:01] <ScottK-laptop> 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] <pmjdebruijn> ok
[14:36] <DRebellion> 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] <sebner> DRebellion: np, changes look good so far, in the evening I'll do a second review and then maybe advocate it
[14:45] <pmjdebruijn> hmmm, pbuilder included with intrepid, doesn't do jaunty...
[15:00] <DRebellion> pmjdebruijn, enable intrepid-backports
[15:01] <pmjdebruijn> DRebellion: I just did
[15:02] <DRebellion> pmjdebruijn, and it works now?
[15:03] <pmjdebruijn> oh wait, I need to update debootstrap as well
[15:03] <DRebellion> pmjdebruijn, yep
[15:04] <pmjdebruijn> it works now
[15:14] <pmjdebruijn> 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] <rjune_> I would say ask him
[15:58] <lidaobing> help review iptux 0.4.2-0ubuntu1(new package): http://revu.ubuntuwire.com/details.py?upid=4186
[17:16] <fta_uds> hi
[17:27] <RainCT> hey
[17:27] <RainCT> has UDS already started?
[17:27] <fta_uds> nope
[17:27] <iulian> Tomorrow.
[17:28] <fta> sorry :)
[17:28] <sebner> fta: haha, one day to early :P
[17:28] <RainCT> iulian: I know.. I'm asking for the case there's some timezone weirdness :P
[17:28] <RainCT> fta: heh
[17:28] <fta> that's the one nick for all channels effect ;)
[17:29] <sebner> RainCT: well California is -9h so it's also sunday there :P
[17:31] <StevenK> It's Sunday, 9:30am currently.
[17:31] <StevenK> And California is -0800
[17:31] <RainCT> sebner: ^^
[17:32] <rjune_> fta: is ogra about?
[17:32] <sebner> StevenK: well I'm not from the UK so -9h :P
[17:32] <StevenK> sebner: It's -19h from where I live
[17:33]  * RainCT slaps sebner :P
[17:33] <fta> lol
[17:33] <RainCT> let's agree that it is "Pacific Standard Time (PST) -0800 UTC"
[17:33] <RainCT> :P
[17:33]  * sebner hides
[17:34] <sebner> RainCT: math is calling :P
[17:34] <RainCT> sebner: you can't hide from them, Google is watching you :P
[17:34] <RainCT> meh
[18:45] <sebner> NCommander: aloha, is it allowed to add license headers with a patch(-system)?
[18:45] <NCommander> sebner, w.r.t. to what?
[18:47] <sebner> 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] <JontheEchidna> I wouldn't think so unless they have been added in an upstream svn/git/whatever
[18:47] <NCommander> I would REJECT if I was an archive admin
[18:47] <NCommander> As a rule of thumb, unless there is a technical reason or a file is uncopyrightable, the headers should go in it
[18:47] <sebner> kay
[18:48] <NCommander> If upstream is allowing you to add the headers and will add it in SVN/GIT
[18:48] <NCommander> Repack the source tarball using DFSG, then note the reason iN README.source, and (optionally) in debian/changelog
[18:48] <NCommander> *DFSG versioning
[18:49] <sebner> NCommander: I see, there is a bad boy with no license headers and after my complains (revu) he added them himself -.-
[18:49] <sebner> NCommander: where bad boy = upstream too
[18:49] <Elbrus> 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:50] <Elbrus> it works in debian
[18:50] <Elbrus> (apparently
[18:50] <sebner> Elbrus: NCommander is the FTBFS guy :P
[18:51] <sebner> anyway thx for your help NCommander and JontheEchidna
[18:51] <NCommander> fpc has issues on PowerPC last I saw
[18:52] <Elbrus> NCommander: but it looks like it works for Debian: http://buildd.debian.org/pkg.cgi?pkg=fpc
[18:53] <jdong> Amperage: -854
[18:53] <jdong> now what would it take to mae Linux do that too?
[18:54] <Elbrus> jdong: you can make money that way,
[18:55] <jdong> I am guessing the equivalent Linux solution is get a bigger battery.
[18:55] <NCommander> lol
[18:56] <jdong> 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] <jdong> and that's after I've optimized my Linux setup the best i could; ASPM/ALPM
[18:57] <NCommander> 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] <NCommander> thus the better power usage curve
[18:57] <jdong> disk idling only results in about 0.4W savings here.
[18:57] <jdong> i.e. full spindown
[18:57] <jdong> I boot Ubuntu into casper to RAM
[18:57] <jdong> the disk is spun down 45s into initial boot
[18:58] <jdong> 11.5W wifi on, 11.2W wifi off
[18:58] <jdong> on OS X when I turn wifi off the battery meter jumps into the 6:30 arena
[18:59] <jdong> 22 minute uptime, currently at 92%
[18:59] <jdong> tat's roughly 300 minutes total runtime including the bootup flurry
[18:59] <jdong> so the battery meter isn't lying right now
[19:06] <DRebellion> 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] <DRebellion> I guess I need to build-depends on chrpath as well?
[19:08] <sebner> DRebellion: right =)
[19:08] <DRebellion> sebner, great : )
[19:08] <sebner> 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] <DRebellion> sebner, exactly
[19:09] <DRebellion> so i can't --list them
[19:09] <sebner> DreamThief: list?
[19:09] <DRebellion> 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] <DRebellion> `cifer' probably isn't a 32-bit LSB-first ELF file.
[19:09] <DRebellion> elf_open: Exec format error
[19:10] <sebner> DRebellion: that means it has a rpatch issue, if you run chrpath on an i386 binary it won't complain
[19:10] <DRebellion> sebner, oh right. Ok then.
[19:10] <sebner> DRebellion: and you don't need the --list option :)
[19:12] <DRebellion> sebner, btw, I don't need to check this build with DH_VERBOSE=1 because you already have?
[19:12] <sebner> DRebellion: yes, it was just a side note for the future
[19:13] <DRebellion> sebner, ok, fixed those issues, now building. I'll let you know when its in revu again.
[19:13] <sebner> DRebellion: ok, you maybe again want to upload it to your PPA and recheck the amd64 binary
[19:14] <DRebellion> 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] <bluefoxicy> did somebody pull Quake from the repos?
[19:43] <DRebellion> sebner, ok, the ppa build is published. Downloaded the amd64 deb, extracted, ran chrpath:
[19:43] <DRebellion> simrun@simrun-desktop:~/cifer-amd64/usr/bin$ chrpath cifer
[19:43] <DRebellion> `cifer' probably isn't a 32-bit LSB-first ELF file.
[19:43] <DRebellion> elf_open: Exec format error
[19:43] <DRebellion> are you sure chrpath built for i386 can read amd64 binaries?
[19:57] <Aggro> 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] <Aggro> I'm not afraid of work, just want to make sure before I start working that I'm not doing something stupid ;)
[19:57] <nhandler> Aggro: If it is in Debian, it will get synced into Ubuntu
[19:58] <Aggro> nhandler: I don't need to do anything? It is automated process?
[19:58] <Aggro> nhandler: I am the package maintainer for it in Debian
[19:58] <nhandler> Up until DIF it is automated.
[19:58] <Elbrus> nhandler: DIF= Debian import freeze???
[19:59] <nhandler> Correct Elbrus
[19:59] <nhandler> After that, you have to manually request a sync
[19:59] <Aggro> I made a bug report: https://bugs.launchpad.net/ubuntu/+bug/306042
[19:59] <Aggro> "please sync package cppcheck from debian Unstable"
[20:00] <nhandler> Aggro: When did you upload it in Debian?
[20:00] <Aggro> nhandler: It was accepted to Unstable yesterday I think
[20:00] <Aggro> nhandler: But it has been in the queue for 3 weeks or so
[20:00] <nhandler> Aggro: You don't need a bug report. The package should make its way into Ubuntu within the week
[20:01] <Aggro> I already made a bug report, should I undo it?
[20:01] <Aggro> The wiki page was a bit misleading
[20:01] <Aggro> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[20:01] <nhandler> Aggro: I would just close the bug report. There is no need for it
[20:01] <Aggro> "For packages in Debian, but not in Ubuntu file a bug..."
[20:01] <nhandler> Where is that?
[20:02] <Aggro> nhandler: The url was given in my previous message
[20:02] <nhandler> Aggro: Yeah, the wiki page should probably be modified. I'll change it now
[20:03] <crimsun> Aggro: likely will be synced within the next 72 hours
[20:03] <Aggro> But the progress is automated? All are Debian packages in Ubuntu? I had a feeling that there were less in Ubuntu?
[20:04] <crimsun> Aggro: just about every source from Debian is in Ubuntu.  There are a few that are blacklisted.
[20:04] <crimsun> Aggro: yes, up until DI, the process is automated (and thus the progress, too, I suppose).
[20:04] <Aggro> nice
[20:04] <crimsun> DIF*
[20:06] <Aggro> nhandler: If I close the bug, what status should I set?
[20:06] <nhandler> Aggro: I just updated the wiki page
[20:06] <Aggro> invalid?
[20:06] <DRebellion> 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] <nhandler> Yeah, invalid is fine
[20:06] <Elbrus> when do packages propogate from jaunty-released to jaunty?
[20:07] <Elbrus> s/released/release
[20:07] <geser> jaunty-release?
[20:07] <nhandler> Aggro: Could you take another look at the wiki page and let me know if it is more clear now?
[20:07] <Elbrus> that's where winff is https://launchpad.net/ubuntu/+source/winff
[20:08] <Aggro> nhandler: You might want to clarify when is Debian Import Freeze (DIF), how does the person who is reading that know.
[20:08] <Aggro> E.g. I have no idea when it is
[20:08] <nhandler> Aggro: Good idea. I guess I can link to the Release Schedule for Jaunty
[20:09] <Aggro> nhandler: What about if the person is ready to wait until the freeze is over?
[20:09] <Aggro> nhandler: Then there is no need to submit a bug either?
[20:09] <crimsun> Elbrus: that is jaunty proper.
[20:09] <nhandler> Aggro: DIF is in effect until after the official release.
[20:10] <Elbrus> Aggro: right, but then it will take an extra release before it is available
[20:10] <nhandler> If they are willing to wait until the next Ubuntu release, no bug is needed
[20:10] <geser> Elbrus: I don't know if "release" has any meaning there
[20:10] <Elbrus> http://packages.ubuntu.com/search?keywords=winff doesn't show anything...
[20:10] <geser> Elbrus: winff is in DEPWAIT: https://launchpad.net/ubuntu/jaunty/+source/winff/+builds
[20:10] <Elbrus> aha.
[20:11] <sebner> 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] <sebner> hi geser =
[20:11] <sebner> =)
[20:11] <geser> Hi sebner
[20:11] <geser> Elbrus: and the successfull builds are in the NEW queue
[20:11] <Elbrus> geser: you mean everything except  i386 and amd64?
[20:12] <geser> yes
[20:12] <DRebellion> sebner, hmm, that's strange... anyway i've fixed all the issues it seems then.
[20:12] <Elbrus> lazarus-ide doesn't (or shouldnot) exist on ppc
[20:12] <geser> if winff exist only i386 and amd64 you just need to wait till it gets NEWed
[20:12] <nhandler> Aggro: The page now mentions when DIF is for jaunty
[20:13] <Elbrus> geser: well, it will build on all systems (I hope) where lazarus-ide builds... (Arch is any)
[20:14] <Aggro> nhandler: Should the timeline (week)? be added there also?
[20:14] <Aggro> nhandler: How long it should take before it is not normal
[20:14] <nhandler> Aggro: I don't think the week will mean anything to most people
[20:15] <nhandler> I think a date is fine
[20:15] <nhandler> If they really care about it, they can click on the link to the release schedule
[20:15] <Aggro> nhandler: I mean the "it should be there within 1 week"
[20:16] <nhandler> Aggro: The one week thing isn't exact. It could be less/more than a week.
[20:17] <Aggro> nhandler: So it is not a cron script? ;)
[20:17] <Aggro> But it should be obvious enough not to fool me as it is now
[20:17] <nhandler> Aggro: It might be a cron script, I honestly cannot remember how they handle the automated syncs.
[20:18] <Aggro> 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] <nhandler> geser: Any idea when you will be able to review my application?
[20:18] <nhandler> Aggro: You are welcome. Glad to have helped
[23:35] <jdong> siretart: what are your opinions on simply copying VLC 0.9.8a into intrepid-security?
[23:36] <jdong> I've only briefly looked at the diff and it doesn't look too bad
[23:53] <RAOF> Hm.  Thinking of SRUs.  Any motu-sru's around?  It'd be nice to have some guidance on bug #287332
[23:55]  * jdong looks
[23:57] <jdong> jeez
[23:57] <jdong> gonna need a moment to ponder this one :)
[23:57] <RAOF> 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] <jdong> primary rdepends seem to be Beagle and Tasque?
[23:58] <RAOF> And gnome-do-plugins, and one other.
[23:59] <RAOF> gfax, that's it.
[23:59] <jdong> mmmkay and have we tested whether or not those things migrate properly, like build against the new evo-sharp?
[23:59] <RAOF> Not yet, actually.  I'll do that now.
[23:59] <jdong> I see beagle and tasque tested
[23:59] <jdong> Pedro seems to have done those
[23:59] <RAOF> Nifty.  I'll do gnome-do-plugins.
[23:59] <jdong> if the other two work, I'll be positive on the idea :)