ESphynxhey guys01:48
ESphynxmicahg xnox ping01:48
micahghi ESphynx01:48
ESphynxhi :) So, finally! I have some time !01:49
micahgI'll have more Sat night :)01:49
ESphynxcool... care to tell me real quick though01:49
ESphynxbasically, there are a few bugs that have been fixed... so I'm planning to just go over all commits and isolate everything that is a bug fix01:49
ESphynxand then test the result... is that basically OK for the SRU?01:50
micahgESphynx: well, bug fix + test case in an LP bug01:50
ESphynxhmm, so I'd have to go and create an LP bug for each?01:51
micahgusually, it's one issue per bug to track if things go wrong01:51
ESphynxI see that, but these are bugs that have been fixed upstream :P01:52
micahgwell, presumably if it's being SRUd and doesn't have a microrelease exception, the bug is an annoyance for someone01:54
micahgthey need test cases and must be verified on the packages built in proposed01:56
ESphynxmicahg: well the major bug, as you might recall, is that it doesn't install on 64 bit releases at all01:57
micahgESphynx: yeah, that can be cherry picked and should be easy enough to write a test case for :)01:57
ESphynxbut since we're bothering making an SRU, I thought I'd throw in fixes for all the bugs I've ran across since.01:57
ESphynx(Some of which surely deserving to be fixed)01:58
micahgsure, as long as it's a minimal fix with little risk and you're willing to do the paperwork, I don't see why not01:58
ESphynxwell, not so set a precedent, but Quantal was the first version including Ecere :P and I don't know how many users started using yet, especially that it wasn't installable on 64 bit and most people install on 64 bit these days :)02:01
ESphynxand these fixes lower risk more than anything else... Paperwork -- I would like to have a clue what I'm getting into ... Is the size of the paperwork going to proportional to the number of bugfixes I include? ;)02:02
micahgyes, https://wiki.ubuntu.com/StableReleaseUpdates#Procedure , see #302:02
ESphynxCan I pack these together into 1?02:04
micahgESphynx: you can keep https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions in mind if you think ecere upstream is worthy02:04
ESphynxregression tests... hope to have these one day ;)02:05
xnoxESphynx: so do you have the binary package name conflict fix?02:05
ESphynxxnox: that's what I'm gonna hit first.02:06
ESphynxxnox: We had determined that it would be up to ecere to be renamed I guess? ;) And not elliptic curves? ;)02:06
xnoxESphynx: as soon as you have it, shout out. I'll review and sponsor it quickly =) as that's a bit urgent.02:06
ESphynxI guess that stems from me being in experimental while elliptic curve is in unstable? ;)02:07
xnoxESphynx: yes, unfortunately =)02:07
ESphynxok. xnox I'm starting on that right about now02:07
ESphynxjust wrestling a bit with micahg here to try to get a MRE for Quantal SRU :P02:07
xnoxnah, you won't get MRE that easy.02:07
ESphynxmicahg: a provisional (one-time) MRE really sounds like the best solution to me... Since the main reason is that it's uninstallable on 64 bit...02:08
xnoxSRU is easier. for MRE you need to show an existing string of SRU typically.02:08
micahgright, and if upstream has no regression tests, that won;t fly02:08
xnoxESphynx: being uninstallable is savere, just prepare the debdiff and file a regular SRU.02:08
ESphynxI think I'll just forget about Quantal otherwise.02:08
ESphynxbetter luck with Raring.02:08
xnoxfix the clash & I might help you do the SRU for quantal.02:09
ESphynxI know you guys offer your help (and I greatly appreciate that)02:09
micahgESphynx: fair warning, attitudes like that don't encourage others to help...02:09
micahg(MRE or else...)02:09
ESphynxmicahg: oh, it's not an attitude thing. sorry , didn't mean it that way02:09
micahgok :)02:10
ESphynxmicahg: it's just a matter of making the most of my very limited time02:10
ESphynxmicahg: e.g. I would like to get proper 64 bit support going02:10
ESphynxand when Raring comes out this problem will have magically dissappeared :P02:10
micahgESphynx: that's quite understandable, I'd suggest focusing on the high priority bugs and backport a new feature version02:10
ESphynx(not because of 64 bit suppor t( i hope to get that going too), but because it's already fixed in Raring...02:11
ESphynxmicahg: so, with that in mind, should I still bother with an SRU?02:11
ESphynxand if so, should I just do the installability one? or should I do one for all the bugs I deem severe?02:12
micahgyes, especially for the installability issue02:12
micahgI'd suggest for anything severe02:13
micahgbut your time is yours02:13
micahgpaperwork isn't that bad if you understand the issue at hand02:13
ESphynxyes... but I do want to try to fit in to the Ubuntu project02:13
ESphynxbut hmm, is that going to be just 1 SRU? or multiple?02:14
micahgyour choice02:14
ESphynxif it fixes multiple bugs? And I should file multiple issues in LP?02:14
ESphynx(all associated with the same SRU?)02:14
micahgmultiple bugs, one debdiff (choose which bug and note on the others)02:14
ESphynxfor the https://wiki.ubuntu.com/StableReleaseUpdates#Procedure02:15
ESphynxdebdiff which fixes this is attached to bug #xxxxxx" -- I see. I'll try to figure that out when I get there.02:16
ESphynxso... for now, I'm going to create a special branch just for this 'sru' process here02:16
ESphynx1 commit per bug fix would be best?02:17
micahgwell, I always suggest that, but you'll want the commits as patches02:17
ESphynxand I should create the bugs on LP with the information as specified there02:17
ESphynxas patches?02:17
micahgpatches against the source02:18
ESphynxmeaning the original source?02:18
ESphynxi.e. one bug fix can't depend over the other, is it?02:18
micahgwell, I mean quilt patches02:18
ESphynx(that's where stuff gets tricky, I got tons of this already which is why I need to start over again already...)02:19
ESphynxright the instability fixes I did depends on improvements to the build system02:19
ESphynxright now*02:19
micahgyeah, so you'll want a quilt patch for those build system fixes02:19
micahgand one patch for each fix02:20
ESphynxwell yeah I'm going to try to isolates stuff and make it a single commit02:20
ESphynxbut I was going to do the other fixes as commits on that same branch as well... but you're saying it really should be on the original source?02:20
micahgbranch, sure, source, no, use patches against the source, the patches are stacked one on another02:21
ESphynxso it's ok is all the bug fixes depends on the previous one?02:21
micahgyeah, just note which are dependent in case they need to be yanked02:22
ESphynxk, well I was just saying, but they really sohuld be independent...02:22
ESphynxso how's that I'm going to isolate important bug fixes (starting with the uninstallability one), and I'll file LP bags for them02:23
ESphynxand I'll reconvene with you on Saturday evening to see how we can get this moving :)02:23
micahgdepends on what files change in each patch, it might make sense in the way they are stacked02:23
ESphynx(or just drop you a line so you can take a look at your earliest convenience :))02:23
ESphynxwell they are going to be stacked in the order of the branch anyways...02:24
ESphynxk, thanks a lot02:24
ESphynxxnox: is this going to be a new release for debian?02:25
ESphynxmicahg: Should I also include this package change for Quantal? the libec package needs to be renamed to libecerec or something similar02:26
ESphynxdue to a conflict with the elliptical curve library in debian/unstable :P02:26
micahgESphynx: I don't think that conflict exists in quantal02:27
ESphynxmicahg: It doesn't for quantal but will for raring or later?02:27
ESphynxbut wouldn't it be best to fix it already?02:27
xnoxESphynx: name-change for debian. no need for name-change in quantal. raring will just get a synced package from debian.02:28
micahgbut only raring needs the fix02:28
xnoxESphynx: so just make a new debian - and i'll sponsor it into debian & sync it into raring.02:28
ESphynxxnox: should this be a minimal fix or can I just release a mini version with latest?02:30
xnoxESphynx: new debian can be anything you want =)02:30
xnoxESphynx: but with name-change fix please ;-)02:30
ESphynx'fair enough. then I'll fix a couple things and test it a bit. yes name change fix of course :)02:31
ESphynxI'll try to get both of these things done by tomorrow!02:31
micahgESphynx: don't forget a breaks/replaces on the older version # of libec0  when you do the rename, should make upgrades to raring work fine as well02:40
ESphynxmicahg: where does that go? control file?02:40
ESphynxk, thanks for mentioning ;)02:41
micahgESphynx: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces02:41
ESphynxah ok, great02:42
micahg(that whole page is worth reading)02:42
ESphynxmicahg: the library is still going to be named the same though ... (except a symlink is going to dissappear)02:42
micahgESphynx: I thought you were renaming libec0 to not conflict with the otehr thing02:43
ESphynxmicahg: I am... so I'm getting rid of /usr/lib/libec.so*  , but keeping /usr/lib/ec/libec.so02:43
micahghrm, I was referring to the binary package02:44
ESphynxyes , the package is going to get renamed... but the library .so file is going to keep the same name02:44
ESphynxme and xnox already agreed on a lintian override to silence the warning :P02:45
micahgthat's fine, I was noting the breaks/replaces for the binary rename02:45
ESphynxyeah ... will it 'break' though?02:45
ESphynx(doesn't it just replace?)02:46
micahgESphynx: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks for reasoning02:48
=== dk_ is now known as dk
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
dholbachgood morning07:53
jackyalcinemorning dholbach08:13
dholbachhi jackyalcine08:13
=== yofel_ is now known as yofel
=== almaisan-away is now known as al-maisan
=== zequence_ is now known as zequence
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
alo21if I download a source which has patches (via pull-debian-source), and I open a file which has a patch, Is the file patched yet when I open the file with gedit?16:47
Laneyalo21: that depends on the patch system in use16:49
Laneyis there a debian/source/format file?16:49
alo21Laney, yea... 3.0.016:52
Laney3.0 (quilt)?16:52
Laneyso yes, with that they should be applied16:52
Laneyyou should have seen a message to that effect when pull-debian-source extracted the package for you16:53
alo21Laney, and if there is a dpatch?16:53
alo21in fact I got that message16:53
Laneyyou wouldn't expect to see that in a 3.0 (quilt) package16:53
alo21Laney, well16:54
Laneybut: dpatch apply16:54
alo21and during pbuilder --build, all patch are applied. Right?16:55
Laneyif they're correctly in the series file16:56
alo21Laney, I have two build logs. One compiled with 'cc -lX11  yeahconsole.o   -o yeahconsole' and failed. another compiled with 'cc  yeahconsole.o   -o yeahconsole -lx11' and succeeded.16:58
alo21how can I decide the order of the arguments16:59
=== [ESphynx] is now known as ESphynx
=== e11bits_ is now known as e11bits
=== cyphermox_ is now known as cyphermox
alo21hi... I am merging a package, and I would like to edit an existing patch and makes it work on Ubuntu. Can I edit it, or I have to create a new one?21:22
micahgalo21: it depends, if the patch is pulled from an upstream commit, you'll want to add a new one, if it's Debian only and upstreamable to Debian, you could modify it, otherwise, add a new patch21:24
alo21micahg, the patch comes from debian, and it edits a makefile. This patch works well on Debian, but not in Ubuntu21:25
alo21micahg, what is the best thing to do?21:27
micahgalo21: which package and patch?21:27
alo21micahg, yeahconsole, patch 50-makefile.patch21:28
micahgalo21: the patch is wrong, that's probably why it fails on Ubuntu :)21:28
micahg+LDFLAGS += -lX11 should be LIBS, not LDFLAGS21:29
alo21micahg, in fact it fails... and I know the solution (is the previous patch)21:29
alo21micahg, or what you said is OK...21:30
alo21micahg, Can I directly edit the existing patch?21:31
micahgyeah, and send the fix to Debian after confirming it still builds there21:31
micahgthat stuff should probably ideally use pkg-config, but if this one change works, we can probably let it be21:32
alo21micahg, why I should send the fix to debian?21:32
micahgalo21: it's wrong there too :)21:32
alo21micahg, so have I to fill in a new bug, or I can get in touch with the Debian Maintainer?21:34
micahgalo21: file a bug with the fix21:34
alo21and the fix should be a .patch or a .debdiff?21:34
micahgafter confirming it solves the problem of course :)21:34
micahgdebdiff fixing the .patch I guess21:35
alo21micahg, Can I edit a patch just with gedit21:39
micahgin this case, yes21:40
micahgyou'll want to quilt pop -a first21:40
alo21micahg, what happens to wiki.ubuntu.com? A lot of pages seems no exist21:44
Laneyprobably https://lists.ubuntu.com/archives/ubuntu-devel/2013-January/036384.html21:45
micahgso he deprecated the whole wiki? :D21:50
alo21micahg, thanks!22:19

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!