[01:44] <ScottK> jdong: I just tested installing into an Etch chroot from etch-backports and it pulled dependencies from backports like you would want.
[01:44] <ScottK> So I think replicating the backports.org approach has potential.
[01:46] <coppro> what is that approach?
[01:49] <ScottK> coppro: Pin the backports repo to a lower priority than the main one http://backports.org/dokuwiki/doku.php?id=instructions
[01:50] <coppro> but then you manually have to do that
[01:50] <coppro> for every dependency
[01:52] <ScottK> coppro: That's the thing is you don't.
[01:52] <ScottK> If it can only satisfy the dependency from the lower priority repo, it'll pull it from there.
[01:54] <coppro> oh, I see
[01:54] <coppro> do you need mutt for that?
[01:56] <ScottK> No.  That's just an example.
[01:57] <coppro> oh
[01:57] <coppro> so pinning the backports repo definitely seems good then
[01:59] <ScottK> Seems to me.
[02:13] <jdong> ScottK: yeah I gave it some thought over the night and think that pinning is probably our best bet
[02:13] <ScottK> We mostly need good U/I for it.
[02:13] <jdong> forgive the 2AM grouchy jdong who wanted a more hairy solution that got everything right :)
[02:14] <jdong> maybe at 2AM I should start writing dbus and hal
[02:14] <jdong> oops did I say that aloud?
[02:14] <coppro> yikes, scary netsplit
[02:14] <ScottK> Speaking of which, can you fix it so the print screen key fires up Ksnapshot again?  That's be really cool.
[02:14] <ScottK> jdong: ^^
[02:15] <jdong> ScottK: I'll look into that when I have some time and dig out a keyboard with a printscreen key :)
[02:15] <jdong> wouldn't be surprised if it got mangled by the big xmodmap file of DOOOOOM
[02:15] <ScottK> Dunno.  It worked in KDE3, but not KDE4
[02:35] <superm1> ScottK, jdong, dont use xmodmap to fix the problem... the equivalent to gnome-settings-daemon should just make sure it's listening for the (correct) standard keycode
[02:39]  * wgrant would like to know what that equivalent is.
[02:42] <jdong> superm1: that's my point :)
[02:42] <jdong> superm1: the point is there's no equivalent AFAICT
[02:42] <jdong> QT4 looks *HORRIBLY* broken
[02:42] <jdong> first off, listening to all key events doesn't even capture the brightness keys XFMonBrightness{Up,Down}
[02:42] <jdong> so kubuntu xmodmaps them into XF86Launch4 and XF86Launch5
[02:43] <jdong> which are, oddly enough, QT::Key_Launch6 and QT::KEy_Launch7
[02:43] <jdong> (??)
[02:43] <wgrant> Ha ha ha.
[02:43] <wgrant> KDE loses.
[02:43] <jdong> and you can guess where this road of hackjobs leads :)
[02:43] <wgrant> I'm glad I don't have to care about KDE. g-s-d is bad enough.
[02:43] <jdong> I'm gonna dig into qt4-x11 later this week{end}
[02:43] <jdong> gonna see why on earth this is the case
[02:44] <jdong> fun trivia fact: Converting the hex keysym for XFBrightnessUp using QT4 to a string calls it "Meta+(unicode mystery block)"
[02:44] <jdong> :)
[02:45] <wgrant> Oh good.
[02:45] <jdong> and registering that KeyEvent is as good as registering text message alerts for the Dow Jones going up these days :)
[02:46] <jdong> but it's gotten me intrigued enough that I've gotta fix it :)
[03:02] <pangloss> nhandler: any luck?
[03:02] <nhandler> pangloss: I'll try now. I've been pretty busy today
[03:03] <pangloss> nhandler: no rush if you are busy, I have alot of work to do as well so I wont be doing any ubuntu stuff tonight
[03:11] <jdong> Tip #5999 of bug reporting: Try to collect your thoughts for at least 5 minutes before adding a comment. This isn't twitter.
[03:12] <jdong> watch, now I jinxed it and there'll be stream-of-consciousness bug reporting in edge.launchpad when I wake up tomorrow. Maybe with bzr somehow integrated.
[03:12] <nhandler> Don't you mean identi.ca jdong ;)
[03:13] <jdong> LP needs a "You already opened your mouth within the past hour. Wait before posting again"
[03:15] <ScottK> nhandler: No.  We're talking LP, not Free software.
[03:15] <ScottK> Actually never mind, identi.ca isn't FOSS either.
[03:16] <nhandler> ScottK: I thought identi.ca was meant to be FOSS
[03:16]  * nhandler goes to re-read the info on their site
[03:17] <ScottK> nhandler: Depends on if you think AGPL is a Free license.  I really don't think it is.
[03:17] <jdong> I think the term is Less Unfree (aka AGPL)
[03:17] <jdong> ack ScottK beat me to the punch.
[03:17] <nhandler> jdong: Less Unfree is a good way of putting it.
[03:18] <jdong> or "Free or I'll sue you" :)
[03:18] <ScottK> Personally I'm less likely to base work I'm doing on AGPL than a license that allows modification, but doesn't require redistribution.
[03:27] <wgrant> I hope LP doesn't go AGPL, but sabdfl suggests it will be...
[03:30] <lifeless> I think AGPL makes a lot of sense for service code
[03:31] <wgrant> lifeless: Yes, but many feel it is less than Free.
[03:31] <jdong> it sure sounds like LP is going full-swing in the opposite direction in terms of closedness
[03:31] <lifeless> GPL isn't free
[03:31] <wgrant> It does make sense.
[03:31] <lifeless> GPL is specifically unfree to ensure access to the code transitively across all users
[03:33] <coppro> gpl is free
[03:33] <lifeless> coppro: puhlease. You can't make proprietary forks of GPL code. So there are things you are not free to do.
[03:34] <lifeless> coppro: BSD is more 'free' from this angle, and public domain is maximally free
[03:34] <lifeless> but BSD and public domain don't enforce a ecosystem
[03:34] <lifeless> so they are less useful IMO
[03:34] <wgrant> AGPL might be less bad if it were less ambiguous.
[03:35] <coppro> they are free by the FSF's definition of free
[03:35] <coppro> feel free to take it up with them
[03:35] <wgrant> It doesn't define what degree of interaction with the user is required.
[03:35] <lifeless> coppro: the prelude of the GPL states that they deny certain rights in the greater good
[03:36] <lifeless> coppro: so please don't invoke greater authority that backs up my point!
[03:37] <wgrant> lifeless: Do I need to distribute AGPL source to those users to whom I serve 403s?
[03:38] <coppro> wgrant: I think so
[03:38] <coppro> try #gnu though
[03:38] <lifeless> wgrant: thats a really interesting point
[03:38] <lifeless> wgrant: spirit-wise I would say no, resoundingly.
[03:38] <wgrant> lifeless: But to the letter, I think I'd have to drop all packets from users to whom I didn't want to give source.
[03:38] <lifeless> because permission-denied is for someone thats not a use
[03:38] <lifeless> *user*
[03:39] <wgrant> Even if they couldn't use more than the access-control bit of the webapp.
[03:39] <lifeless> I'm just checking
[03:39] <coppro> but only if the 403 is generated by the webapp I think
[03:39] <coppro> if the 403 isn't served by the app, then you don't
[03:39] <wgrant> Of course.
[03:41] <jdong> your webapp can't generate 403 messages without giving away source? :)
[03:43] <lifeless> "all users interacting with it remotely "
[03:43] <lifeless> if you deny a hacker access, I think they are clearly not a user
[03:43] <lifeless> AGPL v3 section 13
[03:43] <jdong> well now there's a vague/grey definition of "user"
[03:43] <wgrant> I interacted with your authorisation machinery.
[03:43] <wgrant> Give me your code.
[03:43] <coppro> they are interacting with it
[03:44] <lifeless> depends on the definition of user
[03:44] <coppro> wgrant: can you not write authorization code that passes the user on to the GPL code?
[03:44] <jdong> I got past your ACL once. give me your code.
[03:44] <jdong> coppro: isn't that linking a GPL app with an AGPL app?
[03:44] <coppro> jdong: you don't need to link
[03:45] <jdong> coppro: oh come on now you are playing on the definition of link to a strict technical definition
[03:45] <lifeless> anyhow, I think its fine to deny someone access via an ACL and not offer them source; they haven't become a user at that point
[03:45] <lifeless> user isn't defined in the GPL though
[03:45] <jdong> coppro: this is the SAME problem with, saying, popen()'ing to ffmpeg from a proprietary application and saying "I'm not linking to libavcodec"
[03:45] <wgrant> While I agree that something like AGPL makes a lot of sense for LP, I don't think the license is good.
[03:45] <jdong> wgrant: +1
[03:45] <jdong> I like the idea but the implementation looks troublesome
[03:46] <jdong> I support the spirit, but I don't know if I want to adopt the license for a substantial work or not
[03:46] <wgrant> lifeless: What if I release my authorisation machinery under the AGPL?
[03:46] <wgrant> I guess that's not exactly directly interacting with somebody over the network.
[03:46] <coppro> jdong: I would say it's different; the code doesn't even need to interact with each other
[03:46] <coppro> do an HTTP redirect or something
[03:47] <jdong> coppro: your authorization mechanism doens't need to interact at all with the site it's authorizing?
[03:47] <lifeless> wgrant: the phrasing is 'user interacting' not 'machine interacting' or 'human interacting'
[03:47] <jdong> what's your username?
[03:47] <wgrant> coppro: I can only do that once my hypothetical authorisation machinery is executed and tells the user to go away.
[03:47] <wgrant> lifeless: Is 'user' defined anywhere?
[03:47] <coppro> jdong: well, what I'm saying is, is the authorization machinery related to the site
[03:47] <lifeless> wgrant: no
[03:47] <wgrant> Sigh.
[03:47] <lifeless> wgrant: I quoted the entire relevant text
[03:47] <jdong> coppro: what authorization machinery ISN'T related to the site?
[03:47] <coppro> e.g. does the application need to provide auth services, or can they be managed separately
[03:48] <jdong> coppro: the application needs to at least get the user's id or profile from the authorization service.
[03:48] <wgrant> Say I grab a copy of LP, and restrict access to some team, and disable registration.
[03:48] <jdong> coppro: and that would be interacting with it
[03:48] <coppro> you could used a shared database
[03:48] <coppro> which isn't linking
[03:48] <jdong> coppro: that makes no sense.
[03:48] <lifeless> wgrant: arguing that a http request which is 403'd with no other content (than the error page) shown is a 'user interaction' would strongly depend on the rest of the site
[03:48] <coppro> why not?
[03:48] <jdong> coppro: user "foo" authenticates now goes into the site
[03:48] <jdong> coppro: how do I know who he is?
[03:48] <coppro> have the auth code check the DB from the site
[03:49] <coppro> cookie
[03:49] <lifeless> wgrant: if there is any anonymous access, then the 403 discussion is irrelevant, they can get the code from the 'please log in' page
[03:49] <jdong> coppro: how can you set a cookie?
[03:49] <jdong> coppro: now you're abusing cookies like a communications pipe
[03:49] <coppro> of course
[03:49] <jdong> that's really nothing more than circumventing a license.
[03:49] <coppro> yeah, I guess
[03:49] <jdong> and I thought v3 of the GPL was supposed to be designed to be resistant against these silly technicality tricks?
[03:49] <lifeless> wgrant: otherwise, if all interactions until logged in get a 403 challenge, I would argue they are not interacting with it
[03:49] <coppro> wait, wgrant, are you deciding to put a project under AGPL, or trying to use an existing one
[03:49] <lifeless> wgrant: they are trying to *start* interacting
[03:50] <wgrant> lifeless: They are using my authorisation machinery in order to get their 403.
[03:50] <lifeless> btw, I thought we wanted folk to have a valid real name in ubuntu channels
[03:50] <wgrant> lifeless: Only launchpad-beta-testers ever required that, and even that was dropped months ago.
[03:50] <lifeless> wgrant: but they aren't a user at that point;
[03:51] <wgrant> lifeless: How do you know? The license doesn't say.
[03:51] <lifeless> wgrant: I'm arguing a point of view
[03:51] <coppro> wgrant: are we discussing applying AGPL to LP?
[03:51] <coppro> or what?
[03:51] <wgrant> coppro: That's where this started, but I suspect that this is the failings of the AGPL in general.
[03:51] <coppro> wgrant: well, you can always write an exception in
[03:52] <jdong> a point of view is good, the spirit and ideology is good, but I'm not convinced any of these would be helpful if I had to , say, deal with a legal battle regarding the AGPL and my code.
[03:52] <jdong> coppro: then it's no longer AGPL compatible.
[03:52] <ethana2> Greetings all.  I filed a bug on window-picker-applet by Canonical, and the bug was fixed
[03:52] <ethana2> The i386 Canonical build failed however
[03:52] <wgrant> Canonical?
[03:52] <wgrant> What does this have to do with Canonical?
[03:52] <ethana2> I was wondering what I'd have to do to contribute an i386 build of this applet
[03:52] <ethana2> they made it
[03:52] <lifeless> I would seek clarification vis-a-vis authenticated services from the fsf; as far as LP goes, the site has anonymous access, so the entire 403 discussion is irrelevant
[03:52] <jdong> ethana2: no, Ubuntu developers made it
[03:53] <ethana2> it started as part of ubuntu-netbook
[03:53] <jdong> ethana2: and we do not take contributed binary builds
[03:53] <jdong> ethana2: can you link to the failed build, bug, etc?
[03:53] <ethana2> interesting
[03:53] <ethana2> ah, i'll try
[03:53] <wgrant> lifeless: Canonical's Launchpad instance does. My hypothetical one does not.
[03:53] <ethana2> https://edge.launchpad.net/~netbook-remix-team/+archive  shows it near the bottom
[03:53] <ethana2> the red 'x' with 'i386' next to it in blue
[03:53] <coppro> jdong: my general rule when writing a modification would be to allow the exception to be removed, leaving it compatible. But you're right that it doesn't solve the overall problem
[03:54] <ethana2> ok, https://edge.launchpad.net/~netbook-remix-team/+archive/+build/750906
[03:54] <ethana2> https://edge.launchpad.net/%7Enetbook-remix-team/+archive/+build/750906/+files/buildlog_ubuntu-hardy-i386.window-picker-applet_0.4.5_FAILEDTOBUILD.txt.gz
[03:54] <jdong> checking whether build environment is sane... configure: error: newly created file is older than distributed files!
[03:54] <ScottK> me is back.
[03:54] <jdong> err, either timestamps are funky on the file you uploaded, or time is funky on the server.
[03:54] <wgrant> Hi ScottK.
[03:54] <jdong> I would have to guess the former
[03:55] <ethana2> I didn't upload anything
[03:55] <jdong> whoever uploaded it, then
[03:55] <ethana2> Hmm, ok
[03:55] <ScottK> Since AGPL is not DFSG Free, it's non-free.
[03:55] <jdong> considering it built on all other arches....
[03:55] <jdong> ethana2: have you tried asking for them to do a rebuild?
[03:55] <coppro> ScottK: DFSG Free?
[03:55] <jdong> ethana2: whoever has admin acceess to that PPA
[03:55] <ethana2> How do I go about..
[03:55] <ethana2> ok
[03:55] <Hobbsee> or me
[03:55] <ScottK> coppro: Debian Free Software Guidelines.
[03:56] <ethana2> so I file a bug asking for a rebuild of 4.5 for i386 fixing timestamps in some file
[03:56] <coppro> ah
[03:56] <ethana2> ..right?
[03:56] <Hobbsee> ethana2: no, i just cued ti for a rebuild.
[03:56] <wgrant> ethana2: No, that's not right at all. You find a team member, or ask Hobbsee.
[03:56] <jdong> ethana2: well yeah, contact anyone on the netbook-remix-team
[03:56] <jdong> ethana2: they have a button that magically attempts a rebuild
[03:56] <ethana2> ..but unless the time stamps are fixed, it'll just fail again, right?
[03:57] <ethana2> Hobbsee: do packages often fail to build once, but then just work the second time?
[03:57] <wgrant> The Xen instance might have had a bogus timestamp.
[03:57] <wgrant> Er, bogus clock.
[03:57] <jdong> Hobbsee: just curious, so buildd-admins apply to PPAs too?
[03:57] <Hobbsee> jdong: oh yes.
[03:57] <wgrant> Given that the others succeeded.
[03:57] <jdong> ethana2: not *often* but sometimes
[03:57] <jdong> wgrant: could be timing
[03:57] <Hobbsee> ethana2: depends what the build failure is
[03:57] <lifeless> ScottK: how is it not DFSG free?
[03:57] <ethana2> interesting
[03:57] <jdong> wgrant: i.e. clock off by 10 minutes on uploader; build queue time
[03:57] <ScottK> lifeless: It requires redistribution.  Fails the desert island test.
[03:57] <wgrant> jdong: Hmm, indeed.
[03:57] <lifeless> ScottK: no it doesn't
[03:57] <wgrant> ScottK: Nobody is accessing it if I'm on a desert island.
[03:58] <jdong> wgrant: (of course considering how these new tickless kernel things keep time like a clock with a dead battery....)
[03:58] <lifeless> ScottK: it requires distribution to folk that use it only
[03:58] <Hobbsee> holy, <expletive lists>
[03:58] <wgrant> Hobbsee: What?
[03:58] <ethana2> fascinating, thanks, Hobbsee
[03:58] <ethana2> https://edge.launchpad.net/+builds/samarium   I've never seen how this was done before
[03:58] <Hobbsee> oh, there we go, w-p-a has been taken.
[03:59] <wgrant> Hobbsee: Lots of i386 builds?
[03:59] <Hobbsee> wgrant: somehow the buildds have managed to get up to a queue of 858 on i386!
[03:59] <wgrant> langpacks.
[03:59] <wgrant> Lots of langpacks.
[03:59] <Hobbsee> ah, so it is langpacks.  I thought there weren't that many
[03:59] <wgrant> Could be a couple of releases worth, I suppose.
[03:59] <Hobbsee> that's true
[04:00] <wgrant> Wait, but langpack exports aren't meant to be running until 2.1.11, are they?
[04:00] <Hobbsee> i'm used to seeing them at 0, or a very small number
[04:00] <ethana2> oh hey, cody-somerville_ :)
[04:01] <ethana2> .....or not....
[04:01] <lifeless> ScottK: (which is to say it has exactly the same requirements as regular GPL, modified to the more general 'use' made of web services)
[04:01] <gouki> On the License part of debian/copyright, is it OK to point to the license instead of pasting it?
[04:01] <ScottK> lifeless: Not at all.  It forces redistridution.
[04:02] <lifeless> ScottK: ok, lets get details here. Do you mean section 13?
[04:02]  * ScottK has to go look it up.
[04:02] <lifeless> do so
[04:02] <lifeless> http://www.fsf.org/licensing/licenses/agpl-3.0.html
[04:03] <lifeless> remember that the desert island test is (paraphrased) 'can I use this software legally on a desert island with no network to the world'
[04:03] <lifeless> AGPL passes that test
[04:03] <ScottK> Yes.
[04:03] <ScottK> I disagree.
[04:03] <lifeless> how does it fail - give me a use case
[04:03] <ScottK> You can't if you've modified it.
[04:03] <lifeless> I'm on an island with my laptop
[04:04] <lifeless> I have a webapp - 'helloweb' which is GPL
[04:04] <lifeless> on my laptop
[04:04] <lifeless> I change the text it shows, run the app, point ff at 127.0.0.1:8080
[04:05] <lifeless> how am I breaking the AGPL at this point
[04:05] <wgrant> I have to agree with lifeless here.
[04:05] <wgrant> Nobody else is accessing it, so nobody else has the right to get to the code
[04:05] <ScottK> I guess.
[04:05] <lifeless> there is a 'get code' link on that page, if I click that it gives me the live webapp code
[04:05] <lifeless> because thats what the thing is meant to do
[04:06] <lifeless> even if there are other people on the island
[04:06] <lifeless> if they are able to demand access to the code, they must be in network range of me
[04:06] <lifeless> its not *at all* like the brain dead licences that say 'must send changes to authors'
[04:06] <ScottK> You argue it better than mako did when I had this discussion with him.
[04:07]  * ScottK ponders.
[04:07] <lifeless> also note that AGPL makes no difference between edited and unedited code- the get source link has to work for the original author as well as downstream sites
[04:08] <ScottK> True.
[04:08] <coppro> the original author of GPL or AGPL code with no modifications isn't bound by them always
[04:09] <ScottK> coppro: Actually he is bound by AGPL, just not only by AGPL.
[04:09] <lifeless> coppro: once he distributes it kicks in
[04:09] <wgrant> In any version distributed under the AGPL, the AGPL must be followed.
[04:09] <wgrant> He can do whatever he wants with it without the link, but can't distribute it as AGPL.
[04:09] <ScottK> lifeless: OK.  I think it's DFSG in roughly the same way that Firefox's Trademark license is DFSG free.
[04:10] <lifeless> ScottK: hah!. I think its much better than that actually, but unhappy agreement >> disagreement ;)
[04:10] <lifeless> for now though, -> code to write
[04:10] <ScottK> Forcing distribution as it does is allowed, but one really ought not to do it.
[04:10] <lifeless> ScottK: its the moral equivalent of forcing distribution for binaries like 'cat'
[04:11] <ethana2> Anyone have an idea how long it takes new builds to propagate to launchpad librarian and PPAs?
[04:11] <wgrant> ethana2: They're in librarian seconds after they finish, and published in the PPA after no more than 20 minutse.
[04:11] <ethana2> oh, ok, sweet
[04:11] <ethana2> so half an hour and then check-update
[04:12]  * ethana2 hugs .bashrc
[04:12] <ScottK> lifeless: It restricts my ability to make use of my own work.  There's stuff I write and use that I'm unwilling to distribute because it's a special purpose hack.
[04:12] <lifeless> ScottK: so don't permit network access for other people
[04:12] <lifeless> ScottK: and voila, you don't have to distribute
[04:12] <ScottK> Which kind of defeats the point.
[04:12] <lifeless> ScottK: its entirely contingent on other people using the software
[04:13] <lifeless> ScottK: which is *precisely* the point of free software
[04:13] <ScottK> Interact with/Use
[04:13] <coppro> hmm... reading the DFSG, I don't see any obvious conflicts with the AGPL, but I'm not an expert at this
[04:13] <ScottK> which is a fundamental difference.
[04:14] <ScottK> coppro: Upon reflection I think it's OK.
[04:14] <ScottK> Personally I find it very distasteful and would be very unlikely to make any use of AGPL'ed works in a project of mine.
[04:14] <ScottK> I can see where it'd be attractive for LP.
[04:15] <CarlFK> I have been running apt-cacher for years, a week or so ago (few days before ibex release) I started getting invalid signature messages.  I figured maybe my cache had gotten messed up, and installed apt-proxy on a 2nd box.  that wokred fine until today, when I got "Invalid signature" -
[04:15] <CarlFK> did something in repo land change that may be causing this?  todays apt-get error: http://dpaste.com/88601/
[04:15] <CarlFK> and where is the right place to post about this?
[04:15] <coppro> cp333?
[04:15] <wgrant> CarlFK: I've seen at least two other people with the problem recently.
[04:15] <coppro> perhaps the mirror is dying
[04:15] <CarlFK> cp333 is my local box
[04:16] <coppro> oh
[04:16] <coppro> hmm
[04:16] <coppro> I don't get that issue
[04:16]  * StevenK calls his local mirror 'silver'
[04:16] <CarlFK> wgrant: using a cache, or hitting a real mirror?
[04:16] <lifeless> hi ho ?
[04:16] <StevenK> Because mirrors used to be made with it
[04:16] <wgrant> CarlFK: Using apt-cacher.
[04:17] <wgrant> StevenK: Nice, nice.
[04:17] <CarlFK> wgrant: thanks. I'll stop trying to debug my box :)
[04:17] <wgrant> CarlFK: No, keep going, I don't think anybody has worked out why it happens yet.
[04:17] <coppro> ScottK: well, an example of where I'd expect the AGPL to be useful is something like phpBB.
[04:17] <CarlFK> wgrant: well... um... my plan was to nuke the cache and start over :)
[04:18] <coppro> you want modifiers to have to release source if they let people use it
[04:18] <CarlFK> wgrant: any sugestions on what to do to debug ?
[04:18] <wgrant> CarlFK: No idea.
[04:19] <CarlFK> welp... just re-ran the command, worked fine.
[04:19] <StevenK> CarlFK: Nuke the release files
[04:19] <StevenK> apt-cacher is ... thpecial
[04:20] <wgrant> None of apt-{proxy,cache{,-ng}} seem to work reliably.
[04:20] <wgrant> s/cache/cacher/
[04:21] <StevenK> And mirroring solutions like debmirror and apt-mirror have their own problems
[04:21] <CarlFK> why did apt-get update say: Hit http://cp600 sid Release.gpg
[04:21] <StevenK> debmirror is dumb as a post, and will happily delete 30GB at a pinch
[04:22] <CarlFK> wait... I may have a sid in my sources.list...
[04:22] <StevenK> CarlFK: Because sid appears in your sources.list?
[04:22] <wgrant> StevenK: I was mildly displeased when Hardy's debmirror ate my entire mirror due to a bug.
[04:22] <CarlFK> yep: www.debian-multimedia.org sid main
[04:22] <StevenK> wgrant: \o/
[04:22] <wgrant> I had 4 releases. That would have taken like 4 months of off-peak to fix.
[04:23] <wgrant> So now I use apt-cacher, and hit it when it breaks.
[04:23] <StevenK> wgrant: I managed to avoid that issue. I dumped debmirror, and moved to apt-mirror, since I was sick of the 100-odd line wrapper I had around debmirror
[04:24] <wgrant> StevenK: apt-mirror takes something not unlike a sources.list, doesn't it?
[04:25] <StevenK> wgrant: I can paste my list if you wish
[04:25] <ScottK> coppro: I'd find AGPL useful if I'd written some web service thingy and wanted to make sure no one added stuff to it that I couldn't get access to.
[04:25] <StevenK> wgrant: But it's roughly like it
[04:25] <wgrant> ScottK: Which is precisely what LP needs.
[04:25] <wgrant> But such a license has large issues in practise.
[04:25] <ScottK> wgrant: needs/wants, but sure.
[04:26] <wgrant> ScottK: Oops, true.
[04:26] <ScottK> As a practical matter I think it just discourages other people from caring about extending your software.
[04:27] <ScottK> Which might well be considered a feature in this case.
[04:27] <wgrant> It wouldn't surprise me.
[04:30] <gouki> After Intrepid, all 'Recommends' get installed, correct?
[04:30] <Hobbsee> yes
[04:30] <gouki> Thank you.
[04:32] <ethana2> oh, blast, that build had another bug of the same magnitude that makes it unusable also
[04:32]  * ethana2 files
[04:33] <wgrant> ethana2: Do not file bugs against PPA packages.
[04:33] <ethana2> oh
[04:33] <ethana2> ok
[04:33] <StevenK> Netbook Remix has a bug tracker
[04:33] <StevenK> There's a netbook-remix project in LP
[04:33] <ethana2> i'm on netbook remix's thing
[04:33] <ethana2> code.launchpad.net/~netbook-remix-team/wind..
[04:34] <ethana2> ...so I can file a bug there, right?
[04:34] <Hobbsee> no, that's a team.
[04:34] <Hobbsee> that'snot the project.
[04:34] <Hobbsee> you can't file bugs against people or teams
[04:34] <StevenK> Pity
[04:34] <Hobbsee> i know!
[04:34] <gouki> hehe
[04:34] <StevenK> ethana2: https://bugs.edge.launchpad.net/netbook-remix
[04:34] <ScottK> Grump here wonders if that's OT for MOTU anyway.
[04:34] <ScottK> Grump/Grumpy
[04:34] <StevenK> It is
[04:35] <ScottK> Grumpy and can't type.
[04:35] <StevenK> Is the latter the reason for the former?
[04:35] <ScottK> Nope.
[04:37] <ethana2> bookmarked bug submission page, refreshing X session to verify that this is indeed a bug
[04:39] <jdong> bug 293431
[04:39] <jdong> you've got to be joking me.
[04:39] <jdong> THE WORLD WOULD BE A BETTER PLACE IF YOU STOPPED STARING AT THE PROGRESS BAR
[04:39] <StevenK> It needs to what now?
[04:39] <jdong> StevenK: the progress bar for torrents needs to have more sig figs
[04:39] <jdong> "When a user (i.e. me) is downloading large torrents (between 4 GIB - 8
[04:39] <jdong> GIB) the percentage increase between each percentage takes a long time.
[04:39] <jdong> (say from 1 to 2%) . Somewhere down the line I hope it can be made more
[04:39] <jdong> verbose so it shows instead of 1% to something like 1.05 % and so on &
[04:39] <jdong> so forth, so the user knows how much the torrent is moving along."
[04:39] <StevenK> Um. It des
[04:39] <jdong> ack crappy paste
[04:39] <StevenK> jdong: BAD JDONG
[04:40] <StevenK> jdong: It does
[04:40] <jdong> that's a firefox bug
[04:40] <StevenK> jdong: It shows 3 significant figures
[04:40] <jdong> StevenK: that's what I thought.
[04:40] <StevenK> jdong: I'll kick off a large torrent, and screenshot, and nail the bug shut
[04:41] <Hobbsee> oh, that was shirish.
[04:41] <StevenK> Well, it did the last time I ran Transmission, which was Hardy
[04:41] <Hobbsee> that explains all.  I thought it looked a bit strange.
[04:41] <jdong> StevenK: it does here too
[04:42] <jdong> what the hell?
[04:42] <jdong> he submitted a bug 1 hour ago
[04:42] <jdong> and makred it incorrect?
[04:42] <jdong> oh shut up stupid ubottu
[04:43] <StevenK> Now now, jdong
[04:43] <Hobbsee> !jdong
 jdong: yes, but you're FULL OF CRACK!
[04:46] <StevenK> jdong: Screenshot attached
[05:59] <superm1> would querying DEBIAN_FRONTEND env variable from within a postinst be a reliable way to determine if being ran from a noninteractive frontend?
[06:03] <StevenK> Is there a sensible default instead?
[06:04] <superm1> well in this particular case i'm trying to avoid copying in an update-notifer note if it's ran from noninteractive
[06:05] <StevenK> Why?
[06:05] <superm1> well long story short, this note is created when a mysql server isn't contactable during postinst.  well during a squashfs build for live disks, you dont exactly have a mysql server
[06:06] <StevenK> Ignore it, and get livecd-rootfs to empty the update-notifer directory before it makes the squashfs?
[06:07] <superm1> well isn't it possible that there are valid notes though that you'd want livecd-rootfs to keep?
[06:07] <StevenK> Actually, I think it gets masked by a tmpfs ...
[06:08] <superm1> well mind you - i'm just porting all of the mythbuntu live cd creator code, and this was an old hack that we used to remove it, so i'm trying to remove as many old hacks as possible before making the switch over to livecd-rootfs
[06:09] <superm1> according to livecd.sh in trunk of livecd-rootfs:
[06:09] <superm1>     # Removing update-notifier notes is now considered harmful:
[06:09] <superm1>     #rm -f ${ROOT}var/lib/update-notifier/user.d/*
[06:10] <StevenK> Then ignore it
[06:12] <superm1> well my original proposed solution would appear to work if i read the debconf data from debconf/frontend
[06:12] <superm1> i'm just rather wary doing that still
[06:15] <dholbach> good morning
[06:17] <gouki> Morning dholbach.
[06:18] <dholbach> hi gouki, hi warp10
[06:18] <warp10> morning dholbach!
[06:49] <lukehasnoname> Does Ubuntu grab all its universe packages from debian-unstable every release, then Ubuntu-ize them as necessary?
[07:05] <soren> lukehasnoname: Something like that, yes.
[07:06] <lukehasnoname> alright. There was some discussion on whether we still import from Debian on another chat.
[07:09] <Yasumoto> lukehasnoname: if that's the question, then yes, we definitely still do syncs (do a straight pull from debian) and merges (debian + ubuntu changes to a package) from the debian repos
[07:41] <iulian> G'morning.
[08:30] <emgent> morning
[08:37] <stefanlsd> whats the syntax for closing multiple bugs in the changelog?
[08:39] <persia> stefanlsd, The same as for one bug, only multiple times :)
[08:40] <stefanlsd> (LP: #12345) (LP: #12346) (LP: #12346)     kinda thing?
[08:40] <persia> Generally you don't want to do it like that.  I'll prep a paste.
[08:40] <stefanlsd> persia: thanks!
[08:44] <persia> Bother.  My browser crashed whilst I was composing the example.  Here's a real one: http://paste.ubuntu.com/67185/
[08:44] <persia> Note that there is a separate note for each bug fixed.
[08:45] <persia> So, that closes three bugs, but when someone reads it, they can understand what is closed, and why.  It's much more useful than just listing bug numbers.
[08:46] <stefanlsd> persia: yeah, i normally do that, in this case though, im doing an SRU and one fix is closing 2 bugs, and i wanted to add the SRU bug as well. so essentially same fix closes 3.
[08:47] <persia> stefanlsd, Are the bugs not duplicates then, if they are being closed by the same fix?
[08:48] <persia> And shouldn't you use the original bug for SRU processing, so that the reporter and subscribers can see it's being fixed?
[08:51] <stefanlsd> persia: I suppose they would be duplicates if its the same fix. Very different description's though as its an apparmor profile issue that would affect many different packages.
[08:52] <stefanlsd> persia: wrt to the bug number - from the SRU wiki page:   "Also be sure to reference the SRU bug number in the changelog using the 'LP: #NNNNNN' convention."
[08:52] <persia> stefanlsd, Sure.  Just because the reporters described it differently doesn't mean it's not the same bug, as long as it has the same (small) fix.
[08:53] <stefanlsd> persia: kk. thanks. marked it as a dup. Will LP mark all dupes of a bug as fixed released when published?
[08:53] <persia> As an example, consider "crashes on launch" and "pulseaudio connection issues".  Depending on the reporters, these could be the same bug.
[08:53] <wgrant> Hmm. I wonder if SiS does the bug closing magic.
[08:53] <persia> I think LP just ignores the dupes, but the users will be notified.
[08:53] <wgrant> Probably not.
[08:54] <sbeattie> wgrant: I think that's a known bug, that it does not.
[08:54] <wgrant> It also seems to break update-manager's changelog handling.
[08:54] <persia> stefanlsd, Right.  Reference the SRU bug.  In this case, the SRU bug is the master bug you're fixing (or at least the appropriate release task for that bug)
[08:54] <sbeattie> If I recall my conversation with kees correctly.
[08:56] <sbeattie> stefanlsd: an apparmor SRU will probably want to fix bug 271252 as well.
[08:58] <stefanlsd> persia: ok. thanks. maybe that was a little unclear. Can i amend that line to read something like - "Also be sure to reference the original bug number in the changelog that this SRU is addressing using the 'LP: #NNNNNN' convention."
[08:58] <stefanlsd> sbeattie: thanks. will take a look at that
[09:00] <persia> stefanlsd, I'm not someone who can authorise that.  If you feel you can authorise yourself to do it, go ahead.  If you're not feeling sufficiently self-confident, speak with a member of MOTU SRU.
[09:01] <stefanlsd> persia: kk. thanks. will get some input to ensure its correct.
[09:10] <stefanlsd> sbeattie: has an upstream bug been logged about the apparmor syslog parsing issue?
[09:11] <sbeattie> stefanlsd: I'm not aware of one.
[09:15] <huats> morning everyone !
[09:15] <lukehasnoname> hi
[09:19] <stefanlsd> sbeattie: looks like it could be this - https://bugzilla.novell.com/show_bug.cgi?id=304491
[09:24] <slytherin> Does anyone know when is MoM likely to catch up with packages in jaunty?
[09:25] <Hobbsee> slytherin: sometime after the archive is open for general uploads?
[09:26] <slytherin> Hobbsee: what do you mean by general uploads?
[09:27] <Hobbsee> slytherin: things that are not part of the toolchain.
[09:27] <Hobbsee> there will be a mail to u-d-a about it
[09:27] <slytherin> ok
[09:32] <sbeattie> stefanlsd: no, https://bugzilla.novell.com/show_bug.cgi?id=304491 is not the same; at the time that bug was filed, it didn't work against syslog at all.
[09:32] <Hobbsee> besides, MoM looks updated.
[09:33] <Hobbsee> at least main is
[09:33] <sbeattie> stefanlsd:  bug 271252 is different; it's due to the way the kernel passes audit messages to syslog changing its format slightly sometime between 2.6.24 and 2.6.27
[09:34] <stefanlsd> sbeattie: aah ok. thanks. would you be able to open an upstream bug re this bug?
[09:35] <sbeattie> stefanlsd: yeah, much as I can't stand novell's bugzilla.
[09:35] <stefanlsd> sbeattie: hehe. kk. thanks. also, we can include the patch by Jesse Michael to get it 'vetted' by upstream
[09:41] <slytherin> Hobbsee: I was looking at packages in universe and they don't seem to be updated. I will take another look.
[09:43] <persia> slytherin, Also note that Debian is fairly frozen : there haven't been many updates.  50 or so bugs to go.
[09:43] <slytherin> hmm
[09:43] <persia> (note that fixing Debian RC bugs means fresh updates from Debian earlier in the Jaunty cycle, which makes for less scramble later)
[09:44] <Hobbsee> slytherin: i didn't really check universe.  It may be that they want to do main first.
[09:45] <persia> I'm not sure even main is working properly : see recent traffic in -devel
[09:46] <ido_> hello.
[09:46] <persia> welcome ido_
[09:46] <ido_> i would like to help fixing bugs, and would like someone to guide me on how to start]
[09:46] <ido_> other then pointing me to the long long wiki,
[09:47] <persia> The shorter wiki starting page is https://wiki.ubuntu.com/MOTU/Contributing :)
[09:47] <tbielawa> :)
[09:47] <tbielawa> It's a great read to get you on your way
[09:47] <persia> Basically, find a bug (there are lots in LP).  Fix it.  Submit a patch (preferably as a debdiff).  Ask here if you have questions.
[09:48] <ido_> I've already found a bug I want to fix. seems a simple one.
[09:48] <persia> Which bug?
[09:48] <ido_> I don't know how to get the sources though
[09:48] <ido_> well, I'm not sure its listed on launchpad, searching now
[09:49] <ido_> in the gnome-netstatus-applet about page, it shows a close button which doesn't close. only Esc closes the applet
[09:50] <persia> Well, first step is to get it in Launchpad, and assign yourself.
[09:50] <sbeattie> stefanlsd: filed and attached
[09:51] <stefanlsd> sbeattie: great thanks! just need to link up the report.
[09:51] <persia> Next step is to download the sources (apt-get source gnome-netstatus-applet), and prepare a patch.  The section in the wiki on patch systems is worth a read.
[09:51] <ido_> the but was already filed by someone
[09:51] <ido_> https://bugs.launchpad.net/ubuntu/+source/gnome-netstatus/+bug/289649
[09:51] <ido_> how do I tell if its assigned to anyone ?
[09:53] <persia> If it's assigned to someone, their name appears under "Assigned to".  This one appears to be assigned to the "Ubuntu Desktop Bugs" team.  Usually we discourage bug assignment to teams, but some teams prefer to work that way.
[09:53] <ido_> apt-get source doesnt work
[09:53] <persia> I'd recommend asking in #ubuntu-desktop about that one.
[09:53] <persia> Why doesn't apt-get source work?
[09:53] <ido_> oh. it did.
[09:53] <persia> heh
[09:53] <ido_> lemme paste it, and you tell me if its ok
[09:54] <persia> In a pastebin please :)
[09:54] <ido_> http://www.pastebin.ca/1244698
[09:54] <ido_> ofcourse..
[09:55] <jfcgauss_> what is linux-backports-modules package? how does it differ from linux-restricted-modules and linux-ubuntu-modules packages? is it recommended to install that as well?
[09:56] <persia> jfcgauss_, For the last question, I'll suggest #ubuntu.  For the first question, it's backported modules from the upstream mainline : they may break things, and they may be better : no guarantees.  It's roughly like linux-ubuntu-modules.
[09:57] <ido_> persia, did you check it ? and also, where are the sources downloaded to
[09:58] <persia> Sources download to the current directory.
[09:58] <persia> You probably want to install devscripts
[09:58] <ido_> oh. ok. will get that.
[10:01] <ido_> is there a log for what I manually install via apt-get ?
[10:01] <persia> /var/log/dpkg.log
[10:01] <ido_> I'm new to ubuntu
[10:04] <persia> ido_, By the way, there's a patch for that bug in the GNOME bugtracker, posted by a member of the Desktop Bug team in March 2005.  You definitely want to chat with pedro about it.
[10:04] <persia> (as there's probably some reason the patch hasn't been applied)
[10:05] <ido_> well, even if I don't submit it, it'll be good practice for a first time thingy
[10:06] <ido_> ok, after downloading the sources
[10:06] <ido_> i need to first build it to see it works, right ?
[10:06] <ido_> ./configure && make ?
[10:07] <ido_> or do ubuntu packages need anything else ?
[10:07] <persia> Packages use debian/rules to determine how to build.  The recommended practice is to build it in a sanitised environment.
[10:07] <persia> !sbuild
[10:08] <persia> !pbuilder
[10:08] <ido_> ugh. Sbuild or PBuilder then ?
[10:09] <persia> `sudo apt-get build-dep gnome-netstatus-applet && debuild -b`might also work, but it will install all the dev libraries on your system, and then compile against your system, which may not be what you want.
[10:10] <ido_> no, i prefer not to do that
[10:10] <ido_> lots of packages to install which I will not need later on
[10:13] <ido_> Sbuilder is not an  option since i dont have a space 5gb for LVM
[10:41] <jfcgauss_> hi. i've noticed a proprietary driver named "wl" with little description under Xubuntu>System>Hardware Drivers. does anyone know what that is?
[10:45] <soren> wifi driver.
[10:46] <jfcgauss_> i also have a broadcom driver for wireless, but what is wl really for?
[10:46] <soren> Certain broadcom wifi adapters.
[10:50] <ido_> hrm. after doingi a pbuilder build *.dsc, what now ?
[10:51] <ido_> persia ?
[10:54]  * persia doesn't use pbuilder, and hopes someone else can help ido
[10:54] <ido_> oh. any other pbuilder users out there ?
[10:56] <james_w> look in /var/cache/pbuilder/result
[10:56] <stefanlsd> ido_: pbuilder will put the resulting .deb in /var/cache/pbuilder/result
[10:56] <stefanlsd> heh
[10:56] <stefanlsd> :)
[10:57] <ido_> hrm. result of the build from the sources it downloaded
[10:57] <ido_> and if i want to change the sources now and rebuild them ?
[10:58] <stefanlsd> ido_: pbuilder will build the .deb file, which is now the binaries.  you still have the sources you downloaded. so you need to modify those, run debuild again, and then pbuilder.
[10:59] <ido_> where do the sources exist though ?
[10:59] <ido_> i only see the .gz
[11:01] <stefanlsd> ido_: you downloaded them with apt-get source   ?
[11:01] <ido_> yes, into my home dir
[11:01] <ido_> and the did a pbuilder build
[11:03] <stefanlsd> ido_: pbuilder will build a .deb from a .dsc - which uses the .orig.tar.gz and the .diff.gz file.
[11:04] <ido_> right..
[11:04] <stefanlsd> ido_: debuild will build the .dsc for you.
[11:04] <stefanlsd> ido_: the resultant .deb file from the pbuilder will be in /var/cache/pbuilder/result
[11:04] <ido_> so now if i want to make changes, i need to make them and run debuild, which builds the ,diff file and .dsc ?
[11:04] <ido_> and then run pbuilder build .dsc again ?
[11:04] <ido_> am I correct ?
[11:05] <stefanlsd> ido_: correct
[11:06] <ido_> hrm. how do i run debuild ? (and where ? the source package dir ?
[11:08] <stefanlsd> ido_: from the source directory, i run debuild -S -sa
[11:08] <ido_> uhm.
[11:09] <stefanlsd> the -sa may not be necessary
[11:09] <ido_> complains about not finding a debian/changelog file
[11:09] <stefanlsd> ido_: are you in the package source directory?  does debian/changelog exist?
[11:09] <ido_> oh. source tree of package, i syooise
[11:09] <ido_> s/suppose
[11:10] <ido_> how do i extract the package then ?
[11:10] <ido_> can't I do it directly from the sources ?
[11:12] <stefanlsd> ido_: apt-get source should of extracted package for you...  have a look here - this may explain it better: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[11:13] <stefanlsd> ido_: also, consider attending the session on Packaging 101 with dholbach later today - https://wiki.ubuntu.com/UbuntuOpenWeek
[11:13] <ido_> ok
[11:14] <stefanlsd> ido_: There are also some cool you tube videos on it - https://wiki.ubuntu.com/MOTU/Videos
[11:17] <james_w> I'm still marked as "Contributor" on REVU, how do I change that?
[11:18] <james_w> aha, can a REVU administrator change that please?
[11:21] <james_w> http://revu.ubuntuwire.com/details.py?package=python-fstab
[11:21] <james_w> http://revu.ubuntuwire.com/details.py?package=screen-resolution-extra
[11:22] <james_w> http://revu.ubuntuwire.com/details.py?package=netbook-remix-launcher
[11:22] <james_w> ^ those three can be archived as well
[11:23] <ido_> hrm. any time i work with pbuilder i need to run pbuilder to build it, which extracts base.tgz which takes a really long time..
[11:24] <soren> That's how pbuilder works. :)
[11:24] <ido_> can't it leave them extracted ?
[11:24] <soren> No.
[11:24] <ido_> ugh that sucks.
[11:24] <soren> pbuilder doesn't remove all the packages it installs to build your package.
[11:24] <ido_> so my other option is Sbuilder and work with LVM ?
[11:25] <soren> ...so if it didn't use a base.tar.gz, it would be no different than a regular chroot.
[11:25] <soren> That's another option, yes.
[11:25] <ido_> i think I'm missing something..
[11:25] <ido_> the whole point of using pbuilder is to have the env chrooted..
[11:25] <ido_> right ?
[11:26] <stefanlsd> ido_: a fresh base chroot
[11:26] <ido_> so can't i manually extract the base.tar.gz somewhere
[11:26] <ido_> and chroot it
[11:26] <ido_> and work from there ?
[11:26] <stefanlsd> ido_: you could do something like that manually, but for each package you install, you want a fresh chroot. hence the extract.
[11:27] <ido_> well, I'm going to be working only on one package for starters..
[11:27] <ido_> so i dont mind working with it, i think,.
[11:27] <stefanlsd> ido_: we want a fresh base chroot, as then we can be sure that the packages we are building are pulling in the correct build and runnign depends
[11:28] <ido_> true.
[11:29] <ido_> but if i only want to change a line in the source, doesnt that require me to build everything from scratch ?
[11:29] <ido_> i mean, the chroot env..
[11:29] <slytherin> soren: pbuilder removes the packages after build
[11:29] <ido_> seems impossible to work with..
[11:29] <slytherin> ido_: what help do you need with pbuilder?
[11:30] <soren> slytherin: Are you sure? That seems like an awful waste of time.
[11:30] <slytherin> soren: yes, I am pretty sure. pbuilder is the only build tool I use.
[11:32] <ido_> well, I not pbuilder in specific, but I'd like to know how I can take a package, work on it in a chroot env, rebuild it after changing it, and at last repacakge it..
[11:32] <ido_> getting the package source is done with apt-get source
[11:33] <ido_> pbuider build *.dsc makes the chroot'd env with the correct dependencies for that package
[11:33] <soren> slytherin: You wouldn't happen to a have a build log from pbuilder handy, would you?
[11:33] <slytherin> soren: not now. I am in office. :-)
[11:33] <soren> ido_: Use "pbuilder login" instead, and work from there.
[11:33] <ido_> but now when i want to change the source, i have to go all over the build *.dsc again, which takes tons of time because it builds all its deps again
[11:35] <slytherin> ido_: If you want to install all the build dependencies of this package in the chroot you can try this - sudo pbuilder --login --save-after-login
[11:35] <ido_> oh. and that gives me a shell inside the chrooted env ?
[11:35] <slytherin> that will let you login inside chroot and then you can install build dependencies. Then quit and you have a modified chroot available.
[11:36] <ido_> that i can work in
[11:36] <stefanlsd> ido_: technically speaking, using pbuilder isnt required. that is actually something which happens when you supply the debdiff.  we use pbuilder to ensure that the source package we are building, does actually build and remove properly. it also generates the .deb's for us to actually test if whatever we were fixing was fixed. so its really something we want to be doing
[11:36] <ido_> I'd like to  use pbuilder so that my working ubuntu env doesnt get garabaged with unneeded -dev packages
[11:37] <slytherin> ido_: Then outside the chroot, modify the package source, add changelog entry and create new source package. And then pbuilder build *.dsc. Now all teh dependencies are already installed in chroot so it will take less time.
[11:38] <ido_> hrm. can pbuilder get itiself the required dependencies without deleting them ? (like it does with pbuilder build)
[11:38] <soren> slytherin: I've looked at a few pbuilder logs now, and I see nothing to suggest that it removes the packages it installed.
[11:38] <soren> slytherin: Case in point: http://launchpadlibrarian.net/11921692/mnemosyne_1.0-0ubuntu1.build
[11:39] <slytherin> soren: remove as in uninstall from chroot, right?
[11:39] <soren> slytherin: yes.
[11:40] <ido_> there's a --preserve-buildplace for pbuilder
[11:40] <slytherin> soren: perhaps those packages were toolchain packages.
[11:40] <slytherin> or may be the PPA have some different configuration
[11:41] <soren> slytherin: The PPA's don't use pbuilder.
[11:41] <slytherin> soren: I though the file you were referring to was a PPA build log
[11:41] <soren> slytherin: No.
[11:42] <Hobbsee> slytherin: if you have an apt-cache, it won't make that much difference anyway - you remove the download time, but it still takes time to install.
[11:42] <soren> slytherin: It's a pbuilder log attached to a bug.
[11:42] <Hobbsee> (if that's a help)
[11:42] <slytherin> Hobbsee: I know that already and I share pbuilder cache with the usual apt-cache even to cut down download time.
[11:43] <Hobbsee> right
[11:43] <slytherin> Hobbsee: soren is arguing that pbuilder does not uninstall packages after build is finished. I do not have any log handy to prove otherwise.
[11:44] <Hobbsee> slytherin: why would it uninstall the package after the build has finished?  It removes the entire build directory, last i checked.
[11:45] <Hobbsee> slytherin: but that doesn't mean that the dependancies get installed in the base tarball
[11:45] <Hobbsee> (which is what the build directory is based off each time)
[11:47] <slytherin> Hobbsee: Right. That is what I was talking about. The base tarball is not modified. I may be wrong about the details.
[11:47] <Hobbsee> slytherin: but, why are you recommending making your base pbuilder tarball unclean, and not the standard?  That's a great way of setting yourself up for build failures on the buildds.
[11:47] <Hobbsee> (with your pbuilder login --save-after-login)
[11:48] <slytherin> Hobbsee: I am not recommending it. I just told him the way he could save time by modifying the base tar.
[11:48] <slytherin> In fact I am against it.
[11:48] <Hobbsee> slytherin: well, that certainly *won't* save time when he has to create the base tarball over again to get it back to a clean status.
[11:48] <ido_> since I'm working on the UMPC, which is rather slow
[11:49] <slytherin> ido_: Just FYI ... I do not recommend modifying the base tar ball. I am against it. :-)
[11:49] <ido_> it takes I think around 10 minutes just to build a small package..
[11:49] <Hobbsee> ah, right, that wasn't very clear above.
[11:50] <james_w> persia: there are also a couple of old packages from you on REVU, are they still wanted?
[12:11] <persia> james_w, which packages?
[12:12] <james_w> pidgin-maemo and moblin-media-browser-plugin
[12:12] <persia> Those can be archived.  Did someone else archive the rest of them already?  Also, can you not archive?  I thought that was a MOTU grant, rather than requiring an admin.
[12:12] <StevenK> So did I.
[12:14] <james_w> as I said above, I'm not a MOTU on REVU yet, so could an admin do that.
[12:14] <james_w> If I get archive privileges from that then I'll take care of them
[12:14] <persia> Oh.  I missed what you wanted fixed :)  Let me see if I can figure out how to do it with the latest code.
[12:15] <james_w> thanks
[12:15] <Hobbsee> zul: you around?
[12:19] <persia> james_w, james-w on LP, right?
[12:19] <james_w> persia: yup
[12:20] <persia> james_w, Sorry, but I'm getting a SyntaxError from the script :(
[12:21] <james_w> persia: what's the error?
[12:21] <persia> Could a REVU Hacker confirm I'm supposed to be running `sudo -u revu1 /srv/revu-production/scripts/alter_user.py -njames-w -l1`
[12:21] <persia> james_w, "SyntaxError: invalid syntax" on line 35 of alter_user.py (the SQL statement)
[12:22] <james_w> ah, ouch
[12:22] <siretart> try -lreviewer
[12:22] <persia> siretart, same error.
[12:23] <persia> I remember hearing about some ACL changes, and wonder if this script just didn't get updated.
[12:23] <siretart> ok. then its broken
[12:29] <ido_> anyone working with a bluetooth keyboard ?
[13:05] <zul> Hobbsee: kind of
[13:34] <porthose> james_w, persia: ﻿pidgin-maemo and moblin-media-browser-plugin archived :)
[13:34] <james_w> thanks porthose
[13:34] <james_w> porthose: care to do some more?
[13:34] <porthose> sure
[13:35] <james_w> netbook-remix-launcher screen-resolution-extra python-fstab ubuntu-desktop-testing please
[13:36] <persia> ido_, I have one.
[13:37] <persia> porthose, Thanks!  I completely forgot the point of trying to grant james_w access :)
[13:38] <persia> porthose, On an unrelated note, are you stuck for a solution for the Debian RC ampache bug, or just stuck for time (or am I mismapping?)
[13:39] <porthose> persia: RC bug fixed and uploaded to debian
[13:39]  * persia is clearly not watching closely enough :)
[13:40] <porthose> persia: waiting on RFE
[13:40] <persia> Heh.  That's the frustrating time :)
[13:41] <porthose> persia: yea
[14:40] <bddebian> Heya gang
[14:51] <cody-somerville> Heya bddebian
[14:52] <bddebian> Hi cody-somerville
[15:06] <sportman1280> hello.  If i have a package (Synkron).... how do i go about submitting it for jaunty?  I've been testing it in launchpad's ppa...  But would like to contribute it to the ubuntu compunity
[15:08] <slytherin> !tell sportman1280 about revu
[15:34] <RainCT> sportman1280: note that you can tell REVU to get it from your PPA using http://revu.ubuntuwire.com/import.py (that's still experimental so if you use it you'll be helping to test it, but poke me as imports don't run automatically right now :))
[15:42] <slytherin> RainCT: Just replied to your mail about tags. Going home now. May not login later as I am down with severe cold. But if I login we can sure have detailed discussion here.
[15:49] <RainCT> slytherin: alright, I hope you get fine soon :)
[16:17] <geser> Hi bddebian
[16:19] <bddebian> Heya geser
[16:22] <sebner> hi geser bddebian =)
[16:22] <geser> Hi sebner
[16:24] <bddebian> Hello sebner
[16:33] <danbhfive> hello all.  How long does it take for a package that is declared, in a bug report, to be in -proposed, to actually get in -proposed?
[16:34] <danbhfive> Does it take a few days or something?
[16:34] <RainCT> danbhfive: if an archive admin say that it has been accepted into -proposed, then until it's build. usually some hours, but if the buildds are busy it may take more, up to a few days
[16:35] <danbhfive> RainCT: mk, makes sense.  Thanks
[16:43] <gouki> How can one make bugreport work with Debian (the one one Ubuntus repositories, I mean)?
[16:43] <gouki> *on
[16:44] <nxvl> bugreport?
[16:44] <nxvl> reportbug you mean
[16:44] <gouki> Dohh! yes, nxvl.
[16:44] <nxvl> it works with ubuntu?
[16:44] <nxvl> i always used it for debian
[16:44] <nxvl> i thought it never worked with launchpad
[16:45] <gouki> I was told yesterday that something had to be changed in order to work with Debian BTS...
[16:45] <james_w> gouki: "man reportbug" tells you how to tell it to use a different distribution
[16:45] <james_w> "reportbug -D debian" or something
[16:45] <gouki> james_w, ok. Thanks
[16:47] <ScottK> The default doesn't 'work' with Ubuntu, it just sends mail to some Ubuntu ML.
[16:48] <gouki> I know I asked this yesterday, but I'm about to do it and want to confirm with you guys/gals ...
[16:49] <gouki> I'm about to package 2 or 3 packages that are new to both Ubuntu and Debian. In Ubuntu, a bug should be created with title: [needs-packaging] package and in Debian I need to file an ITP.
[16:49] <gouki> So far so good?
[16:50] <nxvl> yup
[16:51] <gouki> After having the package on REVU, the Ubuntu bug get's changed to Fix Committed, and after someone sponsors that package, it gets changed to Fix Released. I should also assign this bug to myself, correct?
[16:52]  * sebner winks persia =)
[16:53] <james_w> gouki: assign it to yourself, but set it "In Progress"
[16:54] <james_w> Fix Committed would be used when it is uploaded to NEW I think
[16:55] <gouki> OK
[16:55] <gouki> Well, I'm more worried with the Debian part.
[16:56] <gouki> Using reportbug (the file to change BTS is in /etc/reportbug.conf, BTW) I file an ITP.
[16:56] <gouki> After that, what changes do I make to the bug report?
[16:57] <james_w> http://www.debian.org/devel/wnpp/
[16:59] <gouki> Bookmarked! Thank you.
[16:59] <gouki> When the package already exists, being on Ubuntu or Debian, theres no need for a bug report, or is it?
[17:04] <sebner> gouki: yes
[17:04] <sebner> gouki: so I mean, you are right
[17:04] <gouki> sebner, thank you.
[17:06] <gouki> One more thing ... When updating a package (I'm thinking about updating OpenArena) one only downloads the tarball from upstream and copies the debian/ from the already existing package in Ubuntu?
[17:07] <sebner> gouki: well, that's the best-case. More often you have to check if everything is fine with the b-p, patches , maybe you can update the standards version ....  Also important: Don't forget to add a changelog entry
[17:07] <Laney> gouki: There might be changes outside of debian/
[17:07] <Laney> I usually use uupdate
[17:08] <gouki> sebner and Laney, thank you. I'll go read about uupdate.
[17:08] <gouki> One thing I forgot to ask .. When updating an existing package, it's recommended to also get this into Debian, correct?
[17:08] <Laney> yes
[17:09] <gouki> OK
[17:09] <gouki> Well, I'm off. I have enough on my plate for today :)
[17:09] <gouki> Thank you all for the help.
[17:09] <Laney> We currently sync openarena from debian
[17:09] <sebner> gouki: maybe first updating in debian so you can sync it to ubuntu easily
[17:09] <Laney> so you should update it there
[17:09] <gouki> Sure thing.
[17:11] <porthose> If a kind MOTU has a minute would you please look at http://revu.ubuntuwire.com/details.py?package=quickplay.  I have it up on m.d.n and I just wanted a *quick* REVU from a second set of eyes for any major show stopper errors.  Thx :)
[17:16] <RainCT> porthose: there are two menu files
[17:17] <RainCT> porthose: debian/menu and debian/quickplay.menu (using the old section name), which can be removed
[17:17] <porthose> RainCT:  Thank you very much
[17:19] <RainCT> porthose: the comments from the top of the manpage can be removed. debian/control: "and utilized" -> "and uses" (though that complete line isn't probably really interesting to users); "light weight" -> "lightweight"
[17:19] <RainCT> porthose: that's all I see on a quick glance
[17:21] <porthose> RainCT: Thank you very much that is what I needed to know :)
[17:22] <RainCT> porthose: you're welcome :)
[17:33] <hyperair> hello. can someone sponsor bug #267922 for sru please?
[17:40] <DktrKranz> hyperair: I looked at it briefly, be sure to set target to intrepid-proposed and adjust version to be 1.2.1-3ubuntu1.1; if you're around later, I can have a deeper look. Just ping me ;)
[17:41] <hyperair> DktrKranz: why 1.1?
[17:44] <DktrKranz> hyperair: just to make sure it won't clash with future versions in jaunty
[17:44] <hyperair> i see
[17:44] <hyperair> okay
[17:44] <hyperair> DktrKranz: gimme a moment, i'm done with the debdiff.
[17:44] <hyperair> uploading
[17:45] <DktrKranz> (you're encouraged to fix it for jaunty too, if you have occasion once archives will open)
[17:46] <bsnider> is martin pitt here?
[17:47] <DktrKranz> bsnider: no. he usually is on #ubuntu-devel, ircname "pitti"
[17:47] <bsnider> thank you
[17:47] <chrisccoulson> he's in #ubuntu-desktop at the moment though
[17:48] <hyperair> DktrKranz: debian has 1.3.3-3. bug's fixed in there. it would probably be better to grab 1.3.3 from debian for jaunty
[17:49] <hyperair> blarhg
[18:46] <apachelogger> persia: if you get a chance, please vote on NCommander's MOTU application :)
[18:47] <NCommander> BTW
[18:47] <NCommander> this is a stupid question but
[18:47] <NCommander> Do I need to be a core dev to upload to proposed on a main package?
[18:47] <NCommander> (I'm going to guess yes, but maybe I'm wrong)
[18:48] <geser> I don't know either but I guess yes too
[18:48] <jdong> NCommander: yes.
[18:48] <NCommander> Ok
[18:48]  * apachelogger asks geser to vote as well
[18:48] <NCommander> That makes sense
[18:48] <geser> apachelogger: I know, I try to do it this week
[18:49] <apachelogger> NCommander: the pocket is basically in a freeze state, like the regular pockets would be around release date
[18:49] <NCommander> apachelogger, then why can't backports upload anything to the backport pocket if its a universe package?
[18:49] <NCommander> (the ACL is set so only core devs can upload to the backports pocket)
[18:49] <apachelogger> geser: ok, would be great to have him break stuff right away once jaunty opens ;-)
[18:51] <NCommander> Yay for breaking stuff
[18:51] <apachelogger> NCommander: jdong will know, but IIRC backport uploads don't require archive admin approval
[18:51] <NCommander> apachelogger, yes they do
[18:51] <NCommander> They get stuck in unapproved
[18:51] <NCommander> jdong, hrm, maybe if the ACL for pockets match release, a backporter uploading to hardy-backports on universe might work
[18:52]  * apachelogger always shudders when a package gets stuck
[18:52] <apachelogger> => getting some tea
[18:52]  * NCommander works on evil bug
[19:04] <jdong> NCommander: I've been told it "should" "work" "for" "all" "MOTUs"
[19:06] <gouki> How can I include files in a package, say an example configuration file?
[19:07] <NCommander> jdong, should? Does it?
[19:08] <jdong> NCommander: havent' tried yet
[19:08] <NCommander> If it does, then I can stop nagging for non-main backports <g>
[19:09] <jdong> NCommander: it... applies to all backports
[19:09] <jdong> AFAIK.
[19:09] <NCommander> oh, very cool <g>
[19:11] <Yasumoto> gouki: are you thinking something like installing it in /usr/share?
[19:11] <gouki> Yasumoto, could be.
[19:12] <Yasumoto> and I guess it'd be in the debian directory in the package
[19:12] <Laney> gouki: You mean a file that you created yourself? i.e. isn't in the upstream tarball
[19:12] <gouki> Laney, no, a file that's present on upstream tarball.
[19:12] <james_w> gouki: to a first approximation put the example in "debian/" and then put "debian/example.conf" in "debian/docs"
[19:13] <gouki> It's a sample configuration file, that if I don't make it present on the package, will make it hard for users to know how to use the software.
[19:13] <gouki> I'll try what james_w said.
[19:13] <Laney> If it's already present then don't bother copying it to debian/
[19:13] <Laney> just give the path in debian/docs
[19:14] <gouki> Laney, OK.
[19:14] <gouki> This software also includes a data/ folder (where images required to create HTML pages are stored). Would it work the same way?
[19:15] <Laney> gouki: Use a debian/install for that
[19:15] <Laney> docs for docs, install for other stuff
[19:15] <Laney> man dh_installdocs and man dh_install
[19:15] <gouki> Laney, thank you.
[19:21]  * Laney eyes the channel
[19:22] <Laney> motu-sru member, please look at bug #280129
[19:24] <NCommander> Laney, backporting the fix is safer then plucking the newer version in MIA
[19:24] <RainCT> gouki: if it's a sample, you'll want to use debian/<package>.examples rather
[19:24] <NCommander> *IMHO
[19:24] <Laney> It sure is
[19:25]  * NCommander grabs the source package
[19:25] <NCommander> I can do the backporting
[19:25] <gouki> RainCT, thank you.
[19:25] <Laney> I have it already
[19:25] <Laney> NCommander: ^
[19:25] <NCommander> Laney, can you attach the debdiff to the bug?
[19:25] <Laney> Sure.
[19:26] <Laney> I'm seeking an motu-sru opinion on which way to go though.
[19:26] <RainCT> btw, anyone knows if debian/examples (without <package>.) works? because the manpage doesn't mentione it
[19:26] <NCommander> RainCT, it should
[19:26] <NCommander> due to the way debconf works
[19:27] <RainCT> NCommander: debconf?
[19:27] <NCommander> er
[19:27] <NCommander> debhelper
[19:28]  * NCommander properly lights up the "I would test it to be sure" board
[19:28] <RainCT> NCommander: yeah, I think I'll have a look at the source
[19:31] <james_w> RainCT/NCommander: could one of you fix the problem that was preventing people from making me a reviewer on REVU please?
[19:31] <NCommander> james_w, someone has to mark you a reviewer manually in the system
[19:31] <NCommander> so if you didn't request it ...
[19:31] <james_w> "SyntaxError: invalid syntax" on line 35 of alter_user.py (the SQL statement) apparently
[19:32] <RainCT> ah, there's a typo there that script will probably disappear anyway once we switch to LP groups for permissions
[19:34] <RainCT> james_w: what's your nickname on LP?
[19:34] <james_w> james-w
[19:35] <RainCT> NCommander: re dh_installmanpages, I see debhelper actually provides a perl module and the code to find the debian/* file comes from there, so it should work :)
[19:35] <NCommander> RainCT, yup
[19:37] <hyperair> DktrKranz: about just now... debian has 1.3.3-3. bug's fixed in there. it would probably be better to grab 1.3.3 from debian for jaunty
[19:37] <DktrKranz> hyperair, definitely
[19:38] <Yasumoto> If anyone has some spare time, could you look at https://bugs.edge.launchpad.net/ubuntu/+source/libgnomecanvas/+bug/272316 to see if there's anything else I should add to it?
[19:38] <hyperair> DktrKranz: anyway i've made the changes. what comes next?
[19:39] <DktrKranz> hyperair, provide a test case (if you didn't do already) and subscribe motu-sru
[19:40] <james_w> RainCT: did you make me a reviewer?
[19:41] <RainCT> james_w: yep, if I got the number right :P
[19:41] <james_w> heh :-)
[19:41] <RainCT> james_w: check the text in the comment box, it should say "Reviewer"
[19:41] <james_w> ah, just changed, thanks :-)
[19:41] <james_w> I should have more patience
[19:42] <RainCT> patience? what's this? ;)
[19:42] <james_w> how do I move a package to "Needs work"?
[19:42] <RainCT> james_w: comment without advocating
[19:42] <james_w> aha!
[19:43] <hyperair> DktrKranz: ok done.
[19:43] <RainCT> (once I find time for it I'll add neutral comments and then there'll be a box to select veto/neutral/advocate)
[19:44] <hyperair> DktrKranz: anything else, or do i just wait?
[19:45] <RainCT> siretart: ahh, I remember why the cronjob runs as root now: because the config file has chmod 600
[19:45] <DktrKranz> hyperair, wait for a motu-sru ACK, then ask a sponsor to upload it for you. I could have some time to review SRUs later, but I probably have a TV marathon to see U.S. election day :)
[19:46] <RainCT> siretart: ah no, but the owner is revu1 (and it's 640 actually), nevermind :P
[19:47] <hyperair> DktrKranz: hahah. okay, but if it still isn't reviewed when you're done with the tv marathon, could you do it? =p
[19:47] <sebner> hyperair: that makes 150€ for him ;)
[19:47] <DktrKranz> hyperair, I guess it will be around 2 AM local time, so I will probably some sleep at the time ;)
[19:48] <hyperair> DktrKranz: heh nevermind then =p
[19:48] <hyperair> sebner: D=
[19:48] <DktrKranz> sebner, that's all yours, I never asked money, YOU are my exception
[19:48] <hyperair> lol
[19:49]  * sebner hides
[19:49] <hyperair> hmm what went on before?
[20:07] <uniscript> I have a .deb binary package in _all that I want to transition from hardy to intrepid. Is there a way to create a .changes file without having to unpack the package and rebuild it?
[20:08] <DktrKranz> uniscript, AFAIK, you have to unpack it and launch dpkg-genchanges -S
[20:29] <psusi> when I run debuild it appears to be trying to sign the package with my private key identified by my user name instead of my full name, so it fails to find it
[20:29] <psusi> how does debuild decide what your name is?
[20:29] <hyperair> psusi: from the debian/changelog entry
[20:29] <hyperair> psusi: can be overridden by DEBEMAIL environment variable
[20:29] <psusi> ohh, ooops... forgot to fix that up this time...
[20:30] <hyperair> no wait
[20:30] <hyperair> debuild will look in debian/changelog
[20:30] <hyperair> so you should get it right in debian/changelog
[20:30] <hyperair> dch looks in DEBEMAIL
[20:30] <psusi> yea, that fixed it... I forgot to put my full name in the changelog
[20:30] <hyperair> full name? i thought it only depended on the email?
[20:31] <DktrKranz> psusi, you can also pass -kyouraddress@yourprovider.ext to debuild
[20:31] <psusi> got it working now... just had to fix the changelog to use my full name instead of my user name
[20:42] <psusi> hrm.... looks like dput uploaded to main instead of my ppa... hrm...
[20:42] <NCommander> geser, ping
[20:52] <ajmitch> morning
[20:52] <NCommander> hey ajmitch
[20:55] <geser> NCommander: pong
[21:02] <Laney> cjwatson changed the topic of #ubuntu-devel to: Archive: Jaunty open, go wild
[21:02] <Laney> \o/
[21:02] <NCommander> Wait
[21:02] <NCommander> Jaunty is open?
[21:02] <NCommander> WOOOOOOOOOOOOOO!
[21:03]  * Laney dist-upgrades
[21:06] <psusi> woot! PPA is building my package... neat..
[21:07]  * NCommander do-rekease-upgrade -p -d's
[21:08] <Laney> d-r-u knows about jaunty already?
[21:09] <NCommander> nope
[21:09]  * NCommander does it by hand
[21:10] <NCommander> PPAs still don't know about jaunty :-/
[21:10]  * ajmitch isn't surprised
[21:10] <ajmitch> I should probably upgrade to jaunty around beta time
[21:11] <Laney> There wasn't any massive breakage in intrepid :(
[21:12] <Laney> I remember one late in the Hardy cycle
[21:12] <laga> Laney: unless you had an intel NIC :)
[21:12] <Laney> sadly not :<
[21:16] <ajmitch> Laney: it's depressing reading some of the upgrade reports on the NZ loco list, to be honest
[21:17]  * RainCT does s/NZ/cat/ and agrees with ajmitch
[21:17] <Laney> ajmitch: I saw some bad ones on SA, yes
[21:18] <Laney> it's mostly the same old problems
[21:18] <NCommander> What are the issues?
[21:19] <Laney> pulse, flash, xorg
[21:20] <ajmitch> that sounds familist
[21:20] <ajmitch> s/familist/familiar/
[21:20] <Laney> oh and wireless
[21:21] <RainCT> here we have more unusual complains (don't remember any right now, though) :P
[21:21] <wgrant> Pulse seems to work fine as long as you didn't try to "fix" it in Hardy.
[21:22]  * ajmitch does wonder why upgrades from the alternate CD are still supported or expected to work
[21:24]  * ajmitch sees quite a few uploads to intrepid-proposed already
[21:26] <laga> if motu-sru looked at stuff, it'd probably be more.
[21:27] <jdong> laga: I've been trying to keep up; is the queue that bad? :(
[21:28] <NCommander> I thought you uploaded to proposed, then had SRU ack it
[21:28] <laga> NCommander: no, first get an ACK then upload to proposed
[21:28] <laga> although the docs are not clear.
[21:28] <pochu> or upload to proposed, it's unapproved, then get an ACK, then it's approved, then you test
[21:29] <laga> jdong: i dunno about the queue, i just need to get mythbuntu-diskless into shape: bug #292319
[21:29] <NCommander> what pochu said
[21:29] <laga> jdong: could lead to data loss etc.
[21:29] <jdong> laga: gimme one sec, let me just finish this bit of firefox mangling
[21:30] <laga> jdong: sure, no need to rush. i didn't mean to tell anyone to change their workflow ;)
[21:30] <jdong> ScottK: you did say that me uploading backports should work, at one point, right?
[21:30] <jdong> ScottK: I'm going to try that and see if anything explodes :)
[21:31]  * ajmitch waits for jdong to break the world
[21:36] <jdong> alright, now I wait for big FAIL e-mails from the installer :)
[21:41] <jdong> laga: is that versioning scheme going to be consistent? :)
[21:41] <jdong> laga: I'd usually just do 0.9-0ubuntu1.1
[21:42] <jdong> laga: unless you expect Jaunty to remain at 0.9-0ubuntu1 at release time
[21:42] <jdong> ScottK, NCommander: Confirmed, firefox3 is in gutsy-backports approval queue!
[21:43] <NCommander> Oh good, gutsy can now explode in a shower of bits
[21:43] <jdong> (oh god I ph33r the big rush of requests from NCommander in the next few days)
[21:43] <NCommander> Speaking of that, does that mean uploading for MOTU works?
[21:43] <jdong> NCommander: that is correct
[21:43] <NCommander> jdong, bahahahahha
[21:44] <laga> jdong: i guess we can release 0.10 for jaunty.
[21:45] <jdong> laga: or even -0ubuntu2 would be fine.
[21:46] <jdong> laga: usually I only recommend the weirdly spliced 0.0.whatever versions if you got a package you don't expect would change for several releases or if you're the Mozilla team
[21:46] <jdong> </lighthearted jab>
[21:49] <laga> jdong: i usually prefer -0ubuntu2, but that security team wiki got me worried :) i'
[21:50] <laga> i'll change it
[21:50] <gouki> Can I use debian/rules to copy a folder to /var/www or that isn't recommended?
[21:51] <jdong> laga: ACKed
[21:54] <laga> jdong: thanks!! much appreciated :)
[21:54] <NCommander> Here's a question
[21:54] <ajmitch> the answer is no
[21:54] <NCommander> How do I version an upload so that LP will accept it, and then sync when Debian has a newer version
[21:55] <NCommander> Xubuntu is going to be uploading 4.4.3 to jaunty soonish, based off Debian unreleased packages (unreleased because of lenny)
[21:55] <Laney> -0ubuntu1?
[21:55] <NCommander> What I want to happen is that when those packages hit, expect for those with a normal 0ubuntu1 string will get auto clobbered
[21:55] <ajmitch> -0build1?
[21:55] <ajmitch> just for extra evil
[21:55] <NCommander> I've been told 0~ubuntu1
[21:55] <NCommander> or even 1~ubuntu1
[21:55] <Laney> oh, autosync
[21:56] <NCommander> Bingo
[21:56] <ajmitch> autosync *will* clobber it if it has -0build1, but it's a nasty way to do it
[21:56] <ajmitch> and assuming that the orig.tar.gz is the same, etc
[21:56] <NCommander> Yeah, I'll get yelled at for uploading packages once I become an MOTU
[21:56] <NCommander> ajmitch, it should be
[21:57] <ajmitch> of course you can't trust my opinion on such things :)
[21:57] <NCommander> I could just do a normal 0ubuntu1 upload
[21:57] <Laney> Have I seen ~releaseX before? I think so
[21:57] <Laney> ~jaunty1
[21:57] <NCommander> I've seen ~ubuntu1 on some core packages
[21:57] <NCommander> Laney, we do that for backports
[21:57] <NCommander> (and some people use it for SRUs)
[21:57] <Laney> right, in the main archive
[21:57] <ajmitch> I don't know what the autosync behaviour is for packages with ~ubuntu1
[21:58] <NCommander> ajmitch, as far as I know, autosync checks explicately for XubuntuX
[21:58] <NCommander> X~ubuntu1 won't work
[21:58] <ajmitch> that's the problem, as far as you know...
[21:58] <RAOF> Oh, arse.  evolution-sharp is broken in Intrepid.
[21:59] <NCommander> RAOF, what, again?
[21:59] <NCommander> DIdn't we already fix that -_-;
[21:59] <RAOF> NCommander: You fixed the strange and evil mono segfault while building evolution-sharp.

[22:00] <NCommander> That wasn't its fault
[22:00] <NCommander> That was mono
[22:00] <RAOF> This is more a common-or-garden "libedataserver1.2 bumped soname to -11, but evolution-sharp still points at -9" problem.
[22:00] <NCommander> oh, yay, SRU
[22:01] <RAOF> Slightly compounded by the fact that evolution-sharp _should_ have refused to build against libedataserver1.2-11.
[22:11] <chrisccoulson> RAOF - bug 287332
[22:12] <RAOF> Aha.
[22:13] <RAOF> We can almost certainly get away with an SRU that's not "make the libevolution3.0-cil -> libevolution5.0-cil transition", though.
[22:15] <chrisccoulson> yeah, it seems that the SRU will make it libevolution5.0-cil though, but evolution-sharp doesn't have many rdepends
[22:17] <RAOF> Yeah, only 4 by my count.
[22:24] <TheMuso> /c/c
[22:36] <Philip5> hi guys... i have a question about a setting for the cdbs rules when building a deb package. i'm not sure what setting to use in the rules file to force a check for orphant files that doesn't get installed in a package during build but are left in i.e debian/tmp/usr/lib
[22:36] <Philip5> i was guessing it's DEB_MAKE_CHECK_TARGET := check but am not sure and think the cdbs docs could explain abit more
[22:37] <Philip5> anyone here who can help me on that one?
[22:40] <RAOF> DEB_MAKE_CHECK_TARGET is for running the upstream tests; you're (probably) after the 'list-missing' target.
[22:40] <RAOF> I can't offhand think of a package that uses that target, although I know there are several.
[22:42] <Philip5> RAOF: aha... yes it's list-missing i guess... but how would i use that properly?
[22:42] <RAOF> Make it a dependency of one of the targets.  I think common-post-binary-install is the one you're after.
[22:44] <Philip5> but that would only check if it's needed? it wouldn't work on i.e icons or such files?
[22:46] <Philip5> what i understand --list-missing is a parameter to dh_install but would that be a way to go when using cdbs?
[22:47] <Philip5> i'm not sure that i think cdbs helps or make the life easier than old style rules :)
[23:13] <logari81> hi, after reading the PythonPackaging documentation I achieved to deb-ize a pygtk application I wrote, I would like to upload my work in my ppa, but I am not that sure about the versioning part of my package, is here the right place to ask about that?
[23:14] <lifeless> logari81: sure, you can ask here
[23:15] <lifeless> logari81: there are docs on it though, in the more general packaging area
[23:30] <logari81> my problem is that it is the first package of the application and I am not sure if I should include any of the suffixes I ve read in the documentation
[23:30] <logari81> As I ve understood the schema is like <upstream version> <ubuntu version> <ppa version>
[23:30] <logari81> but I see in ppa of others, packages missing the 2nd and/or 3d suffix, I suppose also they are not obligatory
[23:31] <logari81> I would say in my case I dont need the too last suffices either
[23:31] <logari81> is that correct?