| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| Laney | nigelb: I see you offered gwibber help in debian #573822 (reminded by http://identi.ca/notice/88168234) — want sponsorship? :-) :-) | 10:52 |
|---|---|---|
| ubottu | Debian bug 573822 in wnpp "RFA: gwibber -- microblogging client for GNOME" [Normal,Open] http://bugs.debian.org/573822 | 10:52 |
| * Laney grins | 10:52 | |
| iulian | Good Laney! | 11:07 |
| iulian | He always has something to offer. | 11:08 |
| Laney | I live to please. | 11:08 |
| Daviey | poor nigelb | 11:10 |
| Laney | Ongoing (regular) maintenance might not be that hard if a bzr branch gets set up which we can merge the Ubuntu packaging branch with… | 11:13 |
| * Laney looks aruodn | 11:14 | |
| jtaylor | I wonder how wakeup made it into the archive, that thing is full of security holes | 13:15 |
| Laney | let me guess | 13:17 |
| Laney | ...an Ubuntu local package? | 13:17 |
| jtaylor | yes | 13:17 |
| Laney | funny | 13:17 |
| jtaylor | saw dozens of potential issues and one definite priv escl. just by looking at a diff ... | 13:18 |
| Laney | If only we had a good policy for kicking out shoddy apps | 13:20 |
| Laney | in Debian it would be RC bugs and therefore not released | 13:20 |
| tumbleweed | I don't ithkn we need one, kick it | 13:21 |
| stgraber | file a package removal bug (after contacting whoever got the package in Ubuntu in the first place) | 13:21 |
| Laney | absolutely it can be done, but having a policy gives things more weight, no? | 13:21 |
| tumbleweed | we should review ubuntu-only packages with high severity bugs once a cycle or so | 13:21 |
| Laney | and lets people stop them getting in | 13:21 |
| tumbleweed | well, we're working hard on that :) | 13:22 |
| tumbleweed | we stop anyone getting anything in :P | 13:22 |
| * Laney can think of another time we failed ... | 13:22 | |
| * Laney coughs | 13:22 | |
| tumbleweed | that wasn't actually dangerous, just low quality | 13:23 |
| tumbleweed | I thought micahg was going to find a serious security problem in it? :) | 13:23 |
| Laney | well I would probably put the barrier at a different place :P | 13:24 |
| Laney | argh I grepped for sudo in wakeup's source | 13:26 |
| tumbleweed | ubuntu-dev-tools also overuses sudo a bit :/ | 13:27 |
| tumbleweed | (but safely, I think) | 13:27 |
| jtaylor | sudo + predicatable tmpfilename = bad | 13:27 |
| jtaylor | see data/scripts/wakeup | 13:28 |
| jtaylor | data/scripts/wakeup +67 | 13:28 |
| Laney | maybe ARB does have a use :-) | 13:29 |
| jtaylor | and it uses os.system all over the place with non constant arguments | 13:29 |
| jtaylor | though the author is responsive, it could be fixed | 13:29 |
| tumbleweed | yeah, I suspect we need a repo somewhere for everyone to upload their junk to, to get their warm fuzzy feelings, before they become competant, trustworthy developers | 13:31 |
| === almaisan-away is now known as al-maisan | ||
| * tumbleweed wonders if anyone has ever used a signed .changes file from -changes to mess with another developer's PPA | 14:42 | |
| psusi | you mean upload the same package they uploaded to main into their ppa? | 14:43 |
| Laney | yes, I did once, to demonstrate why it was bad | 14:43 |
| Laney | where are you seeing a signed one? | 14:43 |
| tumbleweed | -changes has signed .changes files | 14:43 |
| Laney | heh | 14:44 |
| tumbleweed | psusi: yeah, you'd have to use the upload url mangling trick to do any real damage, though (to put it into a release that didn't have that version) | 14:44 |
| tumbleweed | Laney: glad to see I'm not the first person to wonder this :) | 14:44 |
| Laney | the case I got it fixed for was from +queue | 14:44 |
| Laney | this was ages ago | 14:44 |
| savvas | is the symbols file required for a debian library package? | 14:51 |
| jtaylor | not required but strongly recommended | 14:51 |
| savvas | thank you :) one more question: how do I file a new bug needs-packaging? Because now +filebug in launchpad redirects me to use ubuntu-bug and I cannot file a bug report without a package name | 14:54 |
| Ampelbein | savvas: https://bugs.launchpad.net/ubuntu/+filebug shouldn't redirect to ubuntu-bug. | 15:05 |
| Laney | yes it should | 15:05 |
| Laney | you need to add ?no-redirect to that URL unless you are in bug control | 15:05 |
| Ampelbein | ... That's interesting, thanks. | 15:06 |
| savvas | thank you! | 15:06 |
| === al-maisan is now known as almaisan-away | ||
| softcoder | anyone here know who to ask about debian games getting puleld into ubuntu? | 16:35 |
| tumbleweed | what's the question? | 16:36 |
| softcoder | I worked with pabs and got megaglest to replace glest, its been in debian testing since jan 2 but it never got puleld into ubuntu | 16:36 |
| softcoder | just wondering why not (pabs also thought it was strange) | 16:37 |
| tumbleweed | it's a new package | 16:37 |
| tumbleweed | they have to be manually reviewed | 16:37 |
| tumbleweed | give it time | 16:37 |
| softcoder | gotcha, its not really new, its a 'transition' or replacement | 16:37 |
| tumbleweed | right, but that still means it has to go through the NEW review | 16:38 |
| softcoder | ok, how long does that process usually take? | 16:38 |
| tumbleweed | < 1 month. Someone should do a final cleanup of new around DIF | 16:39 |
| softcoder | ok thx for the info | 16:39 |
| micahg | nothing in NEW ATM, we need the new package sync first :) | 16:42 |
| tumbleweed | well, for new packages from debian the review happens before the source upload | 16:42 |
| micahg | not AIUI, they just get stuck in NEW and there they have to be reviewed | 16:43 |
| ahasenack | hi guys, can someone take a look at this merge proposal for python-tz? https://code.launchpad.net/~ahasenack/ubuntu/precise/python-tz/day-leap-fix-885163/+merge/87407 | 16:52 |
| === yofel_ is now known as yofel | ||
| ahasenack | hi, can someone take a look at this merge proposal, or should I ask in #ubuntu-motu, since it's a universe package? https://code.launchpad.net/~ahasenack/ubuntu/precise/python-tz/day-leap-fix-885163/+merge/87407 | 18:05 |
| broder | ahasenack: i can look at it. one moment | 18:17 |
| broder | (you are asking in #ubuntu-motu, though :-P) | 18:18 |
| ahasenack | broder: thanks | 18:18 |
| ahasenack | broder: oh, I thought that second question was in #ubuntu-devel, I got my tabs mixed :P | 18:18 |
| broder | ahasenack: in the interests of getting a simple test that i can understand, tz=pytz.timezone('Pacific/Apia'); datetime(2012, 1, 1, tzinfo=tz) - datetime(2011, 12, 30, tzinfo=tz) == 1, right? As opposed to now, when it's 2? | 18:23 |
| ahasenack | broder: you mean, besides the backtrace test I pasted in the comments? | 18:24 |
| broder | ahasenack: aha, got it | 18:25 |
| broder | tumbleweed, bdrung: :-/ sponsor-patch started calling debuild with --no-lintian, which oneiric's debuild doesn't support | 18:28 |
| bdrung | broder: really? | 18:30 |
| broder | uh...hmm | 18:31 |
| broder | it does look like it has it doesn't it? | 18:31 |
| broder | i wonder what my laptop was whining about | 18:31 |
| bdrung | broder: i am running oneiric with latest u-d-t without having problems | 18:32 |
| broder | bdrung: yeah, i think something else went wrong. will dig into it later. looks like a false alarm for the moment, though | 18:33 |
| broder | ahasenack: uploaded | 18:35 |
| ahasenack | broder: that's precise, right? | 18:35 |
| broder | right | 18:35 |
| ahasenack | broder: thanks! | 18:35 |
| broder | ...i was going to open the sru bug tasks for that bug, but apparently i can't. wtf' | 18:35 |
| ahasenack | broder: yeah, we have to ask someone for that | 18:35 |
| ahasenack | broder: but let me prepare the sru template first | 18:35 |
| ahasenack | broder: with justification, impact, etc | 18:35 |
| broder | ahasenack: unless something changed very recently, motu could open the bug tasks | 18:36 |
| broder | oh, i see. i'm looking at the upstream bug task | 18:36 |
| * broder glares at lp | 18:36 | |
| broder | ahasenack: ok. tasks are open | 18:38 |
| ahasenack | broder thanks | 18:38 |
| ahasenack | broder: can you also take the review from that mp? It's still "pending" | 18:51 |
| broder | ahasenack: it got marked as merged | 18:51 |
| ahasenack | broder: yeah, but the review request itself is still pending: Ubuntu branches: Pending requested 2012-01-03 | 18:52 |
| broder | i've merged the branch - any review would just be a formality. the mp should fall off the sponsorship queue the next time it runs, because its state isn't "needs review" | 18:52 |
| ahasenack | ah, ok | 18:53 |
| l3on | Hi all.. I'm looking at a orphaned package, in the many lintian errors I see: | 19:02 |
| l3on | W: ferret: command-with-path-in-maintainer-script postinst:18 /usr/bin/update-mime-database | 19:02 |
| l3on | and in postinst I have: | 19:02 |
| l3on | # Deregister our X Desktop Group Shared MIME-info Database info | 19:02 |
| l3on | if [ -x /usr/bin/update-mime-database ] ; then | 19:02 |
| l3on | /usr/bin/update-mime-database /usr/share/mime | 19:02 |
| l3on | fi | 19:02 |
| l3on | is it still necessary update mime ? | 19:02 |
| l3on | does someone of you know how can I fix it? | 19:03 |
| jtaylor | does it use debhelper? | 19:03 |
| jtaylor | if yes dh_installmime will fill postinst correctly | 19:04 |
| jtaylor | with is something like this: http://paste.ubuntu.com/795189/ | 19:04 |
| l3on | jtaylor, I use dh 8, yes :) | 19:06 |
| l3on | jtaylor, so, have I to delete those lines from postinst, right? | 19:07 |
| jtaylor | if you use dh_installmime their probably redundant and can be removed | 19:07 |
| jtaylor | l3on: ukopp and dkopp ftbs in precise due to a zfuncs.h issue, did you get my mail? | 19:07 |
| l3on | jtaylor, yeeeepppp you're right! | 19:08 |
| l3on | damn it :/ | 19:08 |
| l3on | I'll look at them i | 19:08 |
| l3on | in one hour | 19:08 |
| jtaylor | upstream said he'll release a new version 1. jan if you could package that and add it to debian that would be great | 19:08 |
| jtaylor | but its not very urgent | 19:08 |
| l3on | well, considering that debian import freeze is coming... :P | 19:09 |
| l3on | lol | 19:09 |
| jtaylor | we can still sync manually | 19:09 |
| l3on | ah oki :) | 19:09 |
| l3on | sorry for not reply, but when I received mail I was in holydays with family and a little bit busy :/ | 19:10 |
| l3on | jtaylor, anyway... my ferret rules is like: | 19:10 |
| l3on | # Deregister our X Desktop Group Shared MIME-info Database info | 19:10 |
| l3on | if [ -x /usr/bin/update-mime-database ] ; then | 19:11 |
| l3on | /usr/bin/update-mime-database /usr/share/mime | 19:11 |
| l3on | fi | 19:11 |
| l3on | opsss... sorry: | 19:11 |
| l3on | %: | 19:11 |
| l3on | dh $@ | 19:11 |
| l3on | I suppose that dh_installmime is called somewhere | 19:11 |
| tumbleweed | easy enough to find out :) | 19:11 |
| jtaylor | make sure the postinst contains the debhelper token | 19:12 |
| jtaylor | (lintian will warn if not) | 19:12 |
| nigelb | Laney: I do want to help, when I find more time. Currently packed schedule. | 19:43 |
| Alison_Chaiken | Greetings all, my project needs a newer version of another project than upstream is offering as a package. | 20:18 |
| Alison_Chaiken | I want to use the recommended procedure to address this problem, assuming I can understand it. | 20:18 |
| Alison_Chaiken | From reading the Policy, I have the impression that I can package master/HEAD of project foo and distribute it with my other packages, as long as I use debian/watch to update when the latest foo is offered by upstream as a package. | 20:19 |
| Alison_Chaiken | Is this more or less correct? | 20:20 |
| Alison_Chaiken | I understand that what I want to avoid is that a year from now, my users have the old version of foo that I distribute today -- we want them to get an upstream update when it's available, which may not be long for all I know. | 20:21 |
| Alison_Chaiken | I see that when I git-pull the last tagged release of an upstream, I get their debian directory. | 20:27 |
| tumbleweed | Alison_Chaiken: why do you need a newer version? massive changes or a single patch? | 20:27 |
| Alison_Chaiken | When I pull master/HEAD, I don't get one. | 20:27 |
| tumbleweed | Alison_Chaiken: is this upstream a package in Ubuntu, or are we talking about a PPA | 20:27 |
| Alison_Chaiken | tumbleweed, one of my collaborators sent a patchset to the upstream, which they liked, but which is not yet part of a release. | 20:28 |
| tumbleweed | we can just cherry-pick that patch for Ubuntu | 20:28 |
| Alison_Chaiken | My packages are in a PPA; what I'm patching is qjson, which is the RESTful part of Qt. | 20:28 |
| tumbleweed | right, qjson is part of debian & ubuntu | 20:29 |
| tumbleweed | you can just package the latest head of it in your PPA | 20:29 |
| tumbleweed | as it's a PPA, don't worry about the watch file, just make an orig tarball from the latest upsteram HEAD | 20:29 |
| tumbleweed | (or cherry-pick that patch, for a qjson upload to your ppa) | 20:30 |
| Alison_Chaiken | I can just git-pull master/HEAD from qjson and then debuild it? | 20:30 |
| Alison_Chaiken | I upload it to my ppa and call it . . . qjson? | 20:31 |
| jtaylor | use an appropriate version number, e.g. one that replaces current ubuntu package but would get replaced by next one | 20:31 |
| tumbleweed | rather try and create a .orig.tar.gz from upstream HEAD, and treat it as if it was an upstream release | 20:31 |
| tumbleweed | but with a version number like 0.7.1+git20110106 | 20:31 |
| Alison_Chaiken | Upstream is at 0.7.1; I could package their master/HEAD and call it 0.7.1.1 so that when 0.7.2 is released by them, users are offered an update? | 20:32 |
| tumbleweed | Alison_Chaiken: that looks like an upstream version, though | 20:33 |
| tumbleweed | it's better to make it clearer that you packaged a random revision | 20:33 |
| Alison_Chaiken | tumbleweed, I had called the package I already uploaded qjson-`git rev-parse HEAD` but that broke all our project's build machinery: nothing linked against it. (Duh, in retrospect.) | 20:33 |
| tumbleweed | but again, this is a PPA, it doesn't really matter so much :P | 20:33 |
| Alison_Chaiken | Learning right procedure is good though. | 20:34 |
| tumbleweed | yeah, don't change the package name | 20:34 |
| Alison_Chaiken | I don't want to do something stupid just because I can! | 20:34 |
| tumbleweed | and don't use a git hash in a version, they don't increment | 20:34 |
| Alison_Chaiken | I could just solve the problem with the usual cascade of symlinks in /usr/lib of course, too, and make postinst or whatever that script is called do the right linking. | 20:35 |
| Alison_Chaiken | But I'm having trouble figuring out what the cool kids do here, since this problem obviously arises every day for everyone. | 20:35 |
| tumbleweed | err, why the symlinks in /usr/lib? | 20:36 |
| Alison_Chaiken | I could symlink qjson-123ac.so.1.0.0 to qjson.so in /usr/lib. | 20:36 |
| tumbleweed | oh, did it require an ABI change? | 20:36 |
| Alison_Chaiken | But users still wouldn't be offered an update when 0.7.2 actually is released. | 20:37 |
| Alison_Chaiken | No, no, no ABI change: sorry to be misleading. | 20:37 |
| Alison_Chaiken | What I actually did so far is package master/HEAD and call the package qjson-712b15 and put it in my ppa. | 20:38 |
| Alison_Chaiken | It installs fine, but the other binaries didn't link against it, due to the stupid name, even though apt knows they depend on it. | 20:39 |
| tumbleweed | right, don't rename it :) | 20:39 |
| tumbleweed | you can keep the same name as debian | 20:40 |
| Alison_Chaiken | I created my debian directory from the dh_make templates. Perhaps what I need to do to have a happy ending is to copy upstream's debian directory and (ahem) properly amend it to reflect my use of HEAD? | 20:41 |
| tumbleweed | yes | 20:41 |
| tumbleweed | it's really just like any other modification ubuntu makes, from debian | 20:41 |
| Alison_Chaiken | So if I call my package libqjson0, as Ubuntu does, and use qjson's debian directory and just change their metadata, that's cool? | 20:43 |
| Alison_Chaiken | And my users will be offered new qjson when it drops? | 20:44 |
| tumbleweed | yes | 20:44 |
| Alison_Chaiken | When they install my main package, which depends on libqjson0, I just need to make sure they get the one in my ppa, not the upstream. | 20:45 |
| Alison_Chaiken | I guess if the names are the same, that's the tricky part. | 20:46 |
| jtaylor | thats what version numbers are there :) | 20:47 |
| Alison_Chaiken | But maybe that dance has to do with configuring the PPA, not the package. | 20:47 |
| jtaylor | Depends: libqjson0 (>= 0.7.1+gitwhatever) | 20:47 |
| Alison_Chaiken | In the control file of the other packages, I see. | 20:48 |
| jtaylor | though thats also not so great in the case of a soname bump | 20:48 |
| Alison_Chaiken | So my package is called libqjson0, but the version is set in the metadata . . . like debian/changelog?! | 20:48 |
| jtaylor | yes first line of the changelog | 20:49 |
| Alison_Chaiken | Oh, so all I have to do is change the version number of the changelog? | 20:49 |
| jtaylor | add a new entry with dch -vnewversionnumber | 20:49 |
| Alison_Chaiken | Excellent! Packaging is easy ;-) | 20:50 |
| Alison_Chaiken | Thanks very much tumbleweed and jtaylor. | 20:50 |
| jtaylor | if you only have to patch an existing one its very simple | 20:50 |
| Alison_Chaiken | As I said, it's much easier to understand how to turn the crank on these programs than to do figure *what* to do sometimes. | 20:50 |
| tumbleweed | yeah, cherry picking is probably simpler than HEAD, if the patch applies cleanly | 20:51 |
| Alison_Chaiken | I'm off to read "dch --help" or "man dch" or whatever. | 20:51 |
| jtaylor | its just a convinience program to add a correctly formated changelog entry | 20:51 |
| Alison_Chaiken | WIll do, tumbleweed. | 20:51 |
| Alison_Chaiken | jtaylor, I already noted that debuild is picky about changelog format! | 20:52 |
| tumbleweed | Alison_Chaiken: here's an example where I've supported generating both released and VCS builds with get-orig-source: http://anonscm.debian.org/viewvc/python-apps/packages/ibid/trunk/debian/rules?revision=7444&view=markup | 20:52 |
| Alison_Chaiken | Thank you very much, tumbleweed. I *think* I grok all this now. I will study your example. | 20:53 |
| tumbleweed | (that one uses revision numbers rather than dates) | 20:53 |
| Laney | nigelb: heh, OK. :-) | 22:17 |
| ockham | is there any such a thing as a debian import (sync) queue? or are debian packages from testing (or unstable, for not-LTS releases) just part of the regular ubuntu upload queue? | 22:56 |
| tumbleweed | new packages? | 23:00 |
| lifeless | ockham: they are mirrored across by an automatic process, no human accessible queue is involved; things that fail do need to be worked through, and that report is (or was anyhow) on MoM | 23:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!