[00:05] <Laney> james_w: hi, got the next lot — http://dpaste.com/167584/
[00:05] <Laney> been slacking a bit, sorry
[00:06] <james_w> Laney: LP is taking a nap, ping me tomorrow and I'll process them
[00:06] <Laney> oh, I didn't actually expect you to be around at midnight
[00:07] <james_w> well, you are :-)
[00:07] <crimsun> xmonad-contrib is 528803
[00:07] <Laney> I forgot to -f on agda
[01:19] <duanedesign> i have done a few patches to fix some easy bugs and posted the patches upstream. I am now wondering what i should attempt next? What would be a good next step?
[01:33] <persia> duanedesign: Towards which goal do you seek a next step?
[01:51] <duanedesign> hello persia
[01:53] <duanedesign> persia: my eventual goal is to be a MOTU and help maintain and add to the Universe and Multiverse
[01:53] <persia> OK then.
[01:53] <duanedesign> persia: is that too broad :)
[01:54] <persia> Two areas which need current work are unmetdeps and patch review.  I'd be happy to lead you through getting started with either of those, if you have time.
[01:54] <persia> No.  broad is what MOTU is all about :)
[01:54] <duanedesign> oh yeah, definetly!
[01:55] <persia> If you'd no preference, I'd rather point you at patch review, as there are recent logs of my pointing someone at unmetdeps
[01:55] <persia> Does that sound like something you're up to doing?
[01:55] <duanedesign> sounds good.
[01:56] <persia> So, we have millions of users, and they submit thousands of patches, and one of our roles is to process those patches to improve the software.
[01:56] <persia> This generally involves testing the patch, potentially porting it to the newest revision, determining the state of the patch in upstream, making sure it does things in a sane way, etc.
[01:57] <persia> If a patch is good, clean, well-reported (or already upstream), we can just upload (freeze observations permitting).
[01:57] <persia> If a patch needs work, we can either work on it or work with the patch submitter to have them work on it.
[01:58] <persia> But the idea is to collect all the patches, make sure they are as good as they can be, and get them into the software (either in Ubuntu or upstream).
[01:58] <persia> There's lots of useful links at http://qa.ubuntuwire.com with stuff that needs attention.  One of those is "Ubuntu Bugs with the "patch" tag.  This is our target for today.
[01:58] <duanedesign> I have not done a ton of patches yet, but it seems like most patches go upstream?
[01:59] <persia> Lots of them, yeah.  There are rare cases where we want a patch only in Ubuntu, but most patches should get passed upstream so that everyone benefits.
[02:00] <duanedesign> I also see a link on /MOTU/TODO/Bugs for Universe and Multiverse bugs with patches attached
[02:00] <persia> That works too :)  There's lots of links to this list.
[02:00] <persia> I like the "patch" tag because those tend to have gotten some triage, but any of the methods works.
[02:00] <duanedesign> ill stick with the one you gave for know. Just want to make sure i am understanding :)
[02:00] <persia> There's about 2000 patches out there, and about 250 with the patch tag.
[02:01] <duanedesign> ok great persia
[02:03] <persia> So, once you've gotten to one of the lists, pick a bug.  I recommend starting either with a package you've seen before, or with a package that you think doesn't have so many developers working on it: these tend to have easier-to-process patches.
[02:04] <persia> Please share the bug number once you picked it so I can follow along :)
[02:05] <funkyHat> Is there an automated way to deal with merge diffs?
[02:07] <funkyHat> Or should I just delete the lines that I don't want?
[02:07] <persia> funkyHat: There are a few, but we've not found any that are smart enough that we can remove humans from the loop.  The algorithm used on MoM is our best current stable attempt.
[02:07] <funkyHat> persia: I mean is there a tool I can use to step through the parts that need merging and choose one or the other?
[02:08] <persia> funkyHat: No, that's the part where we still need human intelligence :)
[02:09]  * duanedesign is looking through the 'patch' bugs now 
[02:09] <funkyHat> So I have to manually remove the <<<<<<<< blah-version (ubuntu) and [02:10] <persia> If you're using MoM, yes, and you have to think about the other stuff.
[02:10] <funkyHat> ok
[02:10] <persia> Also, you'll want to think about *any other* changes.  MoM merges some stuff cleanly which needs attention.
[02:15]  * zul cries
[02:15] <persia> Why?
[02:15] <zul> ajmitch: fixed
[02:16] <ajmitch> zul: I should have done it myself, but it took awhile to update my lucid VM :)
[02:17] <zul> ajmitch: slacker
[02:20] <funkyHat> If the debian maintainer has changed, should I update XSBC-Original-Maintainer to match?
[02:20] <persia> funkyHat: Please.
[02:20] <persia> duanedesign: Did you find a good bug with a patch?  Do you need a suggestion?
[02:21] <funkyHat> Oh I guess that's what will happen anyway if I keep the debian maintainer headers and then run update-maintainer...
[02:21] <duanedesign> persia: i think i might of found something
[02:22] <duanedesign> bug 40925
[02:22] <persia> Oh, that's a good one!
[02:22] <duanedesign> looks like there is a patch upstream waiting
[02:23] <persia> From the description, the manpages might already be included in the upstream tarball.  Download the source to check.
[02:23] <funkyHat> Does it make any sense to use apport-bug to file a merge bug?
[02:23] <persia> funkyHat: Not really, no.
[02:23] <duanedesign> persia: kk
[02:23] <funkyHat> Didn't think so :)
[02:25] <funkyHat> Oh... launchpad isn't being awkward about filing bugs anymore
[02:25] <funkyHat> that's nice
[02:25] <funkyHat> I was just digging for the firefox quicksearch I made to get around it
[02:35] <bjsnider> if an original tarball already contains debian build scripts
[02:35] <persia> bjsnider: Are they good ones?
[02:35] <bjsnider> yeah, good ones
[02:35] <bjsnider> libxine
[02:36] <bjsnider> what is the procedure as far as preparing it for the build system
[02:37] <persia> Typically the same as usual, only one patches (if necessary) upstream stuff rather than starting from scratch.
[02:37] <bjsnider> what i mean is ordinalrily i would add .orig to the name, then add the build scripts to the local directory and do debuild -S -sa
[02:37] <persia> But that sounds like a package we've had around for a while.  Try looking at what was done last time upstream was integrated.
[02:38] <persia> Same basic idea.
[02:38] <bjsnider> or -sd if it's already in the archive somewhere
[02:38] <bjsnider> so if i do an -S -sa with th orig fie already containing the build scripts, it's fine?
[02:39] <bjsnider> i have to add a new changelog entry
[02:39] <bjsnider> i don't see how that would work
[02:39] <bjsnider> the diff would just change the build scripts?
[02:39] <bjsnider> instead of creating them?
[02:40] <persia> Right.
[02:40] <bjsnider> i see
[02:40] <persia> debhlper has an --ignore feature if you need to ignore some file provided by upstream.
[02:42] <funkyHat> Is there a proper format for the contents of debian/changelog?
[02:42] <funkyHat> Not sure what to put, or how
[02:42] <bjsnider> use dch -i
[02:42] <funkyHat> I used dch, yeah, just wondering what else I need to put
[02:43] <funkyHat> I'm putting (LP: #531681)
[02:43] <persia> funkyHat: That will parse as the correct syntax to close a bug.  Double check by reading your source.changes file when you build the source.
[02:54] <persia> duanedesign: Were you able to get the code?
[02:57] <funkyHat> Trying to run debuild but ubuntu one hasn't synced my gpg key -_-
[02:57] <persia> There should be no need to wait for keyring sync for debuild.  What error do you get?
[02:59] <funkyHat> gpg: skipped "Matt Wheeler <m@funkyhat.org>": secret key not available
[02:59] <funkyHat> gpg: /tmp/debsign.KA3BldE0/amule_2.2.6+debian0-7ubuntu1.dsc: clearsign failed: secret key not available
[03:02] <persia> funkyHat: The most common issue is that you have a comment in your identity in your GPG key.  Run `gpg --list-secret-keys`  If you have an entry in parentheses between "Matt Wheeler" and "<m@funkyhat.org>" you need to include that in debian/changelog
[03:02] <funkyHat> persia: ~/.gnupg@ is empty
[03:04] <persia> Then you don't have a key available on that account.  This is entirely unrelated to any status on the keyservers.
[03:04] <funkyHat> Yes I know, the issue is with Ubuntu One
[03:05] <funkyHat> The lucid VM isn't collecting the contents of .gnupg that I put in my Ubuntu One folder
[03:06] <persia> You really don't want to put that there.
[03:07] <funkyHat> What's a better way to move stuff in and out of kvm VMs?
[03:07] <persia> Unless you have some reason to *know* that the cryptography used for that remote store is sufficient, you may have compromised your key.
[03:07] <persia> I use ssh.
[03:07] <persia> But I also don't worry about signing stuff in VMs.
[03:07] <persia> If I get a good result, I can always use debsign to sign it.
[03:08] <persia> So I usually use `debuild -S -us -uc`
[03:08] <duanedesign> persia: ok, looks like the upstream documentaion that was included was in .html format
[03:08] <persia> (I do the same thing in chroots, which I use more frequently than VMs)
[03:08] <persia> duanedesign: But no upstream manpages in 4.2?
[03:10] <duanedesign> duanedesign: not in the package. But the patch is the html files converted and then minor edits by hand.
[03:11] <persia> duanedesign: OK.  So since you've determined that you understand the issue, and can work on it, set the bug to "In Progress" and assign yourself.
[03:11] <persia> Then make the necessary changes in the source, etc.
[03:12] <persia> Check the upstream mailing list, and see if someone already submitted db4.2 manpages (which may differ from db4.3 or higher manpages).
[03:12] <persia> (this could save you some work).
[03:12] <persia> If they *do* differ, and upstream doesn't have any for 4.2 yet, please submit them.
[03:12] <persia> Once you have a working solution, add that to the linked Debian bug.
[03:13] <persia> Once that's done, you get to decide: if you think it's important that Ubuntu fix this, prepare a candidate for upload.  If you think it should be fixed in Debian or further upstream, mark the Ubuntu task wontfix with an explanation.
[03:13] <persia> Any questions?
[03:15] <duanedesign> the source i got from the oracle9upstream) contains the /doc directory with the .html documentation. The Debian and downstream does not
[03:15] <persia> Really?  So there's a new upstream tarball of db4.2 that isn't yet integrated into Debian and Ubuntu?
[03:17] <duanedesign> persia: i dont think its new. I think for some reason they just took that directory out. Is there a bias towards .html documentation
[03:18] <duanedesign> because the Ubuntu/Debian Read Me even references the missing /doc directory. Saying to see the documentation load docs/index.html into your web browser
[03:18] <duanedesign> guess that needs to be changed too :P
[03:18] <persia> duanedesign: There's a bias towards manpages.  There exists a framework for handling HTML docs, but most developers are neutral about it (use it when it's there,but don't create it when it's not).
[03:19] <persia> duanedesign: That makes it sound intentional.  I'd recommend wontfixing the bug, unless you want to argue with the Debian maintainer about it.
[03:19]  * persia checks a couple things
[03:20] <duanedesign> persia: they might of just moved the .html help pages. Ill search
[03:23] <funkyHat> http://paste.ubuntu.com/388017/ I'm getting an error with pbuilder that I don't understand
[03:24] <funkyHat> Oh I missed off the bit further up where it says that package is broken...
[03:25] <persia> funkyHat: So you understand now?
[03:25] <funkyHat> persia: sort of, I don't know why it's broken
[03:25] <funkyHat> Or how to fix it
[03:26] <funkyHat> As it's broken inside the pbuilder thing, not my actual system
[03:27] <funkyHat> http://pastebin.com/DrnqNGWG Here's the whole output, in case it's any use
[03:30] <funkyHat> Oh, I've worked it out. I need to configure pbuilder to use universe
[03:34] <persia> Good identification of the issue :)  Just take care to switch back to main-only if you are working on a package in main.
[03:34]  * persia frequently fails when dealing with main packages due to having enabled universe
[03:35] <funkyHat> Would it be worth it/possible creating separate base.tgz images for universe and main?
[03:36] <persia> Depends on how much you work in both areas.
[03:36] <persia> Some people do that.  Some people don't.
[03:36] <duanedesign> persia: ok,  db4.2-utils has no man page. Because there is a seperate package db4.2-doc. Its 9.8 MB of HTML pages, lol
[03:37] <duanedesign> so thats where they went
[03:37] <funkyHat> Well so far I've only submitted 5 debdiffs, and pretty sporadically, but I'm planning to do more as time allows ⢁). I'll hold the thought and perhaps do it if I find reconfiguring an issue
[03:41] <duanedesign>  there is a 4.3man page. Should be easy to make a 4.2 manpage by looking at the diff from the 4.2 ->4.3doc package
[03:42] <funkyHat> This thing is taking so long to build :/
[03:43] <funkyHat> Oh, VM. Duh.
[03:43] <persia> duanedesign:  Just make sure to check if there were changes in usage or options between the 4.2 utilities and the 4.3 utilities, and that those are accurately represented as changed in the 4.2 manpages.
[03:43] <duanedesign> persia: ok. Thank you for all your help and patience ;)
[03:44] <persia> duanedesign: Thanks for helping out with the patch review team.
[03:47] <funkyHat> Oh... I think I might have just wasted a bunch of time there with this merge...
[03:48] <funkyHat> It looks like there's actually no changes left (which I actually wrote in the changelog, but it didn't click), so we should just take the debian version
[03:48] <ScottK> That's the best kind.  It means it doesn't need someone to bother with merging it next time.
[03:49] <ScottK> Discovering that and asking for a sync is not a waste of time.
[03:49] <funkyHat> ScottK: Shall I change my merge bug to a sync request, or make a new bug?
[03:50] <ScottK> funkyHat: Just change it.
[03:50] <ekimmargni> If I'm interested in ubuntu getting a package of the gerrit code review tool for git, where should I start on that process?
[03:54] <funkyHat> ScottK: which team should I subscribe?
[03:54] <ScottK> Is the package in Main or Universe?
[03:54] <funkyHat> Universe
[03:55] <funkyHat> Ah is it ubuntu-universe-sponsors?
[03:55] <ScottK> Yes
[03:55] <funkyHat> Thanks ⢁)
[03:56] <funkyHat> I updated merge-o-matic too
[04:00] <persia> ekimmargni: How much effort are you willing to put into creating and maintaining the package?
[04:01] <ekimmargni> persia: None. I've never packaged anything - that's totally beyond my capabilities.
[04:01] <funkyHat> If MoM hasn't encountered any problems with a merge are there any standard places I should check for issues, or is it enough to simply attempt to build?
[04:03] <persia> ekimmargni: OK.  Let me see if I can dig up the appropriate guidance docuemtnation.
[04:03] <ekimmargni> *nod* thanks :)
[04:06] <persia> ekimmargni: My apologies: I can't find quite the page I wanted.  https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages talks about a general overview.  The "Criteria" and "Requesting a new package for Ubuntu" sections are the ones in which you'll likely be ost interested.
[04:06] <funkyHat> Looks like debian-faq is another one to be synced
[04:06] <ekimmargni> persia: thanks, I'll take a look
[05:00] <funkyHat> I just uploaded debdiffs to https://bugs.edge.launchpad.net/ubuntu/+source/debian-faq/+bug/531711 - it's a really straightforward merge
[05:06] <persia> funkyHat: Cool.  And you've subscribed the sponsors.  This is a quiet time of day, LP was recently down, and there's about 15 other items in the queue right now, but it ought get hit sometime soon.
[05:19] <wrapster> dpkg -l lists out a particular pkg as installed but if i check for the same pkg in /var/cache/apt/archives I cannot find that pkg.. how so
[05:20] <persia> wrapster: There's no requirement that /var/cache/apt/archives includes any installed package.  It starts out empty on a new install, for instance.
[05:20] <wrapster> ok.
[05:21] <lifeless> the relationship is even weaker
[05:21] <lifeless> *apt* is a tool for downloading and installing packages
[05:21] <lifeless> the cache has no correspondence to installed or uninstalled packages; its just things that apt has been asked to download, and hasn't deleted yet.
[05:22] <persia> Oh right.  I forgot that apt will happily cache stuff without installing it.
[05:22] <lifeless> update-manager can be configured to download but not install security fixes, as an example o f that
[05:23] <lifeless> or if you start an install and hit cancel after some things download they stay in the cache.
[05:23] <persia> Right.
[05:33] <artfwo> is it okay to insert line breaks in debian/control fields like Build-Depends?
[05:34] <lifeless> yes, if continued properly; see policy for the format specification
[05:49] <micahg> an enum in a .h file that's included should be accessable in a function, right?
[05:50] <micahg> nm...
[06:07] <jayvee> G'day — I've had a libvirt bug sitting around a while, and I have a debdiff attached. I was wondering how I could help move it forward, or get the ball rolling.
[06:08] <jayvee> I've been told I need to get it into a sponsorship queue of some kind, but not sure how to go about it.
[06:14] <persia> jayvee: What's the bug number?
[06:14] <jayvee> persia: https://launchpad.net/bugs/528934
[06:16] <jayvee> My debdiff bumps the version number from ubuntu8 to ubuntu9. But 13 hours ago, an update to libvirt also bumped the version to ubuntu9. Would it be useful for me to re-do my debdiff with ubuntu10 instead, or is that not a problem?
[06:16] <persia> I'm not sure why zul didn't just upload it Monday, really.
[06:16] <persia> You could subscribe the ~ubuntu-main-sponsors team to add it to a list of stuff to get uploaded.
[06:16]  * persia will do that now
[06:17] <persia> But I'd expect the server team to just upload it.
[06:17] <jayvee> heh
[06:17] <persia> Have you also submitted the bug to upstream?
[06:17] <jayvee> Yep.
[06:17] <jayvee> But obviously that won't get into Lucid in time.
[06:17] <lifeless> upstream are a little insane though
[06:17] <jayvee> Which is why I'm also submitting it here.
[06:18] <persia> !sponsorship
[06:18] <persia> !sponsor
[06:18] <persia> Grr.
[06:19] <persia> So https://wiki.ubuntu.com/SponsorshipProcess outlines the process.
[06:19] <persia> This is likely to change soon as the ~ubuntu-main-sponsors and ~ubuntu-universe-sponsors teams are merged (ideally to make it simpler)
[06:20] <persia> But unfortunately the main sponsors seem not to get to things quickly.
[06:20] <persia> Since zul has an interest in this bug (based on his triaging it on Monday), you might ask him if it needs something else to be uploaded.
[06:20] <persia> You might also check with the folk in #ubuntu-server as they tend to care for libvirt and friends.
[06:21] <jayvee> okay
[06:21] <jayvee> is pinging zul in here enough to grab his attention?
[06:22] <persia> Not at this time of day (it's 1:22 there), but when he's awake yes.
[06:22] <persia> But I'd really recommend trying the ping in #ubuntu-server, as more folk there have an interest in libvirt, so someone else might also grab it.
[06:23] <jayvee> Do you think I should re-do the debdiff with the new version number, or is there not much point?
[06:26] <jayvee> persia: oh cool, all I have to do to get it magically in the sponsorship queue is add it to ~ubuntu-{main,universe}-sponsors
[06:26] <jayvee> now I get it
[06:26] <persia> jayvee: I think it's a good idea to update the debdiff if it needs updating.  In my view, when you submit a debdiff, you *are* an Ubuntu Developer, and should be submitting something that would create precisely what any developer would upload.
[06:27] <jayvee> lol, http://qa.ubuntu.com/reports/sponsoring/ is serving utf-8 text with an iso-8859-1 content-type header
[06:27] <persia> That said, if it's trivial, most sponsors will just fix it (but it's more work for the sponsor, and some folk are picky).
[06:27] <jayvee> okay, I'll update it right now
[06:27] <persia> jayvee: Please file a bug against the sponsoring overview :)
[06:27] <jayvee> haha
[06:27] <jayvee> Content-Type: text/html
[06:28] <persia> https://bugs.launchpad.net/ubuntu-sponsoring/+filebug
[06:28] <jayvee> actually they don't specify any encoding
[06:28] <persia> Oh, then it's a bug in your browser that it doesn't default to UTF8 :p
[06:29] <jayvee> every browser I know of out there defaults to iso-8859-1
[06:29] <jayvee> you can change it in the settings, but that only fixes it for one person
[06:29] <jayvee> I do agree though — utf-8 should be the default everywhere.
[06:29] <lifeless> jayvee: on ubuntu ff defaults to your locale
[06:30] <lifeless> jayvee: and our locales default to utf8
[06:30] <persia> Which is how we solved the bug.  Other environments may need other ways to solve it.
[06:30] <jayvee> lifeless: I don't know any of the technicalities, but I would have to disagree based on past experience
[06:30] <persia> For instance, in environments where the locales default to UCS-2, it makes sense to hack the browsers to default to UTF8, because almost nobody sends UCS-2 over the wire.
[06:38] <jayvee> Well launchpad.net explicitly defines utf-8, and given that the page scrapes launchpad.net directly, it should do whatever launchpad.net does. ;)
[06:40] <persia> The page should explicitly report it's charset anyway.  There's two bugs: 1) the page not giving enough information to read it, and 2) the browser having non-ideal defaults.
[06:40] <persia> It's not precisely scraping LP, but using the LP API to collect details.
[06:40]  * jayvee is testing the shiny new debdiff in pbuilder
[06:54] <jayvee> well, shiny new debdiff attached to bug
[06:54] <persia> Well, now comes the frustrating bit: waiting for someone to upload it.
[06:55] <jayvee> yeah :(
[06:55] <persia> Check with Zul in 9-10 hours in #ubuntu-server (or maybe something more like 18 if you're in a timezone that makes that more convenient)
[06:57] <jayvee> well either I'll ping him at like
[06:57] <jayvee> 2 AM
[06:57] <jayvee> or when I get up tomorrow morning :)
[06:58] <persia> That's about what I figured :)
[07:01] <jayvee> well thanks for the pointers anyway
[07:01] <jayvee> I learnt a lot just now.
[07:01] <jayvee> persia++
[07:02] <persia> jayvee: Thanks for helping fix stuff, and stopping by to ask questions.  The folk here and the folk in #ubuntu-server are both likely to be happy to help you with just about anything if you get stuck again.
[07:03] <jayvee> hopefully one day when I get enough of these patches in, I can apply to become an ubuntu member
[07:29] <alkisg> I'm trying to make a *simple* script and it's failing because "$plugin" is empty inside the `for` loop (i.e. line #8) - could anyone see why? http://alkisg.pastebin.com/3q22Sxd8
[07:29] <alkisg> for plugin in file1 file2; do echo $plugin <== empty there :-/
[07:31] <alkisg> Ugh sorry I just saw it
[07:31] <alkisg> I need to escape $ in \$plugin
[07:31] <persia> hrm?
[07:31] <persia> where?
[07:32] <persia> What sort of script is this?  shell?
[07:33] <alkisg> persia: yeah it's a shell script, but nm, I found the solution, I needed to escape \$plugin
[07:33] <alkisg> Silly me
[07:33] <persia> Where?
[07:33] <alkisg> I gave a pastebin link just above
[07:33] <persia> Yes, I'm looking at it.
[07:33] <persia> I'm just not seeing what you needed to escape, and hoping to learn.
[07:33] <alkisg> Ah, well, the problem was this:
[07:34] <alkisg> $plugin was evaluated while writing to >/tmp/script
[07:34] <alkisg> So it was empty
[07:34] <alkisg> I should escape it so that cat >/tmp/script <<EOF doesn't evaluate it
[07:34] <alkisg> ..so that it gets evaluated later on, at sudo sh /tmp/script...
[07:35] <alkisg> persia: if you run the script and then `cat /tmp/script`, you'll see what I mean...
[07:40] <alkisg> Well apostrophes make it more readable than <<EOF and escaping, so: http://alkisg.pastebin.com/TidxHEuR
[07:40] <persia> alkisg: Heh.  I understand now.  I completely ignored that this was a here-file.  Yes, you need to escape everything :)
[07:40] <persia> Why are you doing this as a here file, rather than directly in the script?
[07:40] <alkisg> persia: yup, it took me some minutes to see it, tricky...
[07:41] <alkisg> persia: I want to put it in a web page for people to copy/paste it directly on the terminal, and sudo makes it tricky, as it kills the clipboard contents
[07:41] <alkisg> So I need to put "sudo" at the end...
[07:42] <persia> I'm generally against putting scripts on web pages.  What problem are you trying to solve?
[07:42] <alkisg> The new beta flash player finally allows for greek chars
[07:42] <alkisg> So I need to provide for an easy way for teachers to upgrade it
[07:43] <alkisg> "go to the adobe site, download the tar.gz, extract to /tmp, and run the script"
[07:43] <persia> And this isn't better achieved by providing updated packages?
[07:43] <alkisg> It's beta, so I'm not sure that the download location will stay there
[07:43] <persia> Just make a custom flashplugin-installer that will be perceived as an upgrade that pulls the beta.
[07:44] <alkisg> I.e. `wget http://download.macromedia.com/pub/labs/flashplayer10/flashplayer10_1_p3_linux_022310.tar.gz` will fail when they get the new beta out
[07:44] <persia> Then update the package.
[07:44] <alkisg> What package?
[07:45] <alkisg> doesn't flashplugin-installer download it on the fly from the adobe site?
[07:45] <persia> Yeah.
[07:45] <alkisg> So, for betas this can't work, since the link isn't stable...
[07:45] <persia> And anytime you want it to download from a different place, or use a different checksum, you have to update the pacakge.
[07:45] <alkisg> Ugh, I wouldn't want to do that each day :D I really prefer to leave some instructions for them to follow :)
[07:45] <persia> What I'm suggesting is that you make a special beta version to distribute temporarily, and when it comes out, encourage people to use the regular version (which would be updated in the archives).
[07:46] <alkisg> I'd need to update the beta package every week or so
[07:46] <persia> It shouldn't change every day.
[07:46] <alkisg> E.g. the tar.gz above is "022310" - 10 days ago...
[07:46] <persia> Yeah, that's why there's no flashplugin-beta-installer :)  It's a lot of work.
[07:47] <alkisg> Yup, so in this particular case, putting scripts on a web site is an acceptable way to do it for me :)
[07:47] <persia> But if you move package-provided files around manually, you end up with a system that can't be reproduced from packages.  You may also cause issues with upgrades.  A security upgrade could break your updates, etc.
[07:47] <persia> There are just too many things that can go wrong, and then you have to deal with annoyed users who followed your instrutions.
[07:48] <alkisg> Sure, it's something temporary which I do hope to see resolved in Lucid (i.e. a non-beta 10.1 flash)
[07:48] <persia> Well, OK.  I just think it's 1) poor service for users and 2) encourages poor practices in users/
[07:48] <dholbach> good morning
[07:51] <alkisg> persia: I completely understand what you're saying, it's just a matter of weighting available solutions & resources. Adobe offers a manual installation of 10.1 beta for now, and I don't have the time to package & keep packaging it, so the users will need to do it the adobe way. I can only give them some instructions on how to do it, I can't help them more.... sure, it's not good practice and it may break on updates, I'll warn them about that. Than
[07:52] <zooko> Folks, this bug is urgent and the fellow who I thought would do it hasn't responded: https://bugs.launchpad.net/ubuntu/+source/tahoe-lafs/+bug/529350
[07:52] <persia> OK.  I just argue against what I consider poor practice when I see it.  If you understand why I think it's poor practice, and are willing to accept the costs, then go ahead.
[07:52] <zooko> It is urgent because it is to upgrade a version of a package for Lucid
[07:54] <persia> rockstar: Do you need a hand with that, or are you expecting to get to it soon?
[07:58] <jayvee> zooko: you're the guy that helped me test Wesnoth for OLPC :-)
[07:59] <zooko> jayvee: :-)
[07:59] <zooko> Me and my son Irby.
[07:59] <persia> zooko: I seem to remember you confirming that it was 100% bugfix, so it's not incredibly urgent.  Let's see if rockstar can get to it (or at least tell us that he needs help) in the next day or two.
[07:59] <persia> zooko: Just to confirm, rockstar *did* tell you to assign him, right?
[08:00] <duanedesign> persia: if i add the manpages to the Debian directory, i then need to put install 'instrucions' in the debian/rules folder?
[08:01] <persia> duanedesign: debian/rules isn't a folder :)
[08:02] <persia> duanedesign: And you probably want debian/db4.2-doc.manpages (read `man dh_installman`)
[08:06] <duanedesign> persia: ha ha. d'oh
[08:12] <zooko> persia: yes it is 100% bugfix.
[08:13] <zooko> Just to re-iterate, here is the NEWS file: http://allmydata.org/trac/tahoe-lafs/browser/NEWS
[08:13] <zooko> I *think* rockstar agreed to do it, but he didn't actually say "And please assign that launchpad ticket to me". :-)
[08:13] <persia> zooko: Cool.  That means we aren't under quite as much pressume (no freeze exception required).
[08:14] <persia> Oh, assigning people when they didn't explicitly ask for assignment and you're not in charge of what they do (e.g. being their boss) is poor form.
[08:15] <zooko> Okay.
[08:15] <persia> But that makes it mostly up for grabs.
[08:15] <persia> jayvee: Feel like processing an update?
[08:15] <zooko> I'm familiar with a different work flow where assigning people to a ticket is more like a suggestion and them "accepting" the ticket is the committing thing.
[08:15] <zooko> But now I know.
[08:15] <persia> We don't have any accept feature, so we double-load assignment.  We use subscription for the suggestions.
[08:16] <persia> No worries.
[08:16] <jayvee> persia: what sort of update?
[08:16] <jayvee> zooko's update?
[08:17] <persia> Indeed.  Apparently rockstar didn't actually commit to it, and so the assignment was based on different semantics than those we usually use.
[08:18] <jayvee> so that would involve basically downloading the new source, moving debian/ across, and making sure it all compiles?
[08:19] <persia> And updating debian/ if necessary, and adding a changelog entry describing what you've done, yes.
[08:19] <jayvee> sure
[08:19] <jayvee> I'll have a bash
[08:19] <zooko> Cool!
[08:19] <zooko> Thanks!
[08:20] <persia> zooko: Please stick around and help jayvee with any tests, etc. to make sure that the update works properly in lucid.
[08:20] <jayvee> I'm running karmic myself, but I can test in chroots, pbuilder-dist, etc.
[08:20] <zooko> I will try! However, I might fall asleep in my chair and if m head rests on the keyboard and sends a stream of characters, you'll know what happened.
[08:21] <jayvee> zooko, what is the time there?
[08:22] <zooko> 0:21
[08:29] <zooko> jayvee: if you need help or any questions answered about Tahoe-LAFS, please join the #tahoe-lafs channel.
[08:29] <zooko> I have to fall asleep now.
[08:29] <jayvee> sure, no problem
[08:30] <persia> zooko: There are people likely to be awake in that channel for more hours?
[08:31] <zooko> persia: not sure.
[08:34] <rawang> I want a newer package which is built in lucid, how can i make it depends on the package in lucid while i'm build karmic package?
[08:34] <persia> rawang: Could you give a little more detail?
[08:35] <rawang> persia, sorry for confusing. I need at-spi >= 1.29, and it's in lucid, but it's 1.28 in karmic
[08:36] <rawang> but i need to build my package for karmic
[08:36] <persia> rawang: Is the at-spi >= 1.29 a dependency or a build-dependency?
[08:36] <rawang> persia, i think both
[08:37] <Rhonda> rawang: Use a chroot environment like pbuilder or cowbuilder for that.
[08:37] <rawang> Rhonda, yes, but i want to publish it on PPA
[08:37] <Rhonda> So? :)
[08:37] <rawang> so i have to handle with the dependency :)
[08:38] <RainCT> rawang: I guess you can backport at-spi too then
[08:38] <Rhonda> I still don't understand why a lucid chroot won't help you then?
[08:38] <persia> rawang: Well, if it's a build-dependency, go read the upstream changelog carefully.  It may not be possible to build against an earlier version.
[08:38] <persia> Rhonda: backport targeting karmic
[08:38] <rawang> karmic only provides at-spi = 1.28, but at-spi 1.29 that i want is in lucid
[08:38] <Rhonda> persia: Ah, the "how can i make it depends on the package in lucid" confused me seriously.
[08:39] <rawang> Rhonda, i have to build against for  karmic
[08:39] <Rhonda> rawang: Change that dependency in the source. If it's generated automatically it should get adjusted the same too.
[08:39] <Rhonda> If it's though in the source as hard depends there probably is a reason behind it.
[08:39] <Rhonda> So don't change it in the source if you don't know the impact.
[08:40] <rawang> ok, let me explain more clearly,
[08:42] <rawang> i want to build my package for karmic, so i have this "blah (blah) karmic; urgency-low" in changelog, and have dependency like "at-spi (>= 1.29.0)" in control file. but apparently, karmic don't have at-spi >=1.29, but it's in lucid repository.
[08:43] <rawang> karmic repository on ubuntu PPA don't have at-spi >=1.29, but it's in lucid repository.
[08:43] <persia> rawang: Right.  So you need to find out *why* it requires >= 1.29.0 of at-spi.
[08:43] <Rhonda> rawang: Then it's like I said, yes. Find out why it has >=1.29 in it and what would break if you lower that to 1.28
[08:43] <rawang> persia, the package source code depends on the newer at-spi :)
[08:43] <persia> And either patch the source to not need that, or first backport that.  If at-spi >= 1.29 is not ABI compatible with at-spi << 1.29 then you have to also backport *all* at-spi rdepends.
[08:44] <Rhonda> Then you would need to backport at-spi too.
[08:45] <rawang> persia, Rhonda ahhhh, i see, i got your ideas
[08:45] <rawang> thanks :)
[08:46] <rawang> so karmic won't like to have a big number version increased, right?
[08:46] <rawang> it just want to its packages stable
[08:47] <persia> rawang: Such a change will not happen in the 9.10 release.  What you do in some third-party repository is up to you.
[08:48] <rawang> k, i understand :D
[09:23] <jayvee> persia: well I reckon it's working
[09:23] <jayvee> just attempting to get ubuntu-vm-builder to build a lucid VM for me to test in
[09:23] <persia> jayvee: Cool!
[09:23] <jayvee> zooko will be happy
[09:24] <jayvee> uploaded it to my ppa for him to grab
[09:25] <persia> jayvee: If you're confident it works, attach the diff.gz to the bug and subscribe the correct sponsors queue.
[09:25] <persia> May as well just dunk it in lucid if it's in good shape and get wider testing.
[09:25] <jayvee> persia: Just one question though: the original tarball used the wrong initial directory, allmydata-tahoe-1.6.1, instead of tahoe-lafs-1.6.1. Does that mean I also have to upload a new .orig.tar.gz?
[09:26] <jayvee> And if so, is it okay to attach the .orig.tar.gz to the launchpad bug report?
[09:27] <directhex> the dir name in the orig tarball doesn't matter
[09:28] <jayvee> directhex: that's good — how does that work?
[09:28] <Laney> --strip-components=1
[09:28] <jayvee> mkdir $package-$version && tar -xvf $orig --strip-components=1?
[09:28] <jayvee> oops, insert a "cd $package-$version" in there
[09:29] <directhex> something like that. i don't look at dpkg-source guts
[09:29] <jayvee> aha
[09:29] <jayvee> just have to rename the tarball, I spose
[09:29] <Laney> yes
[09:29] <persia> jayvee: You're going to want to upload a new orig.tar.gz for the new upstream.  What name and initial directory name upstream used is unimportant.
[09:29] <jayvee> kewl
[09:29] <jayvee> persia: looks like I can use the untouched upstream one though
[09:30] <persia> Yeah, you just need to rename it.
[09:30] <jayvee> what's interesting is that the 1.6.0 orig.tar.gz doesn't match upstream's 1.6.0 tar.gz
[09:30] <persia> zooko takes care to make sure their tarballs work with us well.
[09:30] <jayvee> so evidently paul@ubuntu.com didn't know about that
[09:30] <persia> How don't they match?
[09:30] <jayvee> the initial directory is changed :)
[09:30] <persia> And nothing else?
[09:30] <persia> No removals or anything?
[09:31] <jayvee> don't think so, let me check
[09:31] <jayvee> nope
[09:31] <jayvee> no difference
[09:31] <jayvee> diff -ur says no difference — only the inital directories are different
[09:32] <jayvee> yeah, you're right — can't believe I didn't test it before
[09:32] <jayvee> debuild -S works perfectly with the upstream tar.gz
[09:33] <jayvee> cool
[09:33] <jayvee> so I'll just paste a URL to it in the bug report
[09:33] <jayvee> in the meantime, ubuntu-vm-builder is crashing as usual
[09:33] <jayvee> every single time I use it, it crashes for some reason or another — buggiest piece of software I have ever used
[09:34] <jayvee> time for a lucid netinstall instead, methinks
[09:41] <persia> jayvee: Yeah, that repack is just a case of undereducated developer and insufficiently careful sponsor.  We do that sometimes, although we try to avoid it.  Thanks for catching it and asking for the update.
[09:46] <jayvee> heh
[09:46] <jayvee> well you learn something new every day
[09:50] <ara> to get a list of installed packages and their versions, is `dpkg -l | grep ^ii` correct?
[09:50] <jayvee> I use `dpkg --get-selections`
[09:50] <ara> jayvee, but that does not give versions, does it?
[09:51] <jayvee> no, you're right
[09:51] <jayvee> your solution isn't bad at all — use it :)
[09:52] <persia> ara: In most cases you can drop the grep.  Anything where that grep doesn't matched has leftover config files.
[09:52] <persia> (so you did install it, and didn't completely purge it)
[09:53] <ara> persia, jayvee: thanks
[09:54] <POX> ara: aptitude search -F "%p %V" ~i
[09:56] <POX> probably with --disable-columns
[10:11] <jetienne_> q. anybody familiar with minidinstall ? can i just copy the .deb in mini-dinstall incoming if i dont have the changes and all ?
[10:56] <Laney> james_w: Here's the list again http://dpaste.com/167585/
[10:56] <Laney> I'll close the xmonad-contrib sync bug
[10:57] <Laney> oh, no it already got done
[10:57] <james_w> woop
[10:57] <Laney> please leave that one out then
[10:57] <james_w> ok
[10:58] <Laney> StevenK: you forgot to set the bug to fix released ;)
[10:58] <jetienne_> DinstallException: 'Unknown distribution "karmic" in "/home/jerome/public_html/ubuntu/mini-dinstall/incoming/media-services_1.00_i386.changes"'
[10:59] <jetienne_> this is from a mini-dinstall... any idea why he think karmic is not a distribution ?
[10:59] <nigelb> I want to request a sync of a package from debian, but before that I'd like to build and test it.  I got the package from debian.  Anything to change other than the maintainers?
[11:01] <Laney> don't change anything to do a sync
[11:02] <geser> nigelb: how to you want to build the package? pbuilder or PPA?
[11:02] <nigelb> pbuilder
[11:02] <nigelb> and then tell it to use the current X
[11:02] <geser> then just take the unmodified Debian package and throw it at your pbuilder
[11:03] <nigelb> oh, now why didn't I think of that one :o
[11:03] <geser> pbuilder doesn't care about distribution names in debian/changelog or the Maintainer field
[11:04] <nigelb> only I have to satisfy deps before actually doing the install. right?
[11:04] <geser> right
[11:06] <jetienne_> nobody on my "why minidinstall think karmic is no distro" question ?
[11:08] <geser> jetienne_: I don't use mini-dinstall, so I can't help you. Try looking at the configuration if there's a list of acceptable release names (and if this doesn't help look at the code)
[11:10] <jetienne_> media-services (1.00) karmic; urgency=low !<- this is a line from changelogs ... is this correct ? (apparently karmic is picked up from here)
[11:10] <jetienne_> geser: ok looking
[11:10] <nigelb> dont worry about changelog
[11:10] <nigelb> thats not where you should be looking
[11:11] <geser> in this case it might matter as mini-dinstall is an archive software
[11:12] <nigelb> oh
[11:13] <jetienne_> geser: nigelb: thanks it got fixed
[11:13] <jetienne_> apparently the repository names in mini-dinstall must be the same as package distribution
[12:49] <jayvee> fcuk112: your username is a little edgy
[13:28] <nigelb> bdrung_: built and tested epiphany-extensions-more, works beautifully :)
[13:36] <bdrung_> nigelb: great
[13:36] <nigelb> I'm changing that bug to ffe request
[13:36] <nigelb> just a doubt though, the changelog diff means, I get upstream changelog and current ubuntu changelog and run a diff on it?
[13:37] <bdrung_> nigelb: i will unsubscribe u-u-s, please resubscribe once the FFe is granted
[13:37] <nigelb> will do
[13:37] <nigelb> bug 529835
[13:37] <nigelb> (in case you have to hunt for it )
[13:38] <bdrung_> nigelb: yes, the diff between current upstream changelog of the debian package -> upstream changelog from to debian package
[13:39] <nigelb> thank you, I'll do that in a minute
[13:45] <nigelb> where does the logfile from --logfile option of pbuilder get saved?
[13:47] <Rhonda> nigelb: Where you specify. :)
[13:47] <persia> What's the default?
[13:47] <nigelb> oh no, I just specified the file name
[13:47] <Rhonda> There's no default for --logfile because it requires an argument.
[13:48] <Rhonda> But I would expect relative paths to go from the results directory.
[13:48] <Rhonda> Likewise with where --pkgname-logfile is put into, /var/cache/pbuilder/result/
[13:48]  * persia hugs sbuild harder for doing sensible things with logs by default
[13:49] <nigelb> its not there in /var/cache/pbuilder/result
[13:49] <Rhonda> persia: I consider putting the logfile into the result directory to be very sensible, but then that might be just me.
[13:49] <nigelb> ugh, I have to build again, for a log file.  still better than the floundering with gmake that persia helped me with
[13:49] <Rhonda> nigelb: Use --pkgname-logfile, that's quite convenient.
[13:50] <nigelb> it gets saved in the results folder
[13:50] <persia> Rhonda: That's not bad.  sbuild puts all my logs in a logfile hierarchy or mails them to me (if I give it my email address).
[13:50] <nigelb> ?
[13:50] <persia> (but most excitingly, I don't have to add any parameters, or think about it)
[13:51] <nigelb> Rhonda: wasn't it you who wanted help with irssi bugs? ;)
[13:51] <Rhonda> nigelb: Yes, the --pkgname-logfile gets saved in the result directory.
[13:51] <Rhonda> Always!
[13:51] <nigelb> thats kinda cool.
[13:51] <nigelb> I can deal with Lp bugs :
[13:51] <nigelb> :)
[13:52] <Rhonda> Thanks for the offer. :)
[13:52] <nigelb> rhythmbox is getting saner by day now ;)
[13:53] <nigelb> Rhonda: only 6 bugs? wow, thats nice ;)
[13:53] <Rhonda> I did do what I could.
[13:53] <Rhonda> At least the obvious parts are gone - sorry. :)
[13:55] <toabctl> how can i install the new ubuntu light theme? (i use lucid devel)
[13:55] <nigelb>  --pkgname-logfile needs an arugment?
[13:56] <nigelb> because I dont find the log anywhere
[13:56] <c_korn> toabctl: this question is more approriate in #ubuntu+1
[14:08] <Rhonda> nigelb: No, it doesn't. Like said, it gets stored into the /var/cache/pbuilder/result/ directory.
[14:09] <Rhonda> nigelb: <sourcepackage>_<version>_<architecture>.build should be the name.
[14:09] <nigelb> Rhonda: not there for me.  so I deleted everything from that folder and tried building again
[14:09] <nigelb> (well, the build is still going on)
[14:14] <Rhonda> nigelb: You didn't do the rm after you started the build, just in case?
[14:14] <nigelb> it was on the same terminal, so I started the build after the deletion
[14:23] <nigelb> I only see 4 files after the build is over: a deb, a tar, a dsc, and changes
[14:51] <dholbach> "Running a Packaging Jam" session in 9 minutes in #ubuntu-locoteams
[14:56] <persia> Glah!  That reminds me that I completely failed to run a session today.  Handy nobody showed up for it.
[14:57] <nigelb> persia: when was your session?
[14:58] <persia> Was supposed to be at 6:00 UTC.
[14:58] <nigelb> persia: you could have told me to advertise, I could have spammed identica/twitter ;)
[14:58] <persia> nigelb: I'm glad I didn't, given that I remembered about it about 8 hours before it started and 8 hours after it ended, and not a moment between.
[14:59] <nigelb> persia: haha.
[16:00] <gnomefreak> is there someone dedicated to mplayer?
[16:00] <gnomefreak> all i get is code devs and debain* devs
[16:05] <gnomefreak> siretart: do you have a minute about a changelog entry you have for mplayer
[17:24] <dbell> Hey, I'm wondering if I could get some advise about packaging my python game. I've tried following https://wiki.ubuntu.com/PackagingGuide/Python and managed to build a deb. However, since I'm new to python I've not had any experience in creating setup.py so I'm having problems with being able to run my program. Anyone able to give me some pointers on setting up my setup.py so that I'm able to build a deb and be able to r
[17:24] <dbell> un and distribute my game?
[17:40] <vorian> dbell: it might help to look at some other python apps, chm2pdf for example
[17:44] <vorian> I have a feeling motu-release has changed ...
[17:45] <vorian> what is different than the past cycles?
[17:54] <ScottK> vorian: No more motu-release.  Now it's just ubuntu-release in one team.
[17:57] <vorian> ScottK: so as for the freeze approval, any motu/core can approve?
[17:57] <vorian> I know that was being discussed last time around
[17:57] <ScottK> vorian: No, it's ubuntu-release team now instead of motu-release, but the motu-release members who were active at the time are in ubuntu-release.
[17:57] <ScottK> So other than you subscribe a different team, not much has changed.
[17:57] <ScottK> We did get rid of the two ack's rule.
[17:58] <vorian> okie dokie
[17:58] <ScottK> That's the biggest change.
[17:59] <vorian> ok
[18:18] <christoph_debian> hmmm I'm quite sure I sent out a cl-irc sync request but can't find it anywhere ... shall I re-request?
[18:19]  * persia hunts
[18:21] <persia> Please do.  It appears to have found a grue.
[18:24] <christoph_debian> Sync request mailed.
[18:24] <christoph_debian> that one »just« fixes an rc bug
[19:07] <zooko> Good morning! (UTC-8)
[19:11] <iulian> Hi.
[19:11] <zooko> How are you today iulian?
[19:13] <iulian> zooko: I'm about to go to bed.
[19:13]  * iulian yawns.
[19:13] <iulian> zooko: You?
[19:50] <bjsnider> siretart, so you intend for ffmpeg 0.5.1 to be the version that goes into lucid?
[19:56] <sebner> bjsnider: it's already in
[19:58] <bjsnider> yes but lucid isn't officially released yet
[22:14] <Philip5> hi guys! anyone know of a good pbuilder hook to use with sun java to accept the license agreement during build? and at the same time how would I build with sun java on launchpad without the hook?
[22:27] <geser> with debconf preset
[22:27] <geser> I know that LP had this set in the past, don't know if it still the case
[22:28] <geser> doesn't the app work with openjdk and really needs sun jdk?
[22:49] <lifeless> Philip5: there is a ebconf setting
[22:49] <lifeless> Philip5: its documented in the wiki, under java
[23:03] <Philip5> lifeless: thanks... i'll have a read then
[23:07] <debfx> siretart: a new keepassx release is ready, orig tarball: http://downloads.sourceforge.net/keepassx/keepassx-0.4.2.tar.gz