bdrung | tumbleweed: which is the branch that i should review first? | 00:00 |
---|---|---|
stevecrozz | i have a package that i've been maintaining in my ppa for a while, but I need the help of a mentor to whip it into shape so I can propose it be included in Ubuntu's main package repository | 03:56 |
stevecrozz | please send me a message if you are willing to lend a hand or just help me out with some guidance | 03:56 |
Bachstelze | stevecrozz: everything you need is in the packaging guide, if you have questions, just ask here :) | 03:58 |
stevecrozz | Bachsteize: The package is uwsgi and there has been some progress getting it into debian, but I'm not sure if I should follow that or just go my own way | 04:00 |
Bachstelze | stevecrozz: it's generally better to get new packages in Debian first | 04:01 |
Bachstelze | then they are automatically imported to Ubuntu | 04:01 |
stevecrozz | Bachstelze: how do I go about getting the package into debian? are there some other people I should talk to? | 04:04 |
stevecrozz | the technical details of actually creating a package that builds have been sorted out already, i just don't really know where to go from here | 04:04 |
jmarsden | Bachstelze: Debian Import Freeze for Natty was 30 Dec 2010, so packages are not automatically imported from Debian at the moment, you need to request a sync. | 04:04 |
Bachstelze | jmarsden: right, I was speaking in general | 04:05 |
jmarsden | stevecrozz: You may wany to check out http://mentors.debian.net/ and see if you can find a mentor to help get your package(s) into Debian? | 04:07 |
JanC | stevecrozz: if somebody else is already working on getting it in Debian, maybe best to help that person? | 04:07 |
stevecrozz | yeah, its just been really slow, i'm not sure what the holdup is, but I'm trying to resume communication with that person now | 04:08 |
stevecrozz | but i'll try that and check out mentors.debian.net too | 04:08 |
JanC | peopel in Debian might be busy preparing for the new Debian release | 04:09 |
Bachstelze | more info on debian mentoring is here http://wiki.debian.org/DebianMentorsFaq | 04:09 |
tumbleweed | bdrung: syncpackage | 06:33 |
=== almaisan-away is now known as al-maisan | ||
=== al-maisan is now known as almaisan-away | ||
=== almaisan-away is now known as al-maisan | ||
=== hannesw__ is now known as hannesw | ||
=== Guest13856 is now known as Lutin | ||
=== al-maisan is now known as almaisan-away | ||
=== almaisan-away is now known as al-maisan | ||
=== al-maisan is now known as almaisan-away | ||
=== almaisan-away is now known as al-maisan | ||
=== al-maisan is now known as almaisan-away | ||
slangasek | RainCT: hi there, I see that you're the primary author of https://wiki.ubuntu.com/MOTU/Packages/REVU/CheckList - can you explain why it says that a 'needs-packaging' bug is a requirement for REVU? | 15:45 |
slangasek | I don't understand why that's a requirement in an Ubuntu context, and don't find it mentioned anywhere else | 15:45 |
RainCT | slangasek: Right, it's not really a requirement. I put it there because it's likely that reviewers will complain about it. Feel free to reword that sentence. | 15:58 |
slangasek | RainCT: ok, thanks :) | 16:03 |
=== Quintasan_ is now known as Quintasan | ||
=== yofel_ is now known as yofel | ||
=== evilvish is now known as vish | ||
=== vish is now known as evilvish | ||
=== almaisan-away is now known as al-maisan | ||
=== al-maisan is now known as almaisan-away | ||
bcurtiswx_ | building w/o signing is bzr bd -?S what ? | 18:27 |
dholbach | bcurtiswx_, bzr bd -- -S -us -uc | 18:27 |
bcurtiswx_ | dholbach, thanks | 18:28 |
dholbach | after the "--" you can pass any dpkg-buildpackage arguments you like | 18:28 |
bcurtiswx_ | dholbach, Ok i'll man dpkg-buildpackage next time .. thx again | 18:30 |
dholbach | no worries | 18:32 |
geser | dholbach: isn't "bzr bd -S -- -uc -us" preferred? so that bzr-builddeb gets the -S | 18:33 |
dholbach | geser, james_w would know | 18:34 |
james_w | geser, there's some ugly code to cope with either | 18:36 |
tumbleweed | bdrung: I am now | 20:43 |
bdrung | tumbleweed: i started to review syncpackage-* | 20:44 |
bdrung | tumbleweed: 1) there are build errors: http://paste.debian.net/104566/ | 20:44 |
tumbleweed | aah, so missing build deps I guess (/me builds) | 20:45 |
bdrung | backportpackage: check_call -> show correct error message | 20:45 |
bdrung | (check the return value) | 20:46 |
bdrung | 3) the source package object should gain more functionality: package1.debdiff(package2) | 20:46 |
bdrung | 3b) src_pkg.check() | 20:46 |
bdrung | 4) should pull-debian-debdiff really unpack sources? | 20:47 |
tumbleweed | ok, so that error message, I agree check_call is buggy (putting a list in %s), is that the only issue with it? | 20:48 |
tumbleweed | otherwise, it does theck the return value | 20:49 |
bdrung | instead of using check_call, use call and print a error message if the call doesn't return 0 | 20:50 |
tumbleweed | bdrung: check_call in backport package is a local function, not subprocess | 20:51 |
tumbleweed | (well, wraps subprocess.call) | 20:51 |
bdrung | oh | 20:51 |
bdrung | i thought i would be subprocess.check_call | 20:51 |
tumbleweed | yeah, it's confusing :) (blame ebroder :P) | 20:52 |
bdrung | 5) archive.py: "d_source, d_version = os.path.basename(dscfile)[:-4].split('_')" doesn't work (the dsc could have a random name like foobar.dsc) | 20:55 |
tumbleweed | anyway, 3: sounds reasonable. 3b: what does that do? 4: it needs to unpack the package to walk the changelog (well, there we could play tricks here). I basically just copied the existing behavior | 20:56 |
bdrung | 4. ok | 20:57 |
bdrung | 3b: check -> verify | 20:57 |
tumbleweed | right | 20:58 |
bdrung | (for syncpackage) | 20:59 |
tumbleweed | 5. err, yes that is buggy, but there are still situations where we are going to need it, I think | 20:59 |
bdrung | 5. no. we have the dsc file, therefore we can get the information from the file content | 21:01 |
tumbleweed | ok | 21:01 |
bdrung | 6) the example package has a trailing space in d/rules | 21:03 |
bdrung | tumbleweed: 7) can't we generate the test source tarball on test time? | 21:04 |
tumbleweed | 6: yes. 7: yeah, I'm sure I considered this, but I can't think of any decent argumetns against it now. | 21:07 |
=== shadeslayer is now known as kshadeslayer | ||
ari-tczew | RainCT: now gbrainy 1.6.1 is available ;-) | 23:06 |
Wallch_Developer | Does someone here uses Gnome and have time to review a project? | 23:13 |
ari-tczew | Wallch_Developer: maybe ask in the day @ #ubuntu-desktop ? | 23:17 |
Wallch_Developer | i am still awake :P... ok i will also ask at ubuntu-desktop :) | 23:18 |
kklimonda | do you have to test software to actually advocate it? If it builds, installs, then there is a pretty good chance that the person who has packaged it also made sure that it works. Especially if the upstream is active and interested in getting package to Ubuntu. If the detailed testing is a requirenment for the package advocacy then getting some niche projects into Ubuntu is going to be nearly | 23:31 |
kklimonda | impossible. | 23:31 |
kklimonda | tumbleweed: are you still working on updating python-musicbrainz2 and packaging beets for debian? | 23:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!