=== traveller__ is now known as traveller
[02:51] <psusi> I'm trying to extract just the file names from a ureadahead --dump but my sed-fu seems weak... can anyone help?
[02:52] <Emzzzz> http://imggmi.info/DSC-1268361968.jpg/ do my tits look big?
=== funkyHat is now known as funkyGit
=== funkyGit is now known as funkyHat
[03:32] <maco> in patch output, does  "Hunk #4 FAILED at 97." refer to line 97 of the patch, of the file to be patched, or refer to something else entirely?
[03:32] <jayvee> refers to the 4th patch hunk in the patch
[03:33] <jayvee> line 97 of the destination file, I'd guess
[03:40] <ScottL> i'm trying to copy a add a plymouth theme to the ubuntustudio-look package and I'm told that I should use the existing setup.py file to place the theme where it needs to go
[03:40] <ScottL> i need to copy the /ubuntustudio-logo directory (and all it's files) to /lib/plymouth/themes
[03:40] <ScottL> and I know squat about python, but using the existing file this is what I came up with...
[03:41] <ScottL> data_files=[('lib/plymouth/themes/', ['lib/plymouth/themes/ubuntustudio-logo'])]
[03:41] <ScottL> does that make sense? will it actually copy the files and not just the directory?  ANY help would be appreciated!
[03:42] <lfaraone> Can someone show me an example of a use of update-alternatives in a package? I want package bar to provide "foo", but if bar isn't installed, baz should provide "foo" by default.
[03:44] <psusi> I'm trying to extract just the file names from a ureadahead --dump but my sed-fu seems weak... can anyone help?  the file name begin with the line and a /, then are followed by a space and the size in parens
[03:48] <lfaraone> persia: fyi, I figured the autokey situation out.
[03:50] <maco> http://paste.ubuntu.com/393761/ <-- this hunk doesnt apply to this piece of code and i dont want to manually apply that hunk when the rest is a patch in quilt
[03:50] <maco> can anyone see a reason why?
[03:54] <maco> oooh or i'm reading off hunk-numbers wrong...
[03:54] <psusi> can't see why it doesn't apply without seeing the code it is failing to apply to
[04:04] <maco> psusi: i had patch and code in one pastebin, but i realised i was looking at the wrong hunk and now have it fixed
=== paissad_ is now known as paissad
[04:23] <psusi> ok, I've managed to get the ureadahead file list parsed out to just the file names... now I need to massage that into a listing that consists of their inode numbers, one on each line, and some lines starting with an =xxx where xxx is a number giving a priority that should start at 100 and decrease every few files until reaching zero near the end.. and now i'm stumped
[04:26] <persia> psusi: `ls -i` is good for filename -> inode marking.
[04:27] <psusi> yep... I know that... but not sure how to generate the priority tagging
[04:30] <persia> On what basis do you want to identify priorities?
[04:30] <psusi> see I'm trying to take the files that ureadahead reads ahead early in the boot process and use the old e2defrag to pack them all in order at the start of the filesystem so they read faster
[04:31] <EzraR> http://launchpadlibrarian.net/40848926/valgrind.log
[04:31] <psusi> but e2defrag wants a file listing each inode on a line with lines starting with an = and a number identifying the priority of the inodes until the next priority line
[04:31] <EzraR> are those crc errors normal or should i be runnting memtest right now
[04:32] <psusi> and the priorities start at 100 and work down to -100, with unlisted files being assumed to be priority 0
[04:33] <persia> psusi: But how do you want to assign priorities?
[04:33] <psusi> starting at 100 and working towards 0 across the full list of ~2200 files
[04:34] <psusi> maybe I should just work on the defrag code to take the listed inodes in order without any explicit priority
[04:36] <persia> psusi: So if you have 2200 files, you want about 11 at each priority?
[04:36] <psusi> that sounds like it would do it, yea
[04:36] <persia> And they are already in the right order?
[04:36] <psusi> I assume ureadahead --dump lists them in the order they are accessed
[04:37] <psusi> so I'd like to have defrag pack them in that order at the start of the disk
[04:42] <persia> psusi: awk ' { print 100-(NR/4-(NR/4)%1) " " $1 } '
[04:42] <persia> (add $2, etc. to taste.
[04:43] <persia> Oh, and replace "4" with "11" :)
[04:43]  * persia picked a small vaue for test purposes
[04:43] <persia> (or 12, depending)
[04:43] <psusi> got a syntax error
[04:44] <psusi> oops, missed a paren
[04:45] <persia> There's probably some better way to force integers, but ... :)
[04:45] <psusi> though that does not seem to work right... I'm seeing a lot of negative floating points followed by the input lines
[04:46] <persia> Check your parens.
[04:46] <persia> http://paste.ubuntu.com/393787/ was my output testing
[04:47] <psusi> checked it... entered it exactly as you said just with 11 instead of the 4s
[04:47] <persia> I just reran with 7 and got useful results.
[04:48] <persia> (but only on a 30-line input).
[04:48] <persia> Anyway, it should be debuggable :)
[04:48] <psusi> 4 seems to give integers, 11 doesn't
[04:49] <wzssyqa> hi,how to use XB-Python-Version?
[04:50] <persia> psusi: cat /usr/share/dict/words | awk ' { print 100-(NR/11-(NR/11)%1) " " $1 } ' | less gives me integers.
[04:50] <persia> psusi: Maybe nawk/gawk?  (I'm using gawk)
[04:51] <ScottK> wzssyqa: python-central or python-support?
[04:51]  * psusi really needs to learn to use awk
[04:51] <wzssyqa> ScottK: how to edit contral?
[04:52] <fabrice_sp> wzssyqa, you can have a look at http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html
[04:52] <ScottK> wzssyqa: Right, but it depends a bit on which python helper you're using.
[04:52] <ScottK> That's a good one to read.
[04:52] <wzssyqa> ScottK: python-central
[04:53] <ScottK> wzssyqa: XB-Python-Version: ${python:Versions} just above the binary package description.
[04:54] <wzssyqa> replace  ${python:Versions} with 2.6 or etc or all or current?
[04:55] <wzssyqa> ScottK: ?
[04:56] <ScottK> wzssyqa: Let the build system replace it for you.
[04:56] <ScottK> what you put in debian/control is XB-Python-Version: ${python:Versions}
[04:57] <wzssyqa> ScottK: o,XB-Python-Version: all i put it there
[04:58] <ScottK> Yes.  ${python:Versions} instead of all.
[07:38] <dholbach> good morning
[07:48] <^arky^> dholbach: morning
[07:50] <dholbach> ^arky^: heya
=== traveller_ is now known as traveller
=== noodles785 is now known as noodles775
=== _ruben_ is now known as _ruben
[12:31]  * directhex wonders how to accelerate an ubuntu-release decision over Bug 537691
[12:31] <ubottu> Launchpad bug 537691 in Ubuntu Lucid "[needs-packaging] banshee-community-extensions - community add-ons for Banshee media player" [Undecided,New] https://launchpad.net/bugs/537691
[12:33] <persia> directhex: You might ask in #ubuntu-release
[12:33] <directhex> persia, good idea
[12:34] <persia> directhex: My experience is generally that most things just happen, but it's worth catching someone on IRC if I need A to happen because I'm working on B.
[12:40] <directhex> persia, given the proximity to release, i want to make sure no cracks are fallen into
[12:41] <persia> We're not close enough to worry about that if you aren't blocking.
[12:41] <persia> We can probably convince the release managers to approve a swath of stuff once beta1 releases.
[12:41] <persia> But right now, if it's not blocking your work, it's just adding burdens (as every upload currently needs manual acceptance)
[12:42] <directhex> hmm, ok
[12:48] <directhex> "Uploads to universe require a manual push through the queue, but are not subject to release management approval." - hang on, so there's no reason not to simply upload? universe isn't frozen for new uploads?
[12:49] <persia> Um, well, it's more complex than that, really.
[12:49] <persia> But the complexities are complex, and the release team communications aren't likely to get sorted until next cycle.
[12:49] <persia> (and I've given up on sending out corrections)
[12:50] <persia> But essentially, BetaFreeze doesn't mean anything special for unseeded packages.
[12:51] <persia> We're still in FeatureFreeze, but if it's not going into any of the images on cdimage, it doesn't really matter if there's arch skew on builds, etc.
[12:53] <geser> when is the last possible time for an upload to lucid before the release? I plan to upload ubuntu-dev-tools to fix a bug and hopefully to update the defaults for the next release with the upload too (don't want to do a SRU for it)
[12:53] <directhex> so a FFe is still needed from the release team, but release team approval isn't needed for non-FF-breakage? is that it?
[12:54] <persia> Well, non FF breakage that doesn't fall under UIF or BF.
[12:55] <persia> geser: Depends on how much you can convince the release managers to let it in.  I recommend pushing any planned upload for unseeded stuff right about the time the final image canidates are spun.  Getting stuff in later than that is possible, but requires annoying procedural hoops.
[12:56] <persia> Anyone seen quadrispro lately, or know what hours he's usually about?
[12:56] <geser> persia: would that be around FinalFreeze or ReleaseCandidate?
[12:58] <persia> geser: A few days after FinalFreeze actually.
[12:59] <persia> geser: I recommend sending email to u-d@ at final freeze indicating your plans though: this will prevent people being surprised during last-minute uploads.
[12:59] <umang> Sorry if this is the wrong place to ask. I want to add on the PbuilderHowTo page on the Team Wiki that for karmic and bellow `DEBOOTSTRAPOPTS=("--include=apt" "${DEBOOTSTRAPOPTS[@]}")` should be added to .pbuilderrc in order to get a base tarball for sid. Where on the page should I add that? (I had asked about backporting pbuilder here a few weeks ago, so just though this might be the right place since there doesn't seem to be any progress on the backport
[12:59] <umang> ing end)
[13:00] <shadeslayer> hi what do i need to add to build translations along with a package?
[13:00] <persia> umang: Just edit the page.  That sounds sane.
[13:01] <umang> persia, And put it in the .pbuilderrc template or mention it in the troubleshooting section?
[13:01] <persia> umang: troubleshooting section.
[13:01] <persia> umang: Because most folk won't need it in 6 weeks.
[13:02] <geser> persia: thanks, will try to do a final ubuntu-dev-tools upload short before FinalFreeze (and hope it's known till then how lucid+1 will be named)
[13:02] <umang> persia, Alright.
[13:02] <umang> persia, yeah. :)
[13:03] <persia> geser: Really, I recommend doing it *after* finalfreeze.
[13:03] <geser> ok
[13:03] <persia> geser: But check with the release team.
[13:04] <persia> The point being that you need to balance the inconvenience to developers fixing critical issues during FinalFreeze with the inconvenience to developers working on lucid+1
[13:05] <geser> I know, therefore asking for the last possible date to keep ubuntu-dev-tools functional as long as possible
[13:05] <Laney> I thought that the -proposed queue opened a bit before release anyway
[13:06] <geser> a SRU is always an option, but I'd like to avoid going that way if possible
[13:09] <persia> geser: The last possible upload is about 150 minutes before archive close, but please don't try to fit in that window for that :)
[13:09] <persia> A day or two before archive close is probably best.
[13:09] <persia> (and this is complicated, since the timing of archive close is highly variable, depending on image test results, respin rates, etc.)
[13:11] <shadeslayer> hi i need to add translations to my package offered by upstream,they have a script in the cmake files,but i cant figure out if it adds the translations
[13:13] <dpm> shadeslayer, I think you might have more luck asking at kubuntu-devel for that, I'm not too familiar with KDE packaging. I see you have already done that, so it might just be a matter of waiting until someone knows or has time to look into it
=== Tonio__ is now known as Tonio_
[13:53] <shadeslayer> hi can anyone help me with these warnings : rekonq_0.4-0ubuntu1~ppa0
[13:53] <shadeslayer> oops
[13:53] <shadeslayer> http://pastebin.ca/1835424
[13:54] <shadeslayer> the versioning seems to be correct yet,it says native package
[13:54] <shadeslayer> ( lines 54-55 )
[13:55] <persia> shadeslayer: Do you have the right orig.tar.gz present?
[13:55] <geser> shadeslayer: how is your rekonq.*orig.tar.gz exactly named?
[13:55]  * persia doesn't see the usualy warning about not finding the orig though
[13:55] <shadeslayer> persia: geser the tarball is  : rekonq_0.4-0ubuntu1~ppa0.tar.gz : ive also tried with : rekonq_0.4.tar.gz
[13:56] <persia> shadeslayer: You want rekonq_0.4.orig.tar.gz to be in the parent directory, and to be the original upstream tarball.
[13:58] <shadeslayer> persia: ok i fixed the error :)
[13:58] <shadeslayer> persia: apparently i accidently tarballed the upstream folder with debian/
[13:59] <lfaraone> If I have a new upstream bugfix version which works around the bug described in  https://bugs.launchpad.net/bugs/419501, do I attach it to that bug or a new bug report?
[13:59] <ubottu> Launchpad bug 419501 in python-gasp "apport-kde assert failure: python: ../../src/xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed." [Low,In progress]
[13:59] <lfaraone> (it's really a bug in xlib, and it's High)
[13:59] <shadeslayer> lfaraone: just attach it as a patch
[13:59] <shadeslayer> lfaraone: also see #ubuntu-bugs
[14:09] <geser> is there an easy way to figure out which packages hold an other package in main?
[14:10] <Rhonda> geser: apt-cache showpkg $package gives the reverse dependencies of the package.
=== `Alessio` is now known as quadrispro
[14:15] <geser> Rhonda: the problem is that the package (a -perl package) has many reverse runtime and build dependencies and I need check the component of those and if in main check this package too. and my list of packages to check seems to increase instead of decrease.
[14:15] <geser> I guess I need to script is somehow
[14:18] <persia> geser: Get the source for the script that generates component-mismatches.  I don't think it's anastasia anymore (although I could be wrong).
[14:25] <lfaraone> shadeslayer: are bzr merges preferred to patches, btw?
[14:25] <persia> lfaraone: I believe both are currently accepted.  We're still sorting out the presentation tools.
[14:27] <lfaraone> persia: so, rather than subscribing ubuntu-universe-sponsors, I file a merge proposal?
[14:27] <Rhonda> geser: Just put main into your sources.list and apt-cache showpkg can only display packages from main. Done. ;)
[14:29] <Rhonda> geser: Or use grep-available -FDepends $package -sPackage,Section
[14:29] <persia> lfaraone: Doesn't matter.  Either way.
[14:29] <Rhonda> … something along that lines might get you straightly there where you want to aim at.
[14:29] <persia> lfaraone: You can file a merge proposal.  You can link a bug to a branch and subscribe sponsors.  You can attach a patch to a bug and subscribe sponsors.
[14:29] <persia> lfaraone: Different sponsors look at the queue in different ways right now, but people are working on that.
[14:30] <lfaraone> persia: which one has the greatest likelihood of being landed before the beta1? :)
[14:30] <persia> lfaraone: Dunno.  depends who decides to do sponsoring before beta1 :)
[14:31]  * lfaraone choses D, all of the above.
[14:31] <persia> lfaraone: Pick the one that makes the most sense to *you*
[14:31] <persia> lfaraone: Please *don't* choose D.  That just makes it complicated because whoever sponsors it has to do *two* workflows instead of one.
[14:31] <persia> And it may even reduce the chance of getting sponsored because that's extra work for the sponsor.
[14:31] <lfaraone> persia: I'm kidding.
[14:31] <persia> good :)
[14:32] <lfaraone> persia: okay, so I just filed https://code.launchpad.net/~lfaraone/ubuntu/lucid/python-gasp/lp419501/+merge/21242
[14:33] <persia> lfaraone: Which should soon show at http://qa.ubuntu.com/reports/sponsoring
[14:34] <lfaraone> wow, I have to say, I love the way LP does code review.
=== Pici` is now known as Pici
[14:56] <geser> Rhonda: thanks for the hint about reducing the sources.list to only main, that cut down the list of rdepends to a manageable size
[15:26]  * Rhonda giggles at http://www.freesoftwaremagazine.com/columns/bizarre_cathedral_69
[15:26]  * Rhonda . o O ( sorry :) )
[15:30] <Adri2000> sistpoty|work: re: blobby FFe. to make sure I understand correctly: you're ok with the FFe if I find an archive admin willing to sync the current blobby version. i.e. without the ftbfs fix and without the build-dep on the (non-existent in lucid) tinyxml package. right?
[15:31] <persia> Um, can that not be done?
[15:31] <persia> If there is a known ftbfs fix, don't bother to sync, just upload like one might a merge with the FTBFS fix.
[15:31] <persia> (assuming appeoved FFe for other stuff)
[15:33] <Adri2000> persia: the FFe is about a NEW package, and the question is whether or not wait for the next debian revision for syncing. this next revision will fix ftbfs on 2 architectures which ubuntu doesn't support, and will include a build-dep on tinyxml, which is not in lucid
[15:33] <Adri2000> so if we take this new revision, we need to FFe and sync tinyxml as well
[15:34] <Adri2000> if we don't, we take a package that doesn't build on s390 and sh4. which I think is not really a problem for ubuntu :)
[15:34] <Adri2000> bug #537015
[15:34] <ubottu> Launchpad bug 537015 in ubuntu "FFe: Sync blobby 0.8-dfsg-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/537015
[15:34] <sistpoty|work> Adri2000: yes, I'm ok with the current version
[15:35] <Adri2000> cool! :) /me checks the archive admins list
[15:38] <lfaraone> persia: what can I do if I filed a FFE a couple days ago and no action has been taken on it?
[15:42] <psusi> I'm a little confused about the seeds... there are ubuntu-minimal and ubuntu-standard and ubuntu-desktop metapackages that seem to be generated from the seeds, but according to the seed management wiki page, there are also boot and server seeds, but I can't find those meta packages
[15:45] <Adri2000> james_w or jdstrand: ping. would you have a few minutes for a sync please? the sooner we sync it the better, because there will soon be an upload in debian that we don't want in lucid :) it's LP #537015
[15:45] <ubottu> Launchpad bug 537015 in ubuntu "FFe: Sync blobby 0.8-dfsg-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/537015
[16:10] <geser> renaming binary packages needs a FFe, right? (here: postgresql-8.3-pllua -> postgresql-8.4-pllua)
[16:10] <ScottK> geser: I think it's a bug not to work with the default pg, so I'd say no.
=== Tonio_ is now known as Tonio__
=== Tonio__ is now known as Tonio_
[16:29] <jdstrand> Adri2000: sync'd. it now just needs to be deNEWed
=== yofel_ is now known as yofel
[16:40] <Adri2000> jdstrand: thank you. do I need to do something in particular to help deNEWing it? or should I just wait until someone processes the queue?
[16:44] <jdstrand> Adri2000: no, your job is done. thanks :)
[16:44] <Adri2000> :)
[16:48] <randomaction> sistpoty|work: git-buildpackage uploaded (bug 525116)
[16:48] <ubottu> Launchpad bug 525116 in git-buildpackage "please merge git-buildpackage 0.4.65 from Debian unstable (full patch included)" [Medium,Fix committed] https://launchpad.net/bugs/525116
[16:52] <sistpoty|work> randomaction: thanks!
[16:52] <randomaction> np, Rolf did the merge
[16:53] <sistpoty|work> but you uploaded it ;)
[16:56] <randomaction> can we have it in beta1?
[16:56] <sistpoty|work> randomaction: sure, should go through with the next flush of the queue
[17:00] <BlackZ> I have patched a new upstream version of a package in ubuntu repository. It's the first version for ubuntu (version-0ubuntu1), because it's in debian (version-1). Now: should I request a freeze exception for the package, right? (It builds)
[17:06] <randomaction> BlackZ: if -1 doesn't have obvious improvements relative to -0ubuntu1, there's no point
[17:07] <BlackZ> randomaction: it fixes some bugs in the last release
[17:07] <randomaction> and Debian and Ubuntu have the same upstream version?
[17:07] <BlackZ> randomaction: yes
[17:08] <randomaction> then I'd say that no FFe is needed, just a sync
[17:08] <randomaction> because there are no new features when we upgrade from -0ubuntu1 to -1
[17:14] <BlackZ> randomaction: the upstream version is 2.0.7-1, the new upstream version is 2.0.9, so will be 2.0.9-0ubuntu1, right?
[17:16] <randomaction> right, but - are you planning an upgrade to another upstream version? (and can you name the package?)
[17:17] <BlackZ> randomaction: yes - gimp-dds
[17:18] <randomaction> ok, I misunderstood you previously
[17:18] <randomaction> there's no need to prepare 2.0.9-0ubuntu1 because we can just sync 2.0.9-1
[17:19] <randomaction> and whether you need FFe or not depends on if there are new features in 2.0.9 relative to 2.0.7
[17:21] <BlackZ> randomaction: yes, they're. So can I use 2.0.9-1 in debian/control file for the new upstream version?
[17:21] <BlackZ> ops sprry
[17:21] <BlackZ> sorry*
[17:21] <BlackZ> I meant debian/changelog
[17:23] <randomaction> no, just request a sync of 2.0.9-1 from Debian unstable
[17:24] <randomaction> https://wiki.ubuntu.com/SyncRequestProcess
[17:25] <BlackZ> I'll do. Thank you, randomaction
[18:21] <BlackZ> please, help with bug #538195
[18:21] <ubottu> Launchpad bug 538195 in gimp-dds "Please sync gimp-dds 2.0.9-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/538195
[18:49] <sebner> BlackZ: 2.0.8 says: Added support for gamma-correct mipmap filtering in the advanced options
=== kamalm is now known as kamalm-out
[20:02] <RainCT> Hey
[20:02] <RainCT> What's the status of archive reorg? Can MOTU still upload to all of universe at the moment?
[20:05] <randomaction> RainCT: yes, but the archive is frozen for beta
[20:06] <RainCT> ok, I'm asking cause sebner is trying to confuse me (and achieving it quite well) *g*
[20:06] <RainCT> thx
[20:06] <micahg> RainCT: according to the post to -devel-announce, uploads to universe are ok, but need manual queue approval
[20:06] <sebner> RainCT: nah,, I explained everything super easy to you :P
[20:07] <sebner> micahg: randomaction : He refers to package-sets/archive-reorg
[20:07] <micahg> sebner: yes, I was answering the second Q per the -devel-announce email
[20:07] <Laney> cjwatson is the one to ask
[20:07] <sebner> micahg: cli-package set (1 hour ago) is already done so no :P
[20:08] <randomaction> sebner: I did an upload to universe like 3 hours ago
[20:08] <sebner> randomaction: the question was of universe
[20:08] <sebner> randomaction: *all
[20:08] <cjwatson> MOTU's status has not changed
[20:09] <micahg> sebner: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-March/000691.html
[20:09] <cjwatson> and it's not intended for the motu team to lose the ability to upload to what's currently universe
[20:09] <sebner> cjwatson: so the package sets will be working with lucid+1?
[20:09] <cjwatson> the cli-mono set already works in lucid
[20:10] <sebner> then MOTU can't upload to all of universe
[20:10] <cjwatson> hmm?
[20:10] <sebner> that's what I meant micahg
[20:10] <psusi> I'm a little confused about the seeds... there are ubuntu-minimal and ubuntu-standard and ubuntu-desktop metapackages that seem to be generated from the seeds, but according to the seed management wiki page, there are also boot and server seeds, but I can't find those meta packages
[20:10] <sebner> cjwatson: every motu to all of universe
[20:10] <randomaction> did cli-mono packages move to main, then?
[20:10] <cjwatson> I believe this to be false
[20:10] <Laney> There's some idea about MOTU becoming the upload team for "unseeded" packages
[20:10] <cjwatson> give me an example package
[20:10] <Laney> That's what sebner is talking about
[20:10] <sebner> Laney++
[20:10] <cjwatson> so, that has been discussed in very vague terms
[20:10] <cjwatson> it hasn't remotely been implemented
[20:11] <sebner> randomaction: nope, just a special package-set with limited members
[20:11] <cjwatson> but even then - unseeded technically only refers to the "primary" package sets, like kubuntu, ubuntu-desktop - the ones that are generated from seeds
[20:11] <cjwatson> cli-mono is just a big list of packages, not a seed
[20:12] <RainCT> cjwatson: so eg for CLI right now both people in the CLI group and MOTU can upload packages?
[20:12] <cjwatson> so, as stated, there's no reason why motu would lose the ability to upload to cli-mono just because a package set has been defined for it
[20:12] <cjwatson> RainCT: yes, you can test this
[20:12] <cjwatson> (without uploading!)
[20:12] <cjwatson> give me a mono package in universe
[20:12] <Laney> tasque
[20:13] <cjwatson> in a checkout of lp:ubuntu-archive-tools:
[20:13] <cjwatson> ... oh, heh, wait, it doesn't show what I expected :)
[20:14] <cjwatson> edit_acl.py just doesn't follow components, that's all.  bug in the tool.
[20:14] <cjwatson> anyway, while I can't show you it by a paste from a terminal session, package set permissions and component permissions are ORed
[20:14] <Laney> what happens when components go away?
[20:16] <cjwatson> by then, we'll have defined things in much more detail so that I can actually answer that question
[20:16] <cjwatson> but I would expect there to be a package set (probably implicitly generated, rather than having to be maintained by hand) containing all packages not in, err, something like ubuntu-desktop + ubuntu-netbook + ubuntu-server + kubuntu
[20:16] <cjwatson> or whatever
[20:17] <Laney> OK, that's what I understand too.
[20:17] <Laney> (package sets being a bit orthogonal to MOTU)
[20:24] <jcastro> hyperair: what's the plan for banshee 1.5.5? Post beta1?
[20:24] <hyperair> jcastro: er do we have any new freezes in place yet?
[20:24] <jcastro> this morning I believe
[20:24] <hyperair> ._.
[20:24] <hyperair> i'm late, huh
[20:25] <jcastro> I dunno
[20:25] <Laney> there are no extra freezes for universe
[20:26] <hyperair> ah.
[20:26] <hyperair> well
[20:26] <hyperair> i've filed a sync request.
[20:26] <sebner> hyperair: beta freeze = only main
[20:26] <hyperair> it needs an archive admin to take care of it
[20:26] <hyperair> sebner: i see.
[20:26] <sebner> hyperair: banshee \o/
[20:37] <sistpoty> hm, so I just update my bios using flashrom, and the result is that my network card has an hw addr, that's invalid, *sigh*
[20:37] <sistpoty> updated even
[20:38] <sebner> sistpoty: *cheerio*
[20:39] <sistpoty> hi sebner
[20:39] <sebner> sistpoty: I do support your bleeding edge attitude but flashing stuff is usually a bad idea *g*
[20:40] <geser> sistpoty: you sure you flashed the right eeprom? :)
[20:40] <sistpoty> sebner: I had hoped that this fixes my slow response time of a maxtor sata drive (which only happends with my new mainboard)
[20:40] <sebner> sistpoty: and instead it br0ke your network card? That's certainly an EPIC FAIL :P
[20:40] <sistpoty> geser: I flashed... something *g*
[20:41]  * sistpoty picks up a hex editor and looks for the mac address in the bios rom file *g*
[20:41] <sistpoty> wouldn't be the first time I patched a bios update by hand *g*
[20:46] <BlackZ> if a two upstream releases hasn't the README file nor NEWS, etc. how can I request an freeze exception?
[20:46] <BlackZ> can I use the info for new releases from the upstream website?
[20:47] <sebner> BlackZ: sure ;)
[21:18] <cjwatson> RainCT: there we go, that's more like it ...
[21:18] <cjwatson> $ ./edit_acl.py -S lucid -s tasque query
[21:18] <cjwatson> == All uploaders for package 'tasque' ==
[21:18] <cjwatson> Archive Upload Rights for ubuntu-cli-mono-dev: package set 'cli-mono' in lucid
[21:18] <cjwatson> Archive Upload Rights for motu: component 'universe' in lucid
[21:37] <RainCT> cjwatson: thanks for confirming that :)
[22:27] <MTecknology> !dpatch
[22:28] <MTecknology> I'm trying to understand dpatch but I'm kinda lost - anything easy to follow for figuring out how to add a patch with it?
[22:28] <Smeuuh> siretart`: I've been told to bug you, it would seem mplayer is broken from the latest update
[22:29] <siretart`> Smeuuh: well, it works for me :-)
[22:29] <Smeuuh> siretart`: I'm using amd64, latest update just made /usr/bin/mplayer disappear, it'd seem
[22:30] <Smeuuh> first off, mplayer is version ubuntu13, mplayer-nogui is version ubuntu14, is that normal?
[22:30] <siretart`> no, they all should be at ubuntu14
[22:31] <Smeuuh> right, any chance the build failed on amd64 or something ?
[22:31] <Smeuuh> it'd seem ubuntu14 is available for i386, not for amd64
[22:32] <RoAkSoAx> MTecknology, dpatch-edit-patch name.dpatch? and then verify that it is in debian/patches/00list?
[22:32] <Smeuuh> http://de.archive.ubuntu.com/ubuntu/pool/multiverse/m/mplayer/mplayer_1.0~rc3+svn20090426-1ubuntu14_amd64.deb vs same thing with i386
[22:32] <Smeuuh> (not specific to the german mirror)
[22:33] <siretart`> Smeuuh: try checking launchpad. or download/install that package manually. it seems your mirror is outdated
[22:33] <siretart`> or rather: not updated yet
[22:33] <MTecknology> RoAkSoAx: apparently I keep over thinking the patching systems...
[22:34] <Smeuuh> https://launchpad.net/ubuntu/+source/mplayer/2:1.0~rc3+svn20090426-1ubuntu14 it's missing the amd64 part
[22:34] <Smeuuh> has it just not been built yet?
[22:34] <siretart`> Smeuuh: https://edge.launchpad.net/ubuntu/+source/mplayer/2:1.0~rc3+svn20090426-1ubuntu14/+build/1556521
[22:35] <RoAkSoAx> MTecknology, if you do dpatch-edit-patch name.dpatch, it will create a new patch, the you make the changes, and then issue a Control+D. The patch will be in debian/patches/, but make sure it is listed in debian/patches/00list
[22:35] <siretart`> Smeuuh: it hasn't been built yet
[22:35] <siretart`> "Start in 3 hours"
[22:35] <Smeuuh> oh, alright then, should I just wait?
[22:35] <siretart`> yes
[22:35] <Smeuuh> ok, first time it happened to me
[22:36] <sistpoty> hm, do we have any hex editor in the archive that allows to search for binary patterns including wildcards?
[22:36] <Smeuuh> thanks siretart`, sorry for the confusion
[22:37] <MTecknology> RoAkSoAx: awesome - thanks
[22:38] <RoAkSoAx> MTecknology, here's the wikipage that helped me while learning: https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[22:42] <MTecknology> RoAkSoAx: thanks, dpatch was pretty neat - I'm hoping this builds correctly on my system so I can push the change out to launchpad and very eagerly get this on my servers
[22:44] <RoAkSoAx> MTecknology, awesome!!
[22:45] <MTecknology> RoAkSoAx: I feel like I'm starting to crawl out of the noob packager state - maybe I'll be able to offer real contributions to motu eventually :)
[22:45] <RoAkSoAx> MTecknology, it is just practice, practice, practice, and ask questions when doubts, and continue to ask questions and so on :)
[22:48] <MTecknology> RoAkSoAx: If there's a really awesome module to add to something, is that something that could find its way into ubuntu repos or would it probably be best left for its own ppa?
[22:50] <RoAkSoAx> MTecknology, let's say for ie. you wanna add a module to a apache to be shipped in the package? I don't really, however if it's only thing to change how the package is configured and/or the module comes from upstream and its included in upstream but disabled in Ubuntu, you could make it find its way into the package
[22:51] <RoAkSoAx> it is just matter of a bug report and evaluation
[22:52] <MTecknology> ok, I was just curious - I just added a module to nginx, building in LP now
[22:53] <MTecknology> I don't expect this to make it in, it just made me curious
[22:54] <MTecknology> i386 and lpia done, one left :D
[22:55] <RoAkSoAx> MTecknology, what module (I usually merge nginx from debain :) )
[22:56] <MTecknology> RoAkSoAx: upload-status
[22:56] <MTecknology> I want it for Drupal7
[22:57] <RoAkSoAx> MTecknology, this one? nginx_upload_progress_module
[22:57] <MTecknology> RoAkSoAx: http://wiki.nginx.org/NginxHttpUploadProgressModule
[22:57] <MTecknology> ya
[22:59] <directhex> yay i'm on youtube \o/
[23:00] <RoAkSoAx> MTecknology, I see, well I don't really know since It doesn't come with the source, but i'll try to poke someone about it and see what they say
[23:01] <MTecknology> RoAkSoAx: If this works, then the addition of it was unbelievably easy, patch-edit-patch upload-status-module; mkdir modules; git clone ...; mv ... modules/upload-status; vim debian/rules; Ctrl+D
[23:02] <crimsun> jcastro: http://gregdekspeaks.wordpress.com/2010/03/12/any-bored-weekend-hackers-out-there/ looks interesting
[23:02] <RoAkSoAx> MTecknology, note, we don't use patch systems for what is inside debian/ :), we modify that directly
[23:02] <MTecknology> RoAkSoAx: did that wind up in the patch? - I hoped it wouldn't :P
=== kamalm-out is now known as kamalm
[23:03] <RoAkSoAx> MTecknology, i mean, we only use patchsystems to patch the source code
[23:03] <MTecknology> ya
[23:04] <MTecknology> oops
[23:04] <MTecknology> hopefully that doesn't screw this up.. then I can fix that next time
[23:05] <MTecknology> RoAkSoAx: should it still work even if the change to debian/rules is in the patch?
[23:06] <MTecknology> - just so I don't need to redo it this time - fix it when there's a reason to change it anyway
[23:07] <RoAkSoAx> MTecknology, you could just edit the patch manually adn remove the part that patches something under debian/ and then edit it directly
[23:08] <MTecknology> I meant because it's almost done building in LP - once this 4min is up for amd64
[23:08] <MTecknology> which has been sitting there a while now..
[23:09] <MTecknology> I'm fixing it now - I'll just upload again
[23:13] <MTecknology> RoAkSoAx: so in 00list, I should add my patch name to the end of it; then dpatch-edit-patch my_patch last_patch_listed so when I'm editing things I'm looking at things with all the patches applied?
[23:14] <MTecknology> dpatch-edit-patch nginx-upload-progress.dpatch nginx-upstream-fair.dpatch  ?
[23:14] <RoAkSoAx> MTecknology, first dpatch-edit-patch your_patch.dpatch, then edit everything you need to edit not in debian/. then Ctrl-D. once done, edit 00list to add your_patch and edit the rest, if necessary, in debian/
[23:15] <RoAkSoAx> MTecknology, and, yes, it will apply the changes so that your changes are with the patches already applied
[23:16] <MTecknology> RoAkSoAx: how are they applied? top->bottom or bottom->top?
[23:16] <RoAkSoAx> top bottom i believe
[23:17] <MTecknology> thanks
[23:20] <MTecknology> RoAkSoAx: redone - the right way :D
[23:21] <RoAkSoAx> MTecknology, ;)
[23:21] <MTecknology> and the one done the wrong way just finished building :P
[23:22] <MTecknology> RoAkSoAx: funny how that works out :P
[23:23] <sistpoty> directhex: bug #537691 implies removing a number of source packages?
[23:23] <ubottu> Launchpad bug 537691 in Ubuntu Lucid "[needs-packaging] banshee-community-extensions - community add-ons for Banshee media player" [Undecided,New] https://launchpad.net/bugs/537691
[23:23] <directhex> sistpoty, yes, that would be the case
[23:23] <sistpoty> directhex: it's not yet throught debian/new, right?
[23:24] <directhex> sistpoty, no, i only threw it at NEW earlier this evening, once hyperair had finished preparing a package for yesterday's 1.5.5 release
[23:25] <sistpoty> directhex: I must admit that I'd like to not keep archive admins from more important duties, however if you can find an archive admin to do new processing I won't object
[23:26] <sistpoty> directhex: and I guess it could get easier if it went through debian/new already (maybe DktrKranz, congrats btw. might pick an out of order oppurtunity ;))
[23:27] <directhex> sistpoty, oh yes, i need to start dividing my ftpmaster puppy-eyes between bddebian and DktrKranz now don't I. mustn't let any one ftpmaster feel i'm abusing my position...
[23:28] <sistpoty> hehe
[23:28] <directhex> i dread to think of the size of my ftpmaster favours pile by now @_@
[23:29] <sistpoty> directhex: oh, did you check that the upgrade path is sane in regards to the to be removed packages?
[23:31] <directhex> sistpoty, i did now! works fine, of course. the clue is the fifth line of debian/control
[23:32] <sistpoty> directhex: fine, fine (and yes, I didn't check the details of someone doing known good packaging *g*)
[23:33] <directhex> sistpoty, you're right that i should have actually checked earlier about the upgrade path thing... i basically asked hyperair a few days ago if it handled those sanely, and he said yes.
[23:34] <sistpoty> heh, at least I still know when to point out possible points of fail *g*
[23:38] <directhex> i didn't really care much about b-c-e as a priority until i started the whole u1ms plugin process... what, a week ago?
[23:43] <jcastro> directhex: yeah, you're only a day or so behind your counterpart, which is in main!
[23:44] <directhex> jcastro, and has paid staff working on it? there's little actual difference though, since all the magic's in libubuntuone
[23:46] <directhex> look at it this way:
[23:46] <directhex> this is a banshee extension which just shows a custom label: http://www.gitorious.org/banshee-community-extensions/banshee-community-extensions/blobs/master/build/extension-template/Banshee.Template/TemplateSource.cs
[23:46] <directhex> this is u1ms: http://www.gitorious.org/banshee-community-extensions/banshee-community-extensions/blobs/master/src/UbuntuOneMusicStore/Banshee.UbuntuOneMusicStore/UbuntuOneMusicStoreSource.cs