[00:01] <dupondje> l3on: thx
[00:01] <dupondje> well it got dropped because it got fixed upstream ... tought it was good to keep the changelog small :)
[00:01] <l3on> nope.. the general rule is "log everything" :)
[00:02] <tumbleweed> keep the changelog readable
[00:02] <tumbleweed> and say what you were trying to do, not every detail of what you did
[00:02] <tumbleweed> and yes, it's generalyl good to list the bits of ubuntu delta that were dropped
[00:03] <tumbleweed> (just like you list the patches you kept)
[00:09] <Adri2000> aren't we supposed to get an email as usual when syncing a NEW package from debian?
[00:10] <Adri2000> the package correctly appears in the NEW queue, but I'd have expected to get an email saying that...
[00:11] <micahg> adri2000: yes, but there's a bug right now
[00:16] <Adri2000> hmm, ok
[00:20] <dupondje> https://launchpadlibrarian.net/92821119/snort2.debdiff
[00:20] <dupondje> should be fine now :)
[00:26] <arand> Hrm, it appears something which built cleanly in pbuilder-sid FTBFSes in ubuntu due to libfreetype6-dev missing... Are there any particular differences there between Debian and Ubuntu?
[00:27] <arand> (On Debian it is pulled in automatically)
[00:39] <TheMuso> ajmitch: Hrm so the upload was successful, but I don't see anything on revu... I wonder whether anything has gone amiss with revu and my GPG key...
[00:39] <ajmitch> quite likely, when did you last log into revu?
[00:40] <TheMuso> ajmitch: A few days ago to review/download a package.
[00:40] <TheMuso> Linux-lowlatency is the package in question. I am working with the studio devs to get it cleaned up.
[00:40] <ajmitch> and the last successful upload to revu from you?
[00:40] <TheMuso> 2009
[00:41] <TheMuso> According to my profile page.
[00:42] <ajmitch> probably before it was changed to fetch keys on log in
[00:42] <TheMuso> Hrm ok.
[00:43] <TheMuso> But having logged in a day or so ago would have addressed that, or so I would think.
[00:43] <ajmitch> that's what I'd think, I'm just digging in the database
[00:43] <TheMuso> ok thanks
[00:44] <arand> If I fixed this ubuntu-specific FTBFS (simply adding a missing depend), do I need to reupload to Debian first before sync-requesting?
[00:46] <ajmitch> 2012-02-14 01:15:02 - linux-lowlatency_3.2.0-15.24~ppa1_source.changes: Incorrect signature, moving to rejected.
[00:46] <ajmitch> not really useful
[00:49] <TheMuso> No.
[01:00] <micahg> arand: well, if the maintainer's responsive and there's no diff, sure, otherwise, let's upload to Ubuntu and submit it to Debian (assuming it's applicable)
[01:00] <arand> micahg: I'm the Debian maintainer in this case.
[01:00] <ajmitch> TheMuso: can you confirm the filesize of linux-lowlatency_3.2.0-15.24~ppa1.tar.gz that you uploaded?
[01:01] <micahg> arand: oh, well, if it's applicable in Debian, I'd suggest uploading there and then sync if we have no diff
[01:22] <TheMuso> ajmitch: In bytes, 104347701.
[01:28] <ajmitch> TheMuso: ok, so problably something funny going on with the upload processing due to it moving files out of the way
[01:29] <TheMuso> ok
[01:32] <ajmitch> TheMuso: I've reverted the change I did before to bind-mount things. this should let packages be fully uploaded now, afaict
[01:33] <TheMuso> ajmitch: Ok, should I try again?
[01:34]  * TheMuso tries.
[01:34]  * ajmitch hopes you've got a fast connection, that's not a small package to upload :)
[01:36] <TheMuso> I know. I've got 1.2mbps up.
[01:37] <ajmitch> ok, it's moved it into the base ftp dfirectory & the size is still increasing, so I guess it's sort of working as intended now
[01:37] <ajmitch> this part of revu is a bit fragile, it seems
[01:37] <TheMuso> Ok cool.
[01:37] <TheMuso> Indeed.
[01:38] <TheMuso> ajmitch: Thanks for your help.
[01:40] <ajmitch> no problem, I hope this finally works & you can help them out :)
[01:41] <ajmitch> sorry for the hassle
[02:04] <TheMuso> np
[06:50] <whumphrey> Anyone available to help a newer user to linux? Read the forums and how to's for installing a wireless adapter and have reached a point where I need help
[06:52] <whumphrey> please?
[06:55] <whumphrey> I really need help
[07:01] <whumphrey> Anyone available to help a newer user to linux? Read the forums and how to's for installing a wireless adapter and have reached a point where I need help
[07:03] <arand> !support | whumphrey
[07:04] <whumphrey> join #ubuntu
[07:05] <whumphrey> join /#ubuntu
[07:05] <whumphrey> join/ #ubuntu
[07:05] <whumphrey> join #ubuntu
[07:46] <dholbach> good morning
[09:26] <Laney> howdy
[09:29] <nigelb> O Hai Laney!
[09:30] <Laney> alreeeeeeeeeet?
[09:30] <nigelb> Not bad. You?
[09:32] <Laney> there is tea. therefore life is good.
[11:09] <Rhonda> Laney, micahg: would this be appropriate? http://paste.debian.net/156202/
[11:09] <Rhonda> Next step would be opening a bugreport against lucid-backports and attach the diff to it, right?
[11:10] <Laney> WFM, yeah. Same for M and N?
[11:11] <Rhonda> and O, yes
[11:11] <Laney> yes yes
[11:11] <Laney> alphabet fail
[11:11] <Rhonda> :)
[11:11]  * Rhonda whispers to Laney: we are at P already … ppsssst.
[11:13] <tumbleweed> M is getting pretty long in the tooth, only 2 months of support left...
[11:13] <Laney> good
[11:15] <Rhonda> hmm, then I guess I'll skip M
[11:15] <Rhonda> it's such a maverick anyway
[11:15] <Laney> nah, it's still valid for people to upgrade through it until EOL
[11:18] <Rhonda> so you only will approve lucid anyway if the full upgrade path through all releases is there?
[11:19] <Laney> that's what we ask for, yeah. Right now is the most burdensome period in the cycle for backports due to the number of supported releases
[11:20] <Laney> should just be a matter of changing the version though?
[11:20] <Rhonda> yes, is
[11:21] <Rhonda> and since I keep it in git there is not really an overhead involved (besides filing the bugs)
[11:21] <Laney> you can use one and just add tasks for all the relevant -backports projects
[11:22] <Rhonda> tasks?  Wouldn't I need to attach all the debdiffs?
[11:23] <Rhonda> "tasks?" mean I am unsure what you mean with the term in this context :)
[11:23] <Laney> well, you can have multiple attachments, but if they're all the same and you say they all work then I won't require you to do that
[11:23] <Laney> in Launchpad a bug can affect multiple projects
[11:24] <Laney> https://bugs.launchpad.net/maverick-backports/+bug/844697 like this one
[11:24] <Laney> use 'Also affects project'
[11:24] <Rhonda> I remember those.
[11:24] <Rhonda> … which made me unsubscribe from the irssi bugreports because of the perl transition. %-)
[11:24] <Laney> ^o)
[11:25] <Laney> these days you can mute mail from certain bugs
[11:25] <Rhonda> I know, followed that
[11:29] <Rhonda> Laney: and, <nitpicking>the diffs aren't the same, the changelog carries the release name</nitpick>
[11:30] <Laney> yeah. But that needs to be right, or the upload won't work. I can trust you on that (since you'll be the one uploading) ...
[11:30] <Rhonda> I upload?  I thought I just file the bugreport? :)
[11:30] <Laney> for source change backports, yeah
[11:30] <Rhonda> the UbuntuBackports wiki page doesn't go into much details for source change backports
[11:31] <Rhonda> So, I file the bugreport, and upload then, or the other way round?
[11:32] <Rhonda> If first bugreport, should I add LP:
[11:32] <Rhonda> If first bugreport, should I add LP: # into the changelog?
[11:32] <Laney> file report, attach diff (at this point you have the bug number), get approval, upload
[11:33] <Laney> then it'll be stuck in the queue for ScottK or someone to approve
[11:33] <Rhonda> k
[11:33] <Laney> the wiki page does say "If the backport does require source changes and the backports team has approved it, it can be uploaded via the same process as a normal Ubuntu archive upload", which I guess covers it
[11:35] <Rhonda> could be more to the point (filing bugreport against … and attach debdiff)
[11:35] <Rhonda> I seem to remember that the page actually _did_ contain the information where to report bugs against for the approval.
[11:36] <Laney> it got... what's the word?
[11:36] <Laney> 'rationalised' recently
[11:46] <Rhonda> doh, a bug number too early
[11:46] <Rhonda> it's 2011 at the end, so obsolete …
[11:58] <Rhonda> Laney, bug 932011
[11:58] <Rhonda> hmm
[11:58] <Rhonda> bug #932011
[11:58]  * Rhonda peeks at ubottu
[11:58] <Rhonda> LP #932011
[11:58] <Laney> http://pad.lv/932011
[11:58]  * Laney got an email about it too though
[11:59] <Rhonda>  http://deb.at/L932011 works too, but that's not the point :)
[11:59] <Laney> just did it for my own clickification
[11:59]  * Rhonda loves her deb.at redirects
[11:59] <Laney> we need a statement that it builds/installs/runs on target releases
[12:00] <geser> Laney: it easier to type it into IRC to be able to click instead of directly into the browser?
[12:00] <Rhonda> Right, will do that later, just wanted to get it off my chest for now
[12:00] <Laney> k
[12:00] <Laney> geser: about equal, and if I do it here then others can click too :-)
[12:01]  * Laney should play wesnoth one of these days
[12:24] <dupondje> jtaylor: fix for automysqlbackup got uploaded in debian, will sync later :)
[16:16] <scott-work> can i get someone to review a kernel package in REVU?  http://revu.ubuntuwire.com/p/linux-lowlatency
[16:17] <scott-work> we need one more approval before thrusday to get it into universe
[16:18] <tumbleweed> reviewing i a kernel package isn't something I'd take on lightly
[16:18] <tumbleweed> have you asked the ubuntu-kernel people?
[16:23] <Laney> I am very sure it would be much easier to maintain this package in collaboration with the kernel team indeed
[16:24] <Laney> for example I understand they use git? If they won't let it be built as a flavour from the main source package then it would be pretty easy to manage it as a separate branch there
[16:24] <Laney> then you could merge their changes very cheaply
[16:32] <scott-work> tumbleweed, Laney: i am working with the UKT, however, they maintain that this is a community kernel and therefore maintained by the "community", in this case, the ubuntu studio team
[16:32] <scott-work> the lowlatency kernel is based on directly on the current -generic kernel with only some flags changed, so no code is really different
[16:33] <scott-work> but since this is not an "official" kernel and therefore maintained by community, it will reside in the universe repository whcih is the purview of MOTU
[16:33] <scott-work> hence, getting two advocated is the gate keeper to this kernel being in the repos
[16:33] <tumbleweed> that sounds reasonable
[16:33]  * tumbleweed runs off
[16:34] <scott-work> i should also note, that per the blueprint a person from the kernel team should review the kernel as well, although they are most likely not MOTU (or at least i suspect will be the case)
[16:34] <Laney> So no kernel developer is willing to review it for you?
[16:34] <Laney> I expect the number of qualified MOTU to be vanishingly small
[16:35] <scott-work> Laney:  i haven't checked back in the channel yet, but there is still the issue of needing a MOTU to advocate it, unless an exception is made that a kernel team member would be allowed to advocate for it
[16:35] <Laney> I don't see why they couldn't
[16:49] <carif_> question for the channel: what are debian/*.debhelper.log files and are they "source files" or generated files as a result of a build?
[17:01] <pabelanger> Should I be worry about reformatting of debian/po files in my debdiff for bug 931859?
[17:02] <pabelanger> not sure why they we're affected
[17:02] <pabelanger> https://launchpadlibrarian.net/92875057/nagios3_3.2.3.debdiff
[17:48] <RainCT> didrocks: Hey :). Uploaded new zeitgeist, libzeitgeist and zeitgeist-datahub to Debian (zeitgeist to experimental).
[17:50] <didrocks> RainCT: excellent, I'll ask for a sync tomorrow morning, thanks! and congrats for the release :)
[18:09] <Rhonda> micahg, you tagged the ejabberd bug the same time I did call the syncpackage :)
[18:22] <tumbleweed> carif_: result of the build
[18:22] <carif_> tumbleweed, ty
[18:23] <arand> carif_: You can get rid of them with "debuild clean" or equivalent
[18:26] <carif_> another question, i have a cdbs pkg, but it has a debian/patches/series file; I thought that was only for quilt? is it needed for cdbs? If not, why would it be there?
[18:28] <jtaylor_> quilt and cdbs are not mutually exclusive
[18:28] <yofel> carif_: you can use cdbs together with quilt, quilt is just a patch system
[18:31] <carif_> jtaylor_, yofel, but only 1 patch sys is used in debian/rules? or does that depend on the rules file?
[18:32] <jtaylor_> in theory you can use more than one, but that would be a bad idea
[18:32] <yofel> it does depend on which you use, yes
[18:32] <jtaylor_> 3.0 packages automatically use something quilt like at unpack time
[18:32] <yofel> dh7 uses quilt by default, and doesn't recommend any other one
[18:33] <jtaylor_> dh7 not, only source/format 3.0 (quilt)
[18:33] <yofel> indeed, my error
[18:52] <carif_> jtaylor_, yofel, still a little confused. if my pkg is cdbs in the rules file, then debian/patches/series exists as a convenience to use quilt and perhaps to synthesize a new .patch file?
[18:54] <jtaylor_> is it a 3.0 package?
[18:58] <yofel> well, debian/patches/series is used by quilt to see in which order it should apply the patches that are listed there. And quilt has nothing to do with cdbs per se.If it's a 3.0 (quilt) package you'll be using quilt as patch system no matter what build system you use
[20:54] <micahg> ScottK: I forget, for backporting security updates for packages in backports, do I have to get someone to do the install/run tests again?
[20:56] <broder> micahg: my opinion is that you should only have to do b/i/r testing for the package itself, not rdeps
[20:59] <micahg> I'd buy that
[20:59]  * micahg will see if they guy that's been doing the puppet backport testing is up for another round
[20:59] <micahg> s/they/the/
[21:01] <ScottK> micahg: Install/run isn't very hard usually, but if you can't I wouldn't block on it.
[21:01] <ScottK> Technically a backport for a security update is just another backport.
[21:01] <micahg> which should technically require the same testing
[21:02] <ScottK> Although I'm always willing to be creative if there's a good reason.
[21:02] <micahg> ok, I think have someone to test, so it hopefully isn't an issue
[21:48] <broder> any uscan experts want to tell me whether this watch file (for watching a subdirectory of the kernel git tree) works? http://paste.ubuntu.com/842269/
[21:48] <broder> without really knowing what i'm looking at, i'm suspicious that it has to be updated every time the upstream source version changes
[21:56] <tumbleweed> broder: eek
[21:56] <broder> yeeeeaaaahh
[21:57] <tumbleweed> I don't understand it
[21:58] <tumbleweed> but your suspiciouns seem grounded. What's with all the hardcoded hashes
[21:58] <tumbleweed> also, watching hashes with uscan isn't going to work that well
[21:59] <broder> right
[22:00] <tumbleweed> I suspect its trying to treat one hash as 0-x and anything newer as 1-x. Still seems pretty crazy
[22:00] <tumbleweed> rather drop it than do that kind of things
[22:00] <tumbleweed> thing
[22:01] <broder> yeah, i'm inclined to agree. whatever - i don't think the package can be sponsored as-is without some additional information anyway, so it's out of the queue now
[22:02] <broder> also, i should probably stop doing ubuntu stuff during work hours :-P
[22:02] <tumbleweed> doing that entirely derailed my thesis
[22:19] <Corey> Is there a sane way to get git-buildpackage to spit out an orig.tar.gz?
[22:23] <tumbleweed> Corey: git-import-orig
[22:31] <Corey> tumbleweed: I've got a git repo that's got a debian directory in it, and builds a working package; now I'm trying to sanely hook it up to Jenkins for autobuild.
[22:31] <Corey> This is for an internal project, not something that'll ever see the public repos, unfortunately.  Although that does lower the bar a bit for package acceptance.
[22:32] <Laney> git-buildpackage -S?
[22:34] <Corey> Laney: dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at .. It'd seem not.
[22:34] <jtaylor> pristine-tar gentar?
[22:35] <jtaylor> asssuming you use --git-pristine-tar to import
[22:36] <jtaylor> that error is probably caused by that flag not being used :/
[22:37] <Laney> it should fall back to using the upstream branch in that case
[22:37] <jtaylor> it can't create the orig from the upstream without pristine information
[22:37] <jtaylor> I think
[22:38] <jtaylor> at least not with the same checksum
[22:38] <Laney> well, of course not that, but it can still do something
[22:38] <jtaylor> but thats sure not default
[22:39] <jtaylor> I wouldn't want my gbp to generate a wrong checksum tarball because I forgot to checkout the pristine branch from the remote :/
[22:39] <broder> Corey: are you saying that you have a debian directory in your main VCS repository?
[22:39] <broder> as opposed to doing the packaging separately from main development?
[22:40] <Corey> broder: Yes.
[22:40] <broder> i suspect that's the point of confusion for Laney and jtaylor
[22:40] <Corey> Ah.
[22:40] <Corey> Yes, in my repository's topdir, there's a topdir/debian directory with working package build instructions.
[22:41] <Corey> If I check that out into a new environment with the buildtools already installed, what do I have to do to create my package? :-)
[22:42] <jtaylor> git archive to create a tarball, exclude debian
[22:42] <jtaylor> then debuild or gbp should work
[22:43] <jtaylor> a native package is probably even more appropriate for autobuilds, then you don't need to exclude debian
[22:44] <jtaylor> --git-export=WC might also work, skips the tarball creation
[22:48] <jtaylor> hm no that does not work
[22:50] <jtaylor> ah yes it does
[22:50] <jtaylor> I had pristine enabled in my config
[22:51] <Laney> it does use upstream if you don't give --git-pristine-tar
[22:51] <Laney> gbp:info: pdfmod_0.9.1.orig.tar.gz does not exist, creating from 'upstream/0.9.1'
[22:52] <jtaylor> yes git-no-pristine-tar was required in my case
[22:52] <Laney> anyway I don't know how well merge mode is supported if that's what this is
[22:52] <Laney> it's not the usual gbp workflow
[22:54] <Corey> jtaylor: So the exact syntax is what exactly?  You've mentioned three tools and four flags or so. :-)
[22:55] <jtaylor> why don't you just run your regular release script to create a tarball?
[22:56] <jtaylor> else try git-buildpackage --git-export=WC --git-no-pristine-tar in your repository and see if that works
[22:58] <jtaylor> if that does not work: git-buildpackage --git-export=WC --git-no-pristine-tar  --git-upstream-branch=master --git-upstream-tree=branch
[22:59] <Corey> tumbleweed: Didn't, and the second one throws git-buildpackage: error: no such option: --git-upstream-tree
[22:59] <jtaylor> hm which version do you have?
[22:59] <jtaylor> older versions do not have that and must use tags
[22:59] <jtaylor> so tag your master and use --git-upstream-tag=sometag
[23:00] <jtaylor> a no you can use HEAD as a tag
[23:01] <Corey> *sigh*  dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at
[23:02] <Corey> This is on Lucid.
[23:02] <jtaylor> did gbp create one?
[23:02] <Corey> It did not.
[23:03] <jtaylor> let me try iton lucid, but maybe its too old and you're "stuck" with using git archive
[23:07] <jtaylor> works for me
[23:08] <jtaylor> keepass2_2.18+dfsg.orig.tar.gz does not exist, creating from 'HEAD'
[23:09] <jtaylor> my options: git-buildpackage --git-export=WC --git-no-pristine-tar  --git-upstream-tag=HEAD -S -us -uc
[23:09] <jtaylor> repo has only master branch and no tags
[23:11] <jtaylor> < off, bye
[23:11] <Corey> Thanks.