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:01 |
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:02 |
tumbleweed | (just like you list the patches you kept) | 00:03 |
Adri2000 | aren't we supposed to get an email as usual when syncing a NEW package from debian? | 00:09 |
Adri2000 | the package correctly appears in the NEW queue, but I'd have expected to get an email saying that... | 00:10 |
micahg | adri2000: yes, but there's a bug right now | 00:11 |
Adri2000 | hmm, ok | 00:16 |
dupondje | https://launchpadlibrarian.net/92821119/snort2.debdiff | 00:20 |
dupondje | should be fine now :) | 00:20 |
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:26 |
arand | (On Debian it is pulled in automatically) | 00:27 |
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:39 |
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:40 |
TheMuso | According to my profile page. | 00:41 |
ajmitch | probably before it was changed to fetch keys on log in | 00:42 |
TheMuso | Hrm ok. | 00:42 |
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:43 |
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:44 |
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:46 |
TheMuso | No. | 00:49 |
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:00 |
micahg | arand: oh, well, if it's applicable in Debian, I'd suggest uploading there and then sync if we have no diff | 01:01 |
=== Corey_ is now known as Corey | ||
=== nhandler_ is now known as nhandler | ||
TheMuso | ajmitch: In bytes, 104347701. | 01:22 |
ajmitch | TheMuso: ok, so problably something funny going on with the upload processing due to it moving files out of the way | 01:28 |
TheMuso | ok | 01:29 |
ajmitch | TheMuso: I've reverted the change I did before to bind-mount things. this should let packages be fully uploaded now, afaict | 01:32 |
TheMuso | ajmitch: Ok, should I try again? | 01:33 |
* TheMuso tries. | 01:34 | |
* ajmitch hopes you've got a fast connection, that's not a small package to upload :) | 01:34 | |
TheMuso | I know. I've got 1.2mbps up. | 01:36 |
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:37 |
TheMuso | ajmitch: Thanks for your help. | 01:38 |
ajmitch | no problem, I hope this finally works & you can help them out :) | 01:40 |
ajmitch | sorry for the hassle | 01:41 |
=== sikon is now known as lucidfox | ||
TheMuso | np | 02:04 |
=== nhandler_ is now known as nhandler | ||
=== JackyAlcine_ is now known as JackyAlcine | ||
=== almaisan-away is now known as al-maisan | ||
=== al-maisan is now known as almaisan-away | ||
=== Corey_ is now known as Corey | ||
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:50 |
whumphrey | please? | 06:52 |
=== aalex-home_ is now known as aalex | ||
=== almaisan-away is now known as al-maisan | ||
whumphrey | I really need help | 06:55 |
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:01 |
arand | !support | whumphrey | 07:03 |
ubottu | whumphrey: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only. | 07:03 |
whumphrey | join #ubuntu | 07:04 |
whumphrey | join /#ubuntu | 07:05 |
whumphrey | join/ #ubuntu | 07:05 |
whumphrey | join #ubuntu | 07:05 |
=== ondras_ is now known as ondras | ||
=== al-maisan is now known as almaisan-away | ||
=== aalex is now known as aalex-home | ||
dholbach | good morning | 07:46 |
=== almaisan-away is now known as al-maisan | ||
Laney | howdy | 09:26 |
nigelb | O Hai Laney! | 09:29 |
Laney | alreeeeeeeeeet? | 09:30 |
nigelb | Not bad. You? | 09:30 |
Laney | there is tea. therefore life is good. | 09:32 |
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:09 |
Laney | WFM, yeah. Same for M and N? | 11:10 |
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:11 | |
tumbleweed | M is getting pretty long in the tooth, only 2 months of support left... | 11:13 |
Laney | good | 11:13 |
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:15 |
Rhonda | so you only will approve lucid anyway if the full upgrade path through all releases is there? | 11:18 |
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:19 |
Laney | should just be a matter of changing the version though? | 11:20 |
Rhonda | yes, is | 11:20 |
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:21 |
Rhonda | tasks? Wouldn't I need to attach all the debdiffs? | 11:22 |
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:23 |
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:24 |
Laney | these days you can mute mail from certain bugs | 11:25 |
Rhonda | I know, followed that | 11:25 |
Rhonda | Laney: and, <nitpicking>the diffs aren't the same, the changelog carries the release name</nitpick> | 11:29 |
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:30 |
Rhonda | So, I file the bugreport, and upload then, or the other way round? | 11:31 |
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:32 |
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:33 |
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:35 |
Laney | it got... what's the word? | 11:36 |
Laney | 'rationalised' recently | 11:36 |
Rhonda | doh, a bug number too early | 11:46 |
Rhonda | it's 2011 at the end, so obsolete … | 11:46 |
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:58 | |
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 | 11:59 |
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:00 |
* Laney should play wesnoth one of these days | 12:01 | |
dupondje | jtaylor: fix for automysqlbackup got uploaded in debian, will sync later :) | 12:24 |
=== al-maisan is now known as almaisan-away | ||
scott-work | can i get someone to review a kernel package in REVU? http://revu.ubuntuwire.com/p/linux-lowlatency | 16:16 |
scott-work | we need one more approval before thrusday to get it into universe | 16:17 |
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:18 |
Laney | I am very sure it would be much easier to maintain this package in collaboration with the kernel team indeed | 16:23 |
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:24 |
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:32 |
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:33 | |
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:34 |
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:35 |
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? | 16:49 |
pabelanger | Should I be worry about reformatting of debian/po files in my debdiff for bug 931859? | 17:01 |
pabelanger | not sure why they we're affected | 17:02 |
pabelanger | https://launchpadlibrarian.net/92875057/nagios3_3.2.3.debdiff | 17:02 |
RainCT | didrocks: Hey :). Uploaded new zeitgeist, libzeitgeist and zeitgeist-datahub to Debian (zeitgeist to experimental). | 17:48 |
didrocks | RainCT: excellent, I'll ask for a sync tomorrow morning, thanks! and congrats for the release :) | 17:50 |
=== bkerensa_ is now known as bkerensa | ||
=== maxb is now known as Guest79372 | ||
=== medberry is now known as Guest1895 | ||
=== Guest1895 is now known as med_ | ||
Rhonda | micahg, you tagged the ejabberd bug the same time I did call the syncpackage :) | 18:09 |
=== mchro- is now known as mchro | ||
tumbleweed | carif_: result of the build | 18:22 |
carif_ | tumbleweed, ty | 18:22 |
arand | carif_: You can get rid of them with "debuild clean" or equivalent | 18:23 |
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:26 |
=== WaVeR` is now known as WaVeR | ||
=== nhandler_ is now known as nhandler | ||
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:28 |
carif_ | jtaylor_, yofel, but only 1 patch sys is used in debian/rules? or does that depend on the rules file? | 18:31 |
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:32 |
jtaylor_ | dh7 not, only source/format 3.0 (quilt) | 18:33 |
yofel | indeed, my error | 18:33 |
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:52 |
jtaylor_ | is it a 3.0 package? | 18:54 |
=== jtaylor_ is now known as jtaylor | ||
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 | 18:58 |
=== tobin is now known as joshuaAFK | ||
=== emma_ is now known as em | ||
=== em is now known as emma | ||
=== emma is now known as em | ||
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:54 |
broder | micahg: my opinion is that you should only have to do b/i/r testing for the package itself, not rdeps | 20:56 |
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/ | 20:59 |
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:01 |
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:02 |
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:48 |
tumbleweed | broder: eek | 21:56 |
broder | yeeeeaaaahh | 21:56 |
tumbleweed | I don't understand it | 21:57 |
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:58 |
broder | right | 21:59 |
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:00 |
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:01 |
broder | also, i should probably stop doing ubuntu stuff during work hours :-P | 22:02 |
tumbleweed | doing that entirely derailed my thesis | 22:02 |
Corey | Is there a sane way to get git-buildpackage to spit out an orig.tar.gz? | 22:19 |
tumbleweed | Corey: git-import-orig | 22:23 |
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:31 |
Laney | git-buildpackage -S? | 22:32 |
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:34 |
jtaylor | asssuming you use --git-pristine-tar to import | 22:35 |
jtaylor | that error is probably caused by that flag not being used :/ | 22:36 |
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:37 |
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:38 |
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:39 |
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:40 |
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:41 |
jtaylor | git archive to create a tarball, exclude debian | 22:42 |
jtaylor | then debuild or gbp should work | 22:42 |
jtaylor | a native package is probably even more appropriate for autobuilds, then you don't need to exclude debian | 22:43 |
jtaylor | --git-export=WC might also work, skips the tarball creation | 22:44 |
jtaylor | hm no that does not work | 22:48 |
jtaylor | ah yes it does | 22:50 |
jtaylor | I had pristine enabled in my config | 22:50 |
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:51 |
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:52 |
Corey | jtaylor: So the exact syntax is what exactly? You've mentioned three tools and four flags or so. :-) | 22:54 |
jtaylor | why don't you just run your regular release script to create a tarball? | 22:55 |
jtaylor | else try git-buildpackage --git-export=WC --git-no-pristine-tar in your repository and see if that works | 22:56 |
jtaylor | if that does not work: git-buildpackage --git-export=WC --git-no-pristine-tar --git-upstream-branch=master --git-upstream-tree=branch | 22:58 |
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 | 22:59 |
jtaylor | a no you can use HEAD as a tag | 23:00 |
Corey | *sigh* dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at | 23:01 |
Corey | This is on Lucid. | 23:02 |
jtaylor | did gbp create one? | 23:02 |
Corey | It did not. | 23:02 |
jtaylor | let me try iton lucid, but maybe its too old and you're "stuck" with using git archive | 23:03 |
jtaylor | works for me | 23:07 |
jtaylor | keepass2_2.18+dfsg.orig.tar.gz does not exist, creating from 'HEAD' | 23:08 |
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:09 |
jtaylor | < off, bye | 23:11 |
Corey | Thanks. | 23:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!