| === nhandler_ is now known as nhandler | ||
| nigel_nb | I've been trying to build a package and I get some error in pbuilder, can someone review the error and help me figure out whats wrong? | 04:31 |
|---|---|---|
| nigel_nb | this is the error message I get http://pastebin.com/d1cede653 | 04:35 |
| RAOF | That's an indication that one of the patches the packaging is trying to apply is failing. | 04:38 |
| RAOF | You could almost-certainly duplicate this outside of pbuilder by running “debian/rules patch”. | 04:38 |
| nigel_nb | I did a quilt push -a and it worked though | 04:39 |
| nigel_nb | ok, yes. It is being duplicated | 04:39 |
| nigel_nb | RAOF, thanks. Figured whats wrong now :) | 04:43 |
| rhpot1991 | fabrice_sp: ping, you just approved one of my sponsorship packages and I was hoping you could look at the associated package on revu: http://revu.ubuntuwire.com/p/hdhomerun-config-gui | 05:58 |
| fabrice_sp | nice try rhpot1991 :-) | 05:58 |
| fabrice_sp | I already have a backlog of stuff to review: I'll put it in my list | 05:59 |
| rhpot1991 | fabrice_sp: no rush either, I'm going to bed. Anything changes you've recommended I made on this package too. | 05:59 |
| rhpot1991 | fabrice_sp: ok good enough, figured it might be a quick one since its associated with the one we worked through | 05:59 |
| fabrice_sp | great: I'll have a look this evening (early morning here) | 05:59 |
| rhpot1991 | thats fine, I'll be out for the next few hours anyways, whenever you get a chance | 06:00 |
| fabrice_sp | ok: good night then | 06:00 |
| rhpot1991 | I just added the DEP-3 tags to it and pushed, so it should be in good shape | 06:00 |
| rhpot1991 | thanks, cya later | 06:00 |
| fabrice_sp | cool: did you also run lintian -iIE on source and binary pacakge? | 06:00 |
| fabrice_sp | anyway: will check it. Bye | 06:00 |
| rhpot1991 | I ran lintian, didn't specify any flags though | 06:01 |
| fabrice_sp | ok | 06:03 |
| rhpot1991 | fabrice_sp: I see this no dpatch description warning, but thats cause it was move to the DEP-3 tags | 06:04 |
| rhpot1991 | its clean other than that | 06:04 |
| fabrice_sp | cool: sounds good then ;-) I'll check it later on (have to check some ubuntustudio interesting packages first :-) ) | 06:04 |
| rhpot1991 | thanks fabrice_sp | 06:05 |
| fabrice_sp | yw :-) | 06:06 |
| SevenMachines | hi, i was looking at joining the ubuntu bug control team but i'm a little confused by the application selection option 5, 'list 5 bugs you've triaged'. but without being a member of bug control my 'triaging' in terms of importance tags and so on is obviously quite limited, and a lot of the other bugs i'm on are now out of date and/or have already been triaged by the professionals :) | 07:19 |
| SevenMachines | do i just add a bit about why the importance and so on was set that way even if it was nothing to do with me? | 07:20 |
| RAOF | SevenMachines: As far as I know, what you'd be expected to show there are bugs where you got the relevant information from the submitter, and then asked a member of the bugteam to set the importance. | 07:28 |
| SevenMachines | ah, thanks, i don't think i've asked someone to set the importance more than a couple of times. i'll try and remember that in future. theres probably a few i could ask to be 'fix committed' due to a merge | 07:30 |
| === nenolod_ is now known as nenolod | ||
| dholbach | good morning | 08:11 |
| thekorn | good morning dholbach | 08:22 |
| dholbach | hi thekorn | 08:23 |
| === danfish is now known as alanfish | ||
| === alanfish is now known as danfish | ||
| abogani | Hi All, Sorry to bother you. I would want let you noticed that I just uploaded proposal package for the Arduino in REVU ( http://revu.ubuntuwire.com/details.py?upid=7690 and https://launchpad.net/~arduino-ubuntu-team/+archive/ppa/+packages ). If someone could review it would be really appreciated! Thanks in advance! | 10:40 |
| lazka | Ho do I build depend on all python verions for building python modules? | 11:35 |
| soren | Build-Depends: python-all | 11:35 |
| lazka | ah.. python-all-dev | 11:36 |
| lazka | thanks soren | 11:36 |
| soren | python-all-dev should only be needed if you're build python extensions. | 11:37 |
| lazka | it's a pyrex binding for a c lib | 11:38 |
| lazka | Is the xxx.instal file the right way to add extra (non .py) files to the package? | 11:42 |
| Laney | yes | 11:42 |
| Laney | or .docs if it's documentation | 11:42 |
| Laney | or .examples, ... | 11:43 |
| lazka | ok | 11:43 |
| lazka | thanks | 11:43 |
| SevenMachines | can i quickly check, if you have a version eg, 0.1build1, and then you make ubuntu changes, i take it you drop the build part altogether, ie 0.1ubuntu1? | 12:04 |
| slytherin | SevenMachines: right | 12:05 |
| SevenMachines | great, thanks | 12:07 |
| menesis | can REVU mail me comments and advocations? | 12:27 |
| menesis | there is a preference for that but it does not send me anything. I can subscribe to rss feed, but it is slow. | 12:28 |
| paissad | guys, here is my debian/menu file , but after installation of the package, i don't have the package in my system menu !! | 13:06 |
| paissad | http://pastebin.com/f5a93799e | 13:06 |
| paissad | btw, i use xfce | 13:06 |
| paissad | btw, i use xfce4 | 13:06 |
| paissad | do you have any idea why ? | 13:07 |
| Rhonda | paissad: Do you have the menu-xdg package installed? | 13:07 |
| paissad | Rhonda, no | 13:07 |
| Rhonda | The debian menu file entries only show up (in a Debian submenu) if you have that installed. | 13:08 |
| paissad | Rhonda, but how other programs did install their menu icon | 13:08 |
| Rhonda | Otherwise you need to do a .desktop file. | 13:08 |
| Rhonda | See contents of files in your system below /usr/share/applications/ | 13:08 |
| paissad | Rhonda, what would you do advice to do then ? | 13:09 |
| Rhonda | (IMHO) unfortunately some desktop environments think they need to hide the Debian menu. :/ | 13:09 |
| paissad | share/apps or share/pixmap ? | 13:09 |
| Rhonda | Not sure what you mean with share/apps or share/pixmap. | 13:10 |
| Rhonda | You need to put a .desktop file into /usr/share/applications/ in the proper format. | 13:10 |
| paissad | Rhonda, ok | 13:10 |
| Rhonda | paissad: Take a look at files already in there for examples, the documentation for the format is quite technical and IMHO hard to grasp. Ask if you got specific questions about certain lines, but it should get you the idea. | 13:12 |
| paissad | Rhonda, yep, thx | 13:12 |
| Laney | there's a desktop-file-validate script in some package | 13:17 |
| === ShadowChild is now known as lukjad007 | ||
| === lukjad007 is now known as lukjad86 | ||
| paissad | i've finished creating my package, i have this warning btw --> arch-dep-package-has-big-usr-share | 13:46 |
| paissad | but i just the fact is that it's a java software containing a .jar file which is 19MB huge | 13:47 |
| paissad | at leat ... and this jar file is in /usr/share/$package_name/ | 13:48 |
| paissad | i guess it could be an exception knowing that i saw some other java packages which contain jar files in /usr/share !! | 13:48 |
| paissad | huges jar files ^^ | 13:48 |
| paissad | i runned lintian -iIEv -pedantic | 13:49 |
| paissad | ran* | 13:49 |
| paissad | is it ok then ? | 13:50 |
| siretart | paissad: no, its not. use an arch: all package for those cases | 13:52 |
| paissad | siretart, i don't know what you mean | 13:53 |
| paissad | all package for those cases ? | 13:53 |
| siretart | use 'architecture: all' instead of 'architecture: any' in debian/control | 13:54 |
| === _iron is now known as i_ron | ||
| slytherin1 | paissad: if it is java package and complete platform independent code, you should have Architecture: all in debian/control file. | 14:17 |
| askhl_ | Hi, I'm trying to build a debian package of a Python/C program using distutils and python-central. I'm getting an error after the distutils build finishes, saying "/bin/sh: python2.5: not found", "make: *** [debian/python-module-stampdir/gpaw] Error 127", and "dpkg-buildpackage: error: debian/rules build gave error exit status 2". I would like to not depend explicitly on python 2.5, but am not sure where to start looking, nor where exactly th | 15:10 |
| persia | askhl_: Please post the entire build log. | 15:12 |
| persia | (to a pastebin) | 15:12 |
| askhl_ | persia, one moment | 15:13 |
| askhl_ | persia, http://www.student.dtu.dk/~ashj/opendir/build.err and http://www.student.dtu.dk/~ashj/opendir/build.log | 15:15 |
| askhl_ | I can build the program separately running 'python setup.py build' without any errors | 15:16 |
| askhl_ | (although there are compile warnings, but these are unrelated) | 15:17 |
| askhl_ | Ah, I see it loops "for buildver in 2.6 2.5; do" | 15:18 |
| askhl_ | I should probably depend specifically and only on Python2.6, since the program uses a slightly customized Python interpreter | 15:19 |
| askhl_ | (although it would work with other versions of Python as well, I'm packaging specifically for Ubuntu just now) | 15:20 |
| sindhudweep | I'm getting an error using dput to upload a package to a team ppa. I'm fairly certain my .dput.cf is correct as I've used it before, but launchpad is telling me "Launchpad failed to process the upload path '~gnash': path format mismatch." | 15:20 |
| askhl_ | sindhudweep, perhaps you need to specify ~gnash/ppa/ubuntu/ | 15:21 |
| askhl_ | (disclaimer: not exactly an expert) | 15:21 |
| sindhudweep | askhl_: let me try that. Has the path format changed? I'm trying to understand why it worked before and doesn't now. http://pastebin.com/m5bf48b94 is my dput config file. | 15:26 |
| askhl_ | sindhudweep, I have (at all times) had the /ppa/ubuntu/ in my 'incoming' path | 15:26 |
| sindhudweep | okay thanks. I must be mistaken! | 15:26 |
| askhl_ | otherwise it's pretty much the same | 15:27 |
| sindhudweep | http://blog.launchpad.net/cool-new-stuff/multiple-ppas-per-person <--- changed here | 15:27 |
| sindhudweep | i must have been using a really old config file :D | 15:27 |
| askhl_ | persia, the build works correctly if I simply specify 2.6 as the python version rather than the more general (but true) >= 2.3. I think I'll just do 2.6 for now, then I can improve the package later. Thanks | 15:28 |
| === asac_ is now known as asac | ||
| persia | askhl_: Try build-depending on "python-all". This should get you the correct defaults for any environment (I think). | 15:29 |
| persia | askhl_: In lucid, that's just 2.6, but it might differ in other environments. | 15:29 |
| askhl_ | Ah okay. So in Karmic (which I'm using), it's probably 2.5 and 2.6, which is the explanation | 15:30 |
| askhl_ | Thanks again | 15:31 |
| persia | Potentially, but by using that as a build-depends, it should just do the right thing. | 15:31 |
| persia | But check with the python packaging policy, which is more correct than I. | 15:31 |
| askhl_ | I think it was just me being silly, since I didn't have 2.5 installed. But if I submit it to launchpad as a PPA, it'll probably know to download the necessary python packages. So I should be fine | 15:32 |
| persia | Right. You might want to experiment with sbuild or pbuilder to simulate that behaviour locally. | 15:32 |
| === mathiaz_ is now known as mathiaz | ||
| spwelton | woot! got my debian/watch file working last night! | 15:45 |
| dholbach | if anybody's interested in getting https://launchpad.net/lazr.restful into Ubuntu, it'd be nice if you could have a 2nd look at lukasz-czyzykowski's packages on REVU, thanks :-) | 16:02 |
| dholbach | highvoltage: ^ good thing is that some of the packages are shared with schooltool! | 16:03 |
| dholbach | ajmitch: ^ zope fun! :) | 16:03 |
| BlackZ | hi dholbach ! | 16:11 |
| dholbach | hi BlackZ | 16:12 |
| rmunn | I'm interested in getting NLTK (http://www.nltk.org/) into Lucid, especially now that there's been an O'Reilly book published about it. But to do that, I need people to review and advocate http://revu.ubuntuwire.com/p/python-nltk soon. It should be ready to go on -- last set of comments revolved around cosmetic issues (a false-positive lintian warning), so I don't think it'll take much work on the reviewer's part. Any takers? | 16:15 |
| spwelton | Hi all, I made some revisions to eggtimer on REVU at http://revu.ubuntuwire.com/p/eggtimer and was wondering if someone could check it to make sure I've fixed the problems reported in previous comments. Any input is apprciated! Thanks! | 16:22 |
| abogani | Hi All, Sorry to bother you. I would want let you noticed that I just uploaded proposal package for the Arduino in REVU ( http://revu.ubuntuwire.com/details.py?upid=7690 and https://launchpad.net/~arduino-ubuntu-team/+archive/ppa/+packages ). If someone could review it would be really appreciated! Thanks in advance! | 16:56 |
| persia | nixternal: Didn't you have one of those devices? | 17:00 |
| nixternal | persia: yes, my dog ate it :) | 17:04 |
| persia | nixternal: Yes, but you might want to review the package so that when you get a new one it Just Works :) | 17:05 |
| nixternal | hehe | 17:05 |
| persia | Anyway, pets eating things is an old, tired excuse (even if true) | 17:05 |
| nixternal | that is true on both fronts | 17:06 |
| hakaishi | Hello everyone! Anyone upto advocate (or review) qt-shutdown-p? http://revu.ubuntuwire.com/p/qt-shutdown-p | 17:11 |
| paissad | here is my control file http://pastebin.com/f544fafbb, but i've been told that i should change the maintainer field | 17:34 |
| paissad | where is the ubuntu policy for that ? ... i based on debian policy to do that ! | 17:35 |
| persia | check the ubuntu-policy package. | 17:36 |
| paissad | persia, where is ubuntu-policy ? | 17:36 |
| paissad | the doc i mean | 17:36 |
| persia | There's a web mirror at http://people.ubuntu.com/~cjwatson/ubuntu-policy but I don't know how often that is updated. | 17:36 |
| persia | paissad: apt-get install ubuntu-policy :) | 17:36 |
| paissad | lol | 17:37 |
| spwelton | persia: If you've got the time, could you please check my package on REVU? I updated it to fix the errors reported in the comments. http://revu.ubuntuwire.com/p/eggtimer Thanks! | 17:38 |
| cjwatson | I update it when I merge | 17:39 |
| persia | In that case, it's always up to date : | 17:39 |
| persia | spwelton: Please find someone else: I've reviewed that a couple times, and like I said before, think it's duplicate to stuff we already have. | 17:40 |
| spwelton | ok | 17:40 |
| persia | spwelton: Feel free to ask me again after Feature Freeze if you still need review: I may have more time then. | 17:40 |
| spwelton | oh ok, Yeah i figured you guys would be pretty busy right now with feature freeze coming up | 17:41 |
| spwelton | i think i've got it mostly figured out though.. I gave up entirely on using quickly to do any of the packaging and did it all manually | 17:41 |
| persia | heh. | 17:46 |
| === atomicsteve is now known as vorian | ||
| mantis | hi, can anyone give me some help installing video card on ubuntu 9.10? | 17:56 |
| rmunn | mantis, This isn't the best channel for technical support. Ask your question in #ubuntu and you'll get more attention. | 17:57 |
| mantis | thnx | 17:58 |
| paissad | what do you suggest me to put in Maintainer field ? .... i already put --> XSBC-Original-Maintainer: Papa Issa DIAKHATE <paissad@gmail.com> | 18:00 |
| persia | update-maintainer should do the right thing | 18:02 |
| persia | But it's usually something like "Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>" | 18:02 |
| paissad | ok | 18:03 |
| paissad | persia, what about Ubuntu Motu Developers ? | 18:08 |
| paissad | i think i've seen something like that ? | 18:08 |
| persia | paissad: You have seen that. We used to use that for all new packages. | 18:09 |
| persia | But it ended up that the MOTU team wasn't able to maintain all the new stuff by itself, so now we recommend just listing Ubuntu Developers. | 18:09 |
| paissad | ok | 18:09 |
| smoser | hi all, i'm planning on packaging txaws (https://launchpad.net/txaws) which uses setup.py, but does not have an upstream released tarball | 18:24 |
| smoser | what path should I take to package it ? I'm guessing something with 0.0.1~bzr58 , but wondering how best to handle orig tarball | 18:26 |
| persia | smoser: CAn you convince upstream to release one? If not, you'll have to construct one. | 18:26 |
| smoser | likely i can | 18:27 |
| persia | That's the best option. It means there exists some known blob that represents upstream, so it can be checksummed and stuff | 18:27 |
| persia | Not quite as cool as if we had true object-matching network services, but getting closer. | 18:28 |
| === EagleScreen is now known as Guest94095 | ||
| c_korn | grrr, timeout. can someone please have a look at the debdiff? did I make something wrong or did I miss something? http://pastebin.com/f36cd5cce | 18:40 |
| c_korn | should I mention the update-maintainer in debian/changelog ? | 18:40 |
| persia | c_korn: No pont mentioning the maintainer change in the changelog: it's policy-mandated | 18:41 |
| persia | c_korn: I don't see anything else wrong. Do you think it's better to make that change, or upgrade jhdf5 in lucid? | 18:43 |
| persia | (and why) | 18:43 |
| c_korn | persia: puh, I have no idea. I should ask that Sylvestre Ledru (maintainer of scilab and jhdf). he told me to revert that patch because it is more easy :) so maybe there is no need for 2.6. | 18:46 |
| persia | 2.6 is in Debian unstable, and can be pulled to lucid if that makes sense. If the Debian maintainer said 2.5 was the better choice, I'd go with that :) | 18:47 |
| c_korn | I will ask him | 18:48 |
| c_korn | persia: thanks, I await his answer and will let you know. | 18:52 |
| persia | c_korn: No need to let me know specifically. I just think you want to have a firm plan for how to deal with this in your mind when publishing that debdiff, because there are two ways to solve the problem. | 18:53 |
| c_korn | persia: ok, as I said I have no idea about that library. so I let the maintainer decide. | 18:54 |
| persia | That seems the best plan, and then work to make sure that the policy you receive is implemented in Ubuntu. | 18:55 |
| persia | There's lots of cases where some package gets into a wonky state because of the sync/stop sync stuff, and if we can discover this early enough to make sure the release is in a good state, we're winning :) | 18:55 |
| c_korn | persia: yes, I keep that in mind. thanks. I have to leave now. | 18:58 |
| paissad | my package is lintian warning & errors free !! ... i 've put lucid in the debian/changelog file instead of unstable .... now if i understand correctly i need to open another bug ? ... & close it after ? | 19:10 |
| paissad | i did have a bug closed for debian already ! | 19:11 |
| persia | You had an ITP bug closed in Debian? The package was uploaded to Debian? | 19:11 |
| paissad | persia, yes , i had an ITP bug closed in debian .. no the package is not uploaded yet, i'm waiting for a mentor to see it :/ | 19:12 |
| persia | paissad: Aha! | 19:12 |
| paissad | ;) | 19:12 |
| paissad | so, do i need to open a launchpad bug ? ... via reportbug command ? | 19:12 |
| persia | You don't *need* to open a launchpad bug, but it's preferred. Most folk use `ubuntu-bug` rather than reportbug, as reportbug is a little wonky when dealing with launchpad. | 19:13 |
| dupondje | if some package is ftbfs but there is a new version into debian sid that (prolly) fixes it, is there some special things to do ? :) | 19:41 |
| persia | dupondje: First step is to make sure that "prolly" isn't part of your thoughts, because you know the answer :) | 19:42 |
| persia | dupondje: After that, you'll want to review other changes, and build an opinion as to whether it should all be synced, or we only want some patches. | 19:42 |
| dupondje | persia: seems they just fixed the ftbfs in the new version in sid :) | 19:47 |
| dupondje | so no other changes | 19:47 |
| dupondje | trying to build now | 19:47 |
| persia | dupondje: Well, if that's the only change, then sure, a sync is precisely the right thing to do :) | 19:47 |
| persia | dupondje: So, verify, and if that's the only change, and it works, call requestsync | 19:48 |
| dupondje | added syncrequest :) | 19:52 |
| randomaction | How do I fix a package which expects libGL.so to be in /usr/lib (while in fact it's in /usr/lib/mesa). I can make it build with -L/usr/lib/mesa, but then the executable fails to load (still expects the library in /usr/lib) | 19:52 |
| persia | dupondje: Excellent. | 19:52 |
| dupondje | there is some lagg before it gets added as a bug ? | 19:54 |
| persia | Shouldn't be a significant one. | 19:54 |
| * persia doesn't know much about requestsync, and doesn't personally ever use it, so maybe someone else has a better answer | 19:54 | |
| dupondje | https://bugs.launchpad.net/ubuntu/+source/gnome-do-docklets/+bug/521152 | 19:55 |
| ubottu | Ubuntu bug 521152 in gnome-do-docklets "Sync gnome-do-docklets 0.8.2-2 (universe) from Debian sid (main)" [Wishlist,New] | 19:55 |
| dupondje | there it is :P | 19:55 |
| dupondje | somebody can accept it ? :) | 20:01 |
| randomaction | dupondje: I'm looking | 20:03 |
| dupondje | great :) | 20:03 |
| === siretart_ is now known as siretart | ||
| randomaction | acked | 20:09 |
| dupondje | thx | 20:10 |
| dupondje | going to my next ftbfs :) | 20:11 |
| geser | randomaction: is /usr/lib/ hard-coded in the binary? because other binaries find libGL.so | 20:14 |
| randomaction | geser: according to ldd, libGL.so.1 => not found | 20:21 |
| randomaction | so looks like no hardcoding | 20:21 |
| randomaction | the package in question is rss-glx, by the way | 20:23 |
| geser | does /etc/ld.so.conf.d/GL.conf point to valid file (after following all symlinks) for you? | 20:23 |
| randomaction | no, it's a broken symlink | 20:24 |
| geser | how did you broke it? | 20:24 |
| randomaction | I wonder myself | 20:25 |
| randomaction | what package should it belong to? | 20:25 |
| geser | sudo update-alternatives --auto gl_conf should fix it | 20:27 |
| geser | and the package who set it is libgl1-mesa-glx | 20:27 |
| geser | I guess nvidia too (but can't check it) | 20:27 |
| randomaction | why isn't it here, then? http://packages.ubuntu.com/lucid/i386/libgl1-mesa-glx/filelist | 20:28 |
| geser | /usr/lib/mesa/ld.so.conf | 20:29 |
| geser | the symlinks are added through update-alternatives | 20:29 |
| randomaction | ok, let's try it again | 20:30 |
| geser | where did your broken symlink point to? perhaps it's a bug in an other package not updating it | 20:31 |
| smoser | anyone here mildly ruby aware ? | 20:34 |
| smoser | i started packaging right_aws and right_http_connection ruby libraries | 20:34 |
| smoser | putting together the packages using the ruby-pkg-tools | 20:34 |
| persia | smoser: You're aware that FF is in 5 days, right? | 20:34 |
| persia | Do you need these for lucid? | 20:35 |
| paissad | i cannot open an launchpad bug using ubuntu-bug | 20:35 |
| paissad | it's a new package btw | 20:35 |
| smoser | i have them building both libright-<xxx>-ruby1.8 and 1.9. | 20:35 |
| smoser | persia, i am aware, and yes, they're hopeful for lucid. | 20:35 |
| smoser | my problem is that the libuuidtools-ruby that they depend on only builds the 1.8. should i just ditch the 1.9 packages for libright* ? | 20:36 |
| persia | smoser: lucas is the resident ruby expert, but you may find http://pkg-ruby.alioth.debian.org/ruby-policy.html/ provides guidance | 20:37 |
| persia | smoser: Generally that sort of thing ends up getting built in a loop (foreach sort of thing) | 20:38 |
| lucas | smoser: is it in debian? | 20:38 |
| smoser | libuuidtools-ruby is in debian | 20:38 |
| smoser | but builds only the 1.8 | 20:38 |
| lucas | it uses ruby-pkg-tools? the setup.rb class? | 20:38 |
| smoser | persia, doing 1.9 is as easy as adding a Package header for it. | 20:38 |
| smoser | yeah | 20:38 |
| smoser | thats from a build perspective, i'm not aware enough to know if that will "just work" from runtime | 20:39 |
| lucas | smoser: so just remove the Package: stanza for 1.9, add it for 1.9.1, and change the build-deps | 20:39 |
| lucas | and build-dep on the latest ruby-pkg-tools | 20:39 |
| lucas | ah, you need to check that. ruby1.9.1 breaks lots of things | 20:39 |
| paissad | i have no errors during lintian run, but i would like to know if this changelog is ok ? http://pastebin.com/f2b4ae77f ... the bug number was opened from debian ... | 20:39 |
| sebner | paissad: ubuntu changelog is always -0ubuntu1 and I'm wondering if it makes sense to close a Debian BTS bug | 20:41 |
| smoser | lucas, i'll have to check on the 1.9 compatibility of libuuid then. but above your suggestion was to add that to libuuidtools ? i'm somewhat confused. the libright* that i was putting together have a 1.9 stanza, but libuuid does not. | 20:42 |
| paissad | sebner, i read ubuntu-policy, section 4.4, i did not see & i still don't see -0ubuntu1 anywhere :s | 20:43 |
| paissad | and actually, i don't see any difference between debian/changelog explanations between debian-policy & ubuntu-policy | 20:45 |
| dupondje | what could be a reason a package that is like months in debian squeeze isn't in ubuntu yet ? | 20:46 |
| lucas | smoser: I miss some context. but really, why don't you just ship -ruby1.8? with 1.9 lib? | 20:46 |
| lucas | smoser: the ruby community doesn't really care about 1.9.1 yet anyway | 20:46 |
| persia | dupondje: Usually sync failure. Which package? | 20:47 |
| dupondje | gnucash | 20:47 |
| smoser | what does "with 1.9 lib" mean? i'm sorry for being dense. I think you're implying just drop the 1.9 from the things i was goign to package, which is probably fine. | 20:48 |
| smoser | i just modeled my packaging after others i had seen, that had a "libX-Y-ruby" that depended on a libX-Y-ruby1.8 and also built a libX-Y-ruby1.9 | 20:49 |
| smoser | ie, the "default" was 1.8 but there was 1.9 available. | 20:49 |
| sistpoty | dyfet: just taking a look at sipwitch upgrade | 20:50 |
| persia | dupondje: Needs a merge | 20:50 |
| smoser | lucas, https://code.launchpad.net/~smoser/+junk/libright-aws-ruby is what i have now. maybe that will clear things up. | 20:50 |
| sistpoty | dyfet: one problem with the init script: please test if $DAEMON is actually executable before trying to start it | 20:50 |
| persia | dupondje: If you look at the version in Ubuntu, you'll see it has local changes, etc. | 20:51 |
| dupondje | persia: it has patches yes, but they got added upstream | 20:51 |
| sistpoty | dyfet: (the package can be in removed state, which leaves conffiles around, which means that the initscript would still be around, but not $DAEMON) | 20:51 |
| lucas | smoser: yes, sorry, doin several things at the same time. you can drop the -ruby1.9(.1)? package | 20:51 |
| persia | dupondje: But it doesn't look like anyone has gone through to verify that and make sure that we can sync the Debian version. | 20:51 |
| persia | dupondje: Also, if the orig.tar.gz files differ, we can't sync Debian, so need to merge in the changes from Debian. | 20:52 |
| smoser | ok. that seems to make the most sense. thanks. | 20:52 |
| sistpoty | dyfet: same is true for the cronscript, though that only results in a mail | 20:52 |
| randomaction | geser: thanks for your help, I think I should add libgl1-mesa-glx to deps/build-deps | 20:54 |
| sistpoty | dyfet: others than that looks quite nice, at least just from reviewing the .diff.gz so far | 20:55 |
| oojah | Hi, could someone please take a look at http://revu.ubuntuwire.com/p/sqlite3-pcre ? It's a nice and simple package that is for a sqlite extension that implements the REGEXP() call with pcre. | 20:55 |
| === NCommander_ is now known as NCommander | ||
| geser | randomaction: isn't libgl1-mesa-dev enough? it depends on libgl1-mesa-glx | 20:57 |
| === NCommander is now known as Guest88140 | ||
| randomaction | it's not in the build-deps | 20:58 |
| fabrice_sp | Rhonda, about bug 347256 | 20:58 |
| ubottu | Launchpad bug 347256 in pgadmin3 "pgadmin3 has ugly icon" [Undecided,Fix released] https://launchpad.net/bugs/347256 | 20:58 |
| geser | how does it link against libGL then? | 20:59 |
| randomaction | geser: here's the list: http://packages.debian.org/sid/rss-glx | 20:59 |
| fabrice_sp | do we use menu files in Ubuntu? | 21:00 |
| randomaction | it has libgl1-mesa-glx | libgl1 | 21:00 |
| dyfet | sispoty: I used an already needed bug fixes to clean up a few other small things... | 21:00 |
| dyfet | (sistpoty) | 21:01 |
| persia | fabrice_sp: We certainly can use menu files, but we don't present them to users by default. | 21:01 |
| geser | randomaction: ah, it b-d on libgl1-mesa-swx11-dev | 21:01 |
| fabrice_sp | persia, I mean: kde and gnome uses .desktop file, so is there some windows manager in Ubuntu that uss menu files? | 21:01 |
| fabrice_sp | s/uss/uses/ | 21:02 |
| geser | randomaction: I guess we should take this now to #ubuntu-x | 21:02 |
| randomaction | geser: I'm a little lost with all these libgl* libraries | 21:02 |
| dyfet | sistpoty: and it does test.... "test -x "$DAEMON" || exit 0" early in the init script... :) | 21:03 |
| randomaction | geser: so if you can formulate the problem, please do | 21:03 |
| geser | randomaction: a work-around for now would probably be to use libgl1-mesa-dev instead of libgl1-mesa-swx11-dev | 21:03 |
| persia | fabrice_sp: There are a few window managers in Ubuntu that depend on the menu files. Also, installing the menu-xdg package exposes menu files to XDG-compliant menu systems (like those used in KDE and GNOME). | 21:04 |
| geser | but I don't know yet if it's a bug that libgl1-mesa-swx11 doesn't provide a ld.so.conf snippet | 21:04 |
| sebner | paissad: https://wiki.ubuntu.com/PackagingGuide/PackagingOverview | 21:05 |
| Rhonda | fabrice_sp: If menu-xdg is installed, yes. | 21:05 |
| fabrice_sp | persia, ok. Thanks! (I sponsored an upload that broke a menu file, and was trying to undertand the criticity of that) | 21:05 |
| === Guest88140 is now known as NCommander | ||
| persia | fabrice_sp: unbreak it: it's a regression for some users. | 21:05 |
| fabrice_sp | ok | 21:06 |
| sistpoty | dyfet: nice, thanks. haven't seen it in the .diff.gz :) | 21:06 |
| fabrice_sp | Rhonda, will you adopt the changes in Debian? | 21:06 |
| Rhonda | fabrice_sp: It's not that extremely critical, it's just that I would have welcomed coordination last year already and karmic could have had that fixed. So it's more a bit of grumpy mood in me that "reopened" that one. | 21:06 |
| Rhonda | Definitely, though the xpm file will get installed additionally, the debian menu entry doesn't like svg. | 21:07 |
| fabrice_sp | yeah: this has been open since one year | 21:07 |
| fabrice_sp | ok: will install both then | 21:07 |
| dyfet | sistpoty: ah...yes, that part wasnt broken in the old init, so it would not be in the diff :) | 21:07 |
| Rhonda | fabrice_sp: And I'm not totally sure what happens with the desktop entry if it references the file without filetype. Maybe changing the desktop file to mention .svg extension? | 21:08 |
| persia | .desktop files should not specify the extension. | 21:08 |
| fabrice_sp | Rhonda, desktop files are able to find the right extension, AFAIK | 21:08 |
| Rhonda | persia: Which one would get used then? The svg or the xpm? | 21:08 |
| Rhonda | fabrice_sp: … which one is the right one? :) | 21:08 |
| sistpoty | dyfet: oh, sipwitch-dbg is empty? | 21:08 |
| fabrice_sp | desktop-file-validate complains if you have an extension, yes | 21:08 |
| persia | They should be loading by name from the icon-cache, and the icon-cache deals with the set of mime-types that provide that name for the menu system displaying them. | 21:09 |
| Rhonda | You'll say "obviously the svg", but that doesn't sound too obvious to me. | 21:09 |
| dyfet | sistpoty: is it? | 21:09 |
| persia | Rhonda: I usually name the .xpm and .svg icons with the same basename, use the .xpm in the menu file, and put the basename in the .desktop file for the icon-cache to pick the best one. | 21:09 |
| Rhonda | fabrice_sp: Can you install both (xpm + svg) and check which one the menu entry would reference? | 21:10 |
| sistpoty | dyfet: yes, but I'm not 100% sure if I need pkg-binarymangler (or some other package) which is there on the buildds installed in pbuilder | 21:10 |
| persia | Rhonda: The answer to that question (for XDG-compliant menu impementations) depends on the environment, so different desktop environments may select the svg or xpm. | 21:10 |
| dyfet | sistpoty: my last build did build a dbg package.... | 21:11 |
| Rhonda | fabrice_sp: While you are at it, I noticed it through being sent the ubuntu diff through the PTS, in case you wonder. I now did scan quickly over the launchpad bugs of pgadmin3 and I think that we should drop the "System" category from the desktop file. | 21:11 |
| sistpoty | dyfet: yes, the package is there, but it contains only /usr/share/doc/... | 21:11 |
| fabrice_sp | Rhonda, it checks first png, then svg and at last, xpm (http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html) | 21:11 |
| fabrice_sp | so it should be ok | 21:12 |
| Rhonda | persia: And this is what I fear. It's not totally predictable … I want to have it well defined. :) I guess I'll rename the xpm to … nevermind, thanks fabrice_sp for looking it up! | 21:12 |
| dyfet | sistpoty: hmm, it seems to be doing that now that I switched to dh7 style from cdbs...??!! | 21:12 |
| persia | fabrice_sp: That'S the spec: at least in the past some menu implementations have preferred svg over png :) | 21:12 |
| fabrice_sp | ok. Anyway, xpm seems to be alsways the last one :-D | 21:13 |
| Rhonda | fabrice_sp: Hope you aren't mad with me for the response, it really seems to be a fight sometimes to get people to forward such issues. It's less work for everyone involved if it gets fixed in Debian first. No patch to check for syncing on concensus, and this is no issue to sweat about. :) | 21:13 |
| fabrice_sp | Rhonda, will check that also | 21:13 |
| persia | Rhonda: The idea is to exchange predictability for themability and best match to the prevailing environment. | 21:13 |
| dyfet | sistpoty: the last (still using cdbs) build still had a normal debug package... | 21:13 |
| sistpoty | dyfet: haven't myself yet tought dh 7, but from dh_strip it looks like you'll need to pass it -k (I have no clue though how to do that) | 21:14 |
| fabrice_sp | Rhonda, not at all: I always try to get Debian maintainer involved (first at the beginning at the dev cycle, after when release date comes closer) | 21:14 |
| Rhonda | fabrice_sp, persia: About that category bug (don't have the number handy) - there is actually a "programming" menu in ubuntu? | 21:14 |
| persia | sistpoty: dyfet overrride_dh_strip:\n\tdh_strip -k ... | 21:14 |
| Rhonda | I don't see this on my Debian desktop, and I don't find any named category in the specs? | 21:15 |
| dyfet | persia: thanks :) | 21:15 |
| fabrice_sp | Rhonda, in this case, if you get it fixed quickly, I could request the sync, but just in case,I'll fix it | 21:15 |
| persia | Rhonda: There is a "Programming" menu at least for GNOME/KDE/xfce4 | 21:15 |
| fabrice_sp | In gnome, yes | 21:15 |
| persia | Rhonda: But Categories should be selected from the registered list | 21:15 |
| * persia digs up the URL | 21:15 | |
| Rhonda | persia: I have Development but no Programming? | 21:15 |
| persia | http://standards.freedesktop.org/menu-spec/latest/apa.html | 21:16 |
| fabrice_sp | Weel, mine is in Spanish, so I have Desarrollo :-D | 21:16 |
| persia | Right. I think stuff in Category "Development" ends up in a menu called "Programming". | 21:16 |
| sistpoty | dyfet: hm... strange | 21:16 |
| Rhonda | persia: Yes, that's where I'm in too. | 21:16 |
| dyfet | sistpoty: yes, that was a dh7 suprise :)...let me do a quick check build here... | 21:16 |
| Rhonda | persia: Oh, I'm using German locale and that one is named "Entwicklung" (german term for development) so I thought it would be just exactly that in english. | 21:17 |
| Rhonda | persia: Anyway, pgadmin3 _does_ set that category in its desktop file so I wonder, it should appear in there? | 21:17 |
| Rhonda | It's just that it _also_ appears in the System menu. | 21:17 |
| sistpoty | dyfet: anyways, I wouldn't also mind uploading it w.o. the -dbg package containing anything, as anything else is really nice! but it's your call of course | 21:17 |
| persia | Rhonda: I think it ought. I'd have to check the .menu files to be sure. | 21:17 |
| paissad | it is said that we may not need to open a launchpad bug for a new package | 21:17 |
| paissad | is it true ? | 21:18 |
| Rhonda | Categories=GNOME;Database;System;Development; | 21:18 |
| persia | Rhonda: Does it have two Categories in the "Main Category" section? | 21:18 |
| Rhonda | yes | 21:18 |
| persia | Right. It should just have "Development; Database" | 21:18 |
| dyfet | sistpoty: it should just take me a few minutes to verify persia's suggestion, though I am sure he is correct | 21:18 |
| Rhonda | persia: What's the GNOME part? Should I drop that one too? | 21:18 |
| sistpoty | :) | 21:18 |
| persia | Rhonda: the "GNOME" category is a historical leftover from before OnlyShowIn: was available. It may be dropped. | 21:19 |
| persia | And I didn't like it anyway, unless there was some really good reason not to show something in another menu (but I can't see why KDE users shouldn't use pgadmin3 as long as they don't mind having the libraries installed) | 21:19 |
| persia | On the other hand, if you want to *remind* users that something only uses vertain libraries, "KDE", "GNOME", "GTK" "Qt", "Motif", and "Java" are permitted. | 21:20 |
| Rhonda | Just to be sure, is ordering relevant? i.e., should I put Development;Database; or Database;Development;? | 21:21 |
| dyfet | sistpoty: persia: it did not make a difference!....go ahead and upload if you think its okay to do so otherwise, and I can always do a tiny update when we figure out that issue | 21:21 |
| sistpoty | dyfet: ok, I'll upload what's there, I'm quite sure you'll follow up if the result is not to your liking, right? ;) | 21:21 |
| persia | Rhonda: I generally do "${MainCategory};${AdditionalCategory}", but it shouldn't matter. | 21:22 |
| Rhonda | Sounds more straightforward anyway, topdown. :) | 21:22 |
| dyfet | sistpoty: of course :). Now I am really curious why switching to dh7 clobbers dbg.... | 21:22 |
| rmunn | So I've been trying for a week now to get advocates for http://revu.ubuntuwire.com/p/python-nltk, and it's getting a bit discouraging, honestly. I've had several people give very valuable (and much-appreciated) feedback in IRC, but now that it seems the package is ready, I can't seem to get anyone to look at it. What else should I be doing besides mentioning it here in #ubuntu-motu? | 21:22 |
| persia | rmunn: There's not much else you can do, unless there's another development team that might be interested. | 21:23 |
| fabrice_sp | Rhonda, should I then fix the package in Ubuntu, or you will upload shortly a new version? | 21:23 |
| persia | rmunn: I can understand that it's discouraging, but please also understand that as FF approaches, many developers focus on the features they need for FF, rather than having time for too many reviews. | 21:24 |
| Rhonda | fabrice_sp: I'm trying to do that now. ;) | 21:24 |
| sistpoty | dyfet: uploaded, thanks a lot for that great work! | 21:24 |
| fabrice_sp | Rhonda, cool: I'll wait then ;-) | 21:24 |
| rmunn | I think it's worth getting this into Lucid -- it's a pretty famous library in its problem domain (an O'Reilly book was recently published about it), so not having it in Ubuntu feels like an odd gap. But I don't know how to get anyone else intereted. | 21:24 |
| Rhonda | fabrice_sp: Unrelated shameless selfpromotion: The bug decrease is my job. :P http://people.debian.org/~glandium/bts/p/pgadmin3.png | 21:24 |
| persia | Rhonda: 0RC: nice :) | 21:25 |
| fabrice_sp | only 2 :-) | 21:25 |
| sistpoty | rmunn: patience... maybe I'll take a look later on;) | 21:25 |
| rmunn | sistpoty: Thanks, would be appreciated. | 21:25 |
| Rhonda | persia, fabrice_sp: Picked up the package last year and got an upstream developer to subscribe to the Debian BTS. ;) | 21:25 |
| Rhonda | … yet another reason to forward pgadmin3 bugs there. ;) | 21:26 |
| persia | You're always good at that "make upstreams pay attention" thing :) | 21:26 |
| fabrice_sp | :-D | 21:26 |
| Rhonda | Of course, and ubuntu should learn that too. It reduces your own work requirement. ;) | 21:26 |
| persia | I think most of the folk that do a lot of work know it, but lots of stuff gets done drive-by, which often doesn't get the follow-up it needs. | 21:27 |
| rmunn | After Ubuntu Developer Week, I got enthusiastic about learning to be a MOTU, and there was a package I knew about (I was a technical reviewer for the O'Reilly book on NLTK) that I knew could go in. But I'm still new to the whole process. | 21:28 |
| * Rhonda . o O ( I really think I should do my "Debian packaging backwards" talk ) | 21:28 | |
| persia | Rhonda: Do you have an abstract somewhere? | 21:28 |
| Rhonda | Not yet. It starts of off with "ar x foo.deb" | 21:28 |
| dhillon-v10 | hi all, this patch I was working on before: http://paste.ubuntu.com/374998/ turns out to be malformed at line 79, can anyone tell me how to fix that ? | 21:28 |
| persia | Rhonda: heh. That's an interesting way to teach it. | 21:29 |
| Rhonda | persia: Somehow inspired by all the git talk of describing "to understand git you need to know what's inside" | 21:29 |
| Rhonda | Need to head for bed now though. | 21:29 |
| persia | Rhonda: makes sense, but suffers from TLDR for people who don't take it seriously. | 21:30 |
| sistpoty | gn8 Rhonda | 21:30 |
| Rhonda | fabrice_sp: I hope that I can upload tomorrow. | 21:30 |
| quentusrex | fta, are you around? | 21:30 |
| Rhonda | TLDR? | 21:30 |
| rmunn | Rhonda, "Too Long, Didn't Read" | 21:30 |
| fta | quentusrex, yes | 21:30 |
| persia | too-long-didn't-read : the common response to most of my email | 21:30 |
| Rhonda | lol | 21:30 |
| quentusrex | fta, I noticed you do a lot of work on the mozilla ppa. Is there a reason there isn't a 'thunderbird' package to point to the latest stable like the 'firefox' package? | 21:31 |
| fabrice_sp | Rhonda, ok. Ping me (or request the sync) to get it uploaded | 21:31 |
| quentusrex | fta, something to make it easier to stay updated to the latest stable. | 21:31 |
| fabrice_sp | sponsored, I wanted to say | 21:31 |
| maxb | dhillon-v10: The numbers in the hunk headers don't match the content of the patch. I guess you were editing the patch itself manually? Run it through 'recountdiff' | 21:31 |
| dhillon-v10 | maxb: yeah, I did that but then later on screwed up somewhere else, actually 3 of my other patches got rejected because I edited them later on so do you think recountdiff can fix those | 21:32 |
| maxb | It's fairly good | 21:32 |
| Rhonda | fabrice_sp: I haven't put in the LP: closes message for the category bug. For a start I would even call that one invalid because it should appear in programming, for a second, I "just" dropped the system category in the desktop file, which is totally different to what the bug wanted. :) | 21:33 |
| Rhonda | fabrice_sp: I though subscribed to it to not forget about it. :) | 21:33 |
| fta | quentusrex, yeah, i used to do a lot of work on mozilla stuff, far less those days. micahg is working on tb now | 21:33 |
| micahg | quentusrex: almost done :) | 21:33 |
| quentusrex | fta, it said you had done the last round of commits | 21:33 |
| quentusrex | micahg, awesome. Let me know if I can help | 21:34 |
| quentusrex | I have found a bug in thunderbird 3.0 and 3.1 | 21:34 |
| dhillon-v10 | maxb: is it supposed to take some time, btw thanks a lot :) | 21:34 |
| micahg | quentusrex: testing if you're available this weekend maybe | 21:34 |
| quentusrex | If you have an rss feed that has a relative url for the images, | 21:34 |
| maxb | dhillon-v10: No, it should be instantaneous | 21:34 |
| quentusrex | it doesn't use the correct domain for the images. | 21:34 |
| micahg | quentusrex: please file against the thunderbird package and tag PPA for the moment | 21:35 |
| quentusrex | it uses the domain of the rss feed(such as feed burner) rather than the domain of the site where the feed is for. | 21:35 |
| quentusrex | ok | 21:35 |
| dhillon-v10 | maxb: here it just keeps on going still hasn't ended yet, like 4 mins. | 21:35 |
| micahg | quentusrex: specify which versions and a sample feed if you can | 21:35 |
| dhillon-v10 | maxb: oh I know why :) | 21:35 |
| rhpot1991 | can you "rename" a file in install, ie : file.ico /usr/share/pixmaps/newname.ico | 21:38 |
| rhpot1991 | I think that might need to be done in links | 21:38 |
| fabrice_sp_ | Rhonda, sorry: piuparts killed my system. I only saw that you answered me something | 21:39 |
| persia | rhpot1991: Not with dh_install, but you can do it in debian/rules (mv foo bar) | 21:39 |
| fabrice_sp_ | Rhonda, but not the content | 21:40 |
| persia | fabrice_sp_: What timestamp? | 21:40 |
| fabrice_sp_ | 3 minutes ago | 21:40 |
| * fabrice_sp_ still has to find why piuparts kill X... | 21:40 | |
| persia | Latest I have is 7 minutes ago, I'll /query | 21:41 |
| rhpot1991 | persia: can I reference the file in the same manner that I do in install? | 21:42 |
| dhillon-v10 | maxb: this is what happens now: http://paste.ubuntu.com/375006/ should i do the whole patch over? | 21:42 |
| rhpot1991 | persia: wondering about paths to the source | 21:42 |
| persia | rhpot1991: Not quite. You'll want to use `mv ${CURDIR}/debian/tmp/... ${CURDIR}/debian/tmp/...` : after that you can use dh_install on the new name if you're splitting the package. | 21:43 |
| rhpot1991 | persia: thanks | 21:43 |
| kklimonda | can I use bzr merge-upstream with bzr branches and not tarballs? | 21:44 |
| maxb | dhillon-v10: No need to do it all again, just manually apply the rejects and re-diff against the base | 21:44 |
| kklimonda | I get a really scary error but on the other hand it tries to do something before I get it | 21:44 |
| kklimonda | it even generates a tarball and when I try to merge-upstream it I still get "bzr: ERROR: [Errno 20] Not a directory" | 21:46 |
| persia | kklimonda: I don't know much about using bzr-builddeb but if you have a local complete branch including packaging, and a foreign complete branch of newer upstream, you should be able to just `bzr merge {foreign-branch}` to get the latest code. | 21:48 |
| persia | Mind you, you'll still want the tarball (debian/rules get-orig-source may help) to build a source package. | 21:49 |
| kklimonda | persia, they don't have a common ancestor - that's why I was hoping to use merge-upstream comman and it seems to work up to the point when it doesn't :) | 21:49 |
| persia | Ah, that makes it awkward. | 21:49 |
| persia | I hear there's ongoing work to be able to merge without a common ancestor (for known similar content), but it's not likely ready for some time. | 21:50 |
| quentusrex | micahg, I don't see where the report bug link got moved to... | 21:50 |
| micahg | quentusrex: https://help.ubuntu.com/community/ReportingBugs#Filing bugs at Launchpad.net | 21:51 |
| persia | quentusrex: ?no_redirect is the trick | 21:51 |
| quentusrex | I wish the link would be on the software page. | 21:52 |
| quentusrex | where everything else is located. | 21:52 |
| quentusrex | found a bug in the reporting a bug software... | 21:54 |
| persia | heh | 21:54 |
| quentusrex | micahg, here is the feed: http://feeds.feedburner.com/zerohedge/feed | 21:54 |
| quentusrex | load that into any thunderbird 3.* | 21:54 |
| quentusrex | and all the relative image paths use the wrong domain. | 21:54 |
| micahg | quentusrex: please file a bug, I cannot look into it now | 21:54 |
| quentusrex | I need to reboot. Just installed a graphics driver update. | 21:55 |
| quentusrex | micahg, I just tried and the bug report crashed. | 21:55 |
| dyfet | sistpoty: what peria suggested lead me to one solution for the dbg package that did work, which was using the override_dh_strip to pass dh_strip the --dbg-package=sipwitch-dbg directly, but I am going to see if there is a better dh7 way to do debug packages that I simply do not know before submitting an update | 21:55 |
| micahg | quentusrex: an oops? | 21:55 |
| sistpoty | dyfet: oh, nice. feel free to ping me (as long as I'm awake) for skipping the queue ;) | 21:55 |
| dyfet | sistpoty: I may get to look at it over the weekend :) | 21:57 |
| sistpoty | dyfet: heh :) | 21:57 |
| quentusrex | micahg, https://bugs.launchpad.net/ubuntu/+bug/521188 | 21:58 |
| ubottu | Ubuntu bug 521188 in ubuntu "Thunderbird 3.0 handling relative image urls wrong in rss feeds" [Undecided,New] | 21:58 |
| quentusrex | there I was able to file that. | 21:58 |
| micahg | quentusrex: k, I'll see if I can look at it sometime soon | 21:59 |
| quentusrex | thanks. | 21:59 |
| micahg | quentusrex: feel free to poke me next week if you don't see any activity | 21:59 |
| quentusrex | ok | 22:01 |
| quentusrex | thanks micahg | 22:01 |
| paissad | i want to remove my previous uploaded package to revu.ubuntuwire.com ..... is it possible ? .. | 22:02 |
| asbin | persia: Hi ! I've fixed some issues with enna package, if you want to have a look at it :) | 22:03 |
| paissad | i want to remove theses packages (amd64 & i386) ones ! | 22:04 |
| paissad | http://revu.ubuntuwire.com/p/pms-linux | 22:04 |
| paissad | finally, i built it in binary-indep instead arch dependent ^^ | 22:04 |
| paissad | instead of* | 22:04 |
| persia | paissad: Just upload the new source, and it will replace the old one. | 22:05 |
| persia | REVU doesn't build anything. | 22:05 |
| paissad | persia, ok | 22:06 |
| sistpoty | rmunn: just taking a look at the comments to python-nltk: If I read it right, there's still nltk.jar in the orig.tar.gz? if so, please remove it and repack the tarball, otherwise python-nltk would need to go to multiverse at best | 22:09 |
| persia | sistpoty: Why? Since it's deleted on clean, we *know* it's not used in the build, and we have source for it in the upstream tarball. | 22:15 |
| sistpoty | persia: do we? | 22:16 |
| persia | I thought we did. Do we not? | 22:16 |
| * sistpoty looks again at the comments | 22:16 | |
| persia | I'm not sure we can prove it, but I am sure we aren't distributing binaries to users that use it, and I am sure we can show md5sum match to upstream to indicate we're not shipping modifications without source. | 22:17 |
| persia | (unless I'm confusing this with another package that had a jar to be deleted on clean that came up recently) | 22:17 |
| rmunn | Was at another computer, back now. | 22:18 |
| sistpoty | persia: maybe you'll need to teach me java lessons... as in comment 3, the .jar is built using 3rd party sources. My assumption is that hence the complete source for the .jar is missing, as I assume that code from 3rd party sources are contained in it | 22:18 |
| sistpoty | persia: is that assumption true? | 22:19 |
| rmunn | The nltk.jar was discussed a few days ago. It's built entirely from sources inside the .orig.tar.gz, but it depends on classes from Mallet, which isn't in Debian yet. | 22:19 |
| rmunn | I had two options: repack (which would force reviewers to go through and compare my repacked tarball to the original to prove I hadn't inserted any Trojans), or keep the original and delete the .jar in clean. I chose the latter. | 22:20 |
| sistpoty | rmunn: yes, I see, but does the .jar hence include just references to 3rd party sources or does it also contain code from these? (my java knowledge is really extremely limited) | 22:20 |
| rmunn | There are no licensing issues with redistributing the .jar since its source code is entirely present in the .orig.tar.gz. | 22:21 |
| persia | sistpoty: I think I missed that. I concur with you: if the jar is build from external (unincluded) sources, it needs to go. | 22:21 |
| persia | rmunn: My apologies for giving you incorrect advice earlier. | 22:21 |
| rmunn | The only dependency on external sources is via "import edu.umass.cs.mallet.base.util.MalletLogger". | 22:21 |
| sistpoty | persia: as I wrote, I'm not 100% sure if it is, I don't know too much what .jar files actually contain | 22:21 |
| persia | rmunn: Entirely? No third-party .class files? | 22:21 |
| persia | sistpoty: It's a zip archive full of whatever, but interestingly full of .class and/or .java files. | 22:22 |
| rmunn | Entirely, I checked. All the .class files in that .jar are built from javasrc/org/nltk/mallet/*.java files in the .orig.tar.gz. | 22:22 |
| rmunn | All of which are licensed Apache-2, which allows redistribution of both source and binaries. | 22:22 |
| persia | rmunn: If you've checked, and you're sure, I'll support you not deleting the .jar file. | 22:22 |
| rmunn | And all of which are copyright the NLTK project, just like the rest of the source. | 22:22 |
| * persia adds this to the list of packages to REVU soon | 22:22 | |
| sistpoty | rmunn: ok, if you're sure, I agree with you and persia. Let me just go out for a smoke to try to recall java a bit ;) | 22:23 |
| persia | sistpoty: `jar tvf foo.jar` should show you the contents. | 22:23 |
| rmunn | I'm going to try to persuade upstream not to distribute the .jar file in the .tar.gz source in the future, but it's too close to Lucid freeze for me to want another round of back-and-forth emails. :-) | 22:23 |
| rmunn | Jar files are .zip files renamed, "unzip -l nltk.jar" will show you its contents too. | 22:24 |
| paissad | guys, i uploaded my package, but i have a warning , i'm a lillte bit confused ! http://revu.ubuntuwire.com/p/pms-linux | 22:26 |
| persia | rmunn: Yeah, but people who use tar a lot prefer that interface :) | 22:26 |
| rmunn | http://pastebin.com/f37527b42 shows contents of the nltk.jar file from original upstream tarball, BTW. | 22:26 |
| rmunn | persia, I didn't remember there was a "jar" command so I used "file" and discovered it was a .zip... :-) | 22:26 |
| persia | paissad: That's just lintian being confused. Override them. | 22:27 |
| persia | rmunn: Yeah well, java people use jar :) | 22:27 |
| paissad | persia, i had no warnings when i run lintian -iIEV -pedantic | 22:27 |
| rmunn | persia, It's been ages since I did any real work in Java... basically since I discovered Python, I don't use any other language by choice -- only when contributing to a project that uses something else. | 22:27 |
| persia | paissad: Odd, I'd have expected that one to show up. | 22:28 |
| paissad | persia, :) | 22:28 |
| persia | paissad: Could be that the newer lintian you're using locally doesn't get confused as easily. | 22:28 |
| paissad | persia, Lintian v2.3.2ubuntu1 | 22:28 |
| persia | paissad: If you're clean locally (source and binary) ignore REVU's lintian messages. | 22:28 |
| persia | Yeah, that's newer than the one on REVU. | 22:29 |
| paissad | ok | 22:29 |
| paissad | persia, i hope that the package will be available for lucid lynx ... many users are expecting it ... currenty they are downloading it from my personal repository ... i cannot play anymore in network with my PS3 because of downloads from the repo, ... i got many lags :/ ... | 22:30 |
| sistpoty | rmunn: having thought about it for a bit, I think it's save to leave the .jar there, since all the source are present, and imho the java compile doesn't inline anything (at least from thinking a bit what the goals of a jvm are) | 22:32 |
| persia | The main trick with .jar files in sources (if they are clean) is to remember to delete them right away to avoid the chance that they are used in the final output. | 22:33 |
| persia | (otherwise one runs the risk of hidden code paths being promulgated) | 22:34 |
| rmunn | sistpoty, Allowing the .jar file to be installed without recreating it in build step runs the risk of a Trojaned .jar file being inserted at some point in the upstream tarball. Recreating it from verifiable sources is best for security. | 22:34 |
| sistpoty | rmunn: *nod* | 22:35 |
| rmunn | So I delete it in clean -- and once Mallet is packaged for Debian (prolly in Lucid+1) I'll be able to recompile the .jar. | 22:35 |
| persia | Right. | 22:36 |
| rmunn | Right now I've just disabled the NLTK-to-Mallet interface that used that .jar (with upstream's approval) so that the package can get into Lucid. And in the process, I discovered a bug in the upstream code -- that interface was broken anyway :-O, so users won't actually notice any difference. | 22:36 |
| sistpoty | crap, etree license looks out for problems: it demands having read (and agreed to) the license to *use* it | 22:36 |
| rmunn | sistpoty, Does that violate DFSG? | 22:37 |
| sistpoty | rmunn: no, but it means that the license needs to be displayed to the user (if the files are used in the first place) before she can use the software | 22:38 |
| rmunn | I checked on the origin of the etree library in the NLTK code by looking at upstream's SVN logs: it was copied from the Python 2.5 code, not from the python-elementtree package. In case that makes any difference. | 22:38 |
| sistpoty | I assume then the python license would apply? | 22:39 |
| rmunn | sistpoty, Huh. I'm pretty sure upstream isn't doing that... | 22:39 |
| sistpoty | (unless it allows to change the license, damn copyright stuff) | 22:39 |
| paissad | i thank everyone here for the help, it's very kind ! | 22:40 |
| rmunn | The code comments give that license that I copied into debian/copyright, then the phrase "Licensed to PSF under a Contributor Agreement. See http://www.python.org/2.4/license for licensing details." | 22:40 |
| rmunn | The license text at that URL does not contain the word "contributor", so I can't research further. | 22:41 |
| sistpoty | did I mention yet, that I really hate license problems? :) | 22:42 |
| rmunn | ... And now that I think about it, the etree license says "By obtaining, using, and/or copying this software ... you agree that you have read, understood, etc. the following: Permission to use, cop, modify, and distribute ... is hereby granted, provided that the above copyright notice appears in all copies ... [and] in supporting documentation." | 22:43 |
| persia | Text like that typically requires the annoying debconf-show-the-license hack, and users hate it. | 22:43 |
| rmunn | There's nothing in the conditions that the user could possibly be in violation of by simply using it. | 22:44 |
| persia | Doesn't matter, because of the "obtaining, using" bit. | 22:44 |
| rmunn | ... In fact, "by obtaining" would require showing the license BEFORE the download if you go by that interpretation. | 22:44 |
| * persia gets extra grumpy at folk who use odd licenses | 22:44 | |
| persia | rmunn: Good point, but it means that it's not redistributable with our archive model. | 22:45 |
| rmunn | persia, But this code is part of Python. Surely this was worked out at some point before? | 22:45 |
| rmunn | Otherwise the same problems that apply to this code would apply to Python 2.5 and onwards. | 22:46 |
| ryanakca | Could someone review http://revu.ubuntuwire.com/p/turnin-ng please? | 22:46 |
| persia | rmunn: Would it be possible to delete the offending code from the tarball and build against the system library? | 22:46 |
| sistpoty | actually, I may have been nitpicking on the license. The problem (and why I hate copyright stuff) is that I just don't know how to read it | 22:46 |
| dupondje | gnucash is ftbfs, but if we want to fix it, we introduce a new bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567208 what is considered the best option then ? keep it ftbfs or ? | 22:47 |
| ubottu | Debian bug 567208 in gnucash "Gnucash 2.2.9-3 has no graphing support" [Serious,Open] | 22:47 |
| sistpoty | maybe a copyright expert might have an opinion on http://revu.ubuntuwire.com/revu1-incoming/python-nltk-1002101912/python-nltk-2.0~b8/debian/copyright, slangasek? (for example the etree license) | 22:48 |
| persia | ryanakca: I don't have time for a full review right now, but I don't see why you shouldn't create the empty /srv/... directories on package install. The rest of the packaging looks sane from an initial glance. | 22:48 |
| rmunn | persia, It would be possible, but I haven't looked into the NLTK code to see what parts of it import nltk.etree internally. I hesitated to do so at first because I didn't want to diverge from upstream without a compelling reason -- but licensing issues would be compelling. | 22:48 |
| persia | RIght. | 22:50 |
| paissad | btw, i would like to know if it is possible to make the uploaded package available from download like a normal repository ? | 22:50 |
| persia | One of the reasons reviewers get harder to find as the packaging gets better is because licensing review becomes more important, and it's painful. | 22:50 |
| ryanakca | persia: Because different universities like things in different places | 22:51 |
| sistpoty | rmunn: looking at the suggests (e.g. numpy) and just grepping in the source code, are these meant to be suggests? (grep revealed import statements w.o. try-catch) | 22:51 |
| persia | ryanakca: In that case, I don't see any obvious issues :) | 22:52 |
| rmunn | sistpoty, I thought about making them Recommends, but Debian policy seemed to say "If the package would work with Suggests, use Suggests." | 22:52 |
| sistpoty | rmunn: ok, so the files that do imports aren't needed for the average user, right? | 22:53 |
| rmunn | Right -- they're for people doing statistical analysis, graphs of word frequency, etc. | 22:53 |
| sistpoty | ok, thanks! | 22:54 |
| rmunn | I would actually prefer to add a Recommends rather than a Suggests, but some tools pull in all Recommends: packages automatically, and I don't want to pull in python-matplotlib and all its dependencies (including X) on someone's text-only system when they can use NLTK just fine without it. | 22:54 |
| sistpoty | rmunn: ok, nice rationale. just advocated the package, since my concerns regarding copyright really are beyond my knowledge about licensing | 22:57 |
| rmunn | BTW, as far as the etree copyright issue is concerned: run "sudo apt-get install python-elementtree". Notice that it does not use the debconf hack to display the license before installing, despite the fact that it has the same "By using, etc." license. | 22:58 |
| sistpoty | heh | 22:59 |
| rmunn | So clearly, the Debian maintainer who added that package in 2004 didn't see a problem with that license. | 22:59 |
| sistpoty | well, as I wrote, I just don't know if it's a problem in the first case ;) | 23:00 |
| rmunn | :-) | 23:02 |
| rmunn | I'll add a comment of my own to the REVU page in case another MOTU has questions about it. | 23:03 |
| ryanakca | persia: OK, thanks :) | 23:05 |
| rmunn | sistpoty, Thanks for the review and advocacy. | 23:08 |
| sistpoty | rmunn: thanks for your work! | 23:09 |
| rmunn | persia, Thanks for your comments on the .jar file and licensing. Would you recommend that I make major changes to the package at this point to tear out nltk/etree/* and replace it with a python-elementtree dependency, even though that would almost certainly mean not getting this package into Lucid? Or is the "python-elementtree has had this license since November 2004 and Debian accepted it" argument enough precedent for letting | 23:11 |
| rmunn | the etree-licensed code stand as-is? | 23:11 |
| rmunn | I was doubtful about the license issue until I saw that python-elementtree uses the same license and had had no copyright issues raised in five years -- that settled it for me. :-) | 23:12 |
| persia | rmunn: I recommend you do the work to strip out the embedded libraries, and then upload the result to Debian. | 23:13 |
| persia | rmunn: I agree that you're unlikely to finish by the 18th, so may as well take your chances on the current package in REVU for lucid. | 23:13 |
| slangasek | sistpoty: was there a specific concern in this license? | 23:14 |
| sistpoty | slangasek: yes, covering "use" | 23:14 |
| persia | Also required acceptance for "obtaining" the code. | 23:14 |
| slangasek | ou may not use this file except in compliance with the License. | 23:14 |
| slangasek | "you may not use this file except in compliance with the License." - that bit? | 23:14 |
| sistpoty | exactly, slangasek | 23:14 |
| persia | "By obtaining, using, and/or copying this software ... you agree that you have read, understood, etc. the following: Permission to use, cop, modify, and distribute ... is hereby granted, provided that the above copyright notice appears in all copies ... [and] in supporting documentation." | 23:14 |
| rmunn | slangasek, The etree license says "By obtaining, using, and/or copying ... you agree that you have read ... the following terms and conditions." | 23:14 |
| slangasek | is that enforceable anywhere? | 23:15 |
| * persia doesn't think so | 23:15 | |
| rmunn | Thing is, the python-elementtree package uses that exact same license, and has been in Debian since November 2004 without (to my knowledge) any issues being raised. | 23:15 |
| * sistpoty has no clue | 23:15 | |
| slangasek | I'd be inclined to ignore it as invalid on its face | 23:15 |
| rmunn | And yeah, the "obtaining" bit would require reading the license before even downloading it... classic "shrinkwrap" license problem as I understand the legalities (IANAL, of course) | 23:16 |
| slangasek | clickwrap/shrinkwrap are somewhat enforceable; a random license attached to the file is not | 23:16 |
| slangasek | (file, download, package) | 23:16 |
| sistpoty | thanks for your insight slangasek! | 23:16 |
| persia | rmunn: Just to confirm, you didn't have to go through a license approval step in order to download the uptream tarball, did you? | 23:16 |
| slangasek | unless the license itself requires that, when distributing, you ensure the people you're *distributing* to have read the license, then *shrug* it's unenforceably | 23:17 |
| rmunn | persia, Correct. I downloaded it from http://code.google.com/p/nltk/downloads/list | 23:17 |
| slangasek | -y+e | 23:17 |
| rmunn | At no point was I required to click "I accept", either to download the file or to unpack the tarball. | 23:17 |
| persia | slangasek: I've been interpreting licenses as potentially valid, if pointless, and claiming those are upstream bugs that ought be fixed. Do we generally ignore these cases (in which case I should be less picky)? | 23:18 |
| sistpoty | he, so I learned another thing: If a license statement is not enforcable, ignore it. Only problem I have that I absolutely don't know if a license statement *is* enforcable *g* | 23:18 |
| rmunn | As I understand U.S. law, you generally don't *know* (with 100% certainty) what parts of a contract is unenforceable until a suit is brought and the judge rules on it. | 23:19 |
| rmunn | ^is^are | 23:19 |
| rmunn | "what parts ... *are* unenforceable" | 23:19 |
| sistpoty | best package I ever reviewed was where the reviewee's wife was a lawyer and he simply asked her for an opinion *g* | 23:20 |
| persia | rmunn: That's the case everywhere, I believe (or at least I don't know of any jurisdiction in which rulings can be taken by other than counterparty consensus without a bench ruling (for some definition of "bench") | 23:20 |
| slangasek | persia: ignoring the intent of the copyright holder is not normally my preference, but in cases such as this where there's no conceivable way they could make it binding on the user, I'm ok with accepting it (while treating it as an upstream bug that ought to be fixed) | 23:20 |
| slangasek | rmunn: legal nihilism isn't a very practical strategy when one is in the business of distributing free software | 23:21 |
| rmunn | Incidentally, here's the copyright holder's own download page: http://effbot.org/downloads/#elementtree | 23:21 |
| persia | slangasek: OK. So I'll be just as picky in my complaints, but maybe let some pointless stuff slide through to the archive admins :) | 23:21 |
| slangasek | sounds good :) | 23:21 |
| rmunn | No "you must agree to the license in order to download this" anywhere on his page that I can see. So the copyright holder isn't enforcing the "by obtaining" part of his own license, as best as I can tell. | 23:22 |
| rmunn | slangasek, Good point re: legal nihilism. :-) | 23:22 |
| persia | rmunn: File an upstream bug :) | 23:22 |
| sistpoty | persia: of course asking for an expert opinion beforehand might not only enlighten you but others as well (e.g. me *g*) | 23:22 |
| rmunn | persia, But where -- in NLTK, or in Python which uses the same code (which NLTK got it from), or against ElementTree saying "Hey, your license is unenforceable"? :-) | 23:23 |
| persia | sistpoty: The risk is that in many jurisdictions the act of asking anyone qualified to give an opinion creates a state that requires another qualified person to discuss. I prefer to talk to people who are knowledgeable and interested, yet not actually qualified :) | 23:23 |
| persia | rmunn: Yes. | 23:24 |
| * persia would prefer the position of "magistrate" did not exist anywhere | 23:24 | |
| slangasek | heh | 23:24 |
| sistpoty | persia: heh, well, but I guess the statement of slangasek was understandable, even to a non-law-informed person as /me wasn't it? ;) | 23:25 |
| persia | sistpoty: Indeed it was. I'm just under the impression that slangasek isn't "qualified", and I know he lives in a jurisdiction that allows lay arguments with qualified opinions. | 23:26 |
| sistpoty | haha | 23:26 |
| slangasek | IANAL, FWIW ;) | 23:26 |
| persia | (although I do believe slangasek is expert in the area) | 23:26 |
| sistpoty | heh | 23:26 |
| paissad | damn it, i got another error :( ... which of these two is correct for the changelog file ? .......(Closes: #nnnn) or (LP: #nnnn) | 23:26 |
| paissad | ? | 23:26 |
| paissad | Debian uses Closes: #nnnn ... | 23:26 |
| rmunn | paissad, It's "Closes LP: #nnnn" for Launchpad bugs. | 23:26 |
| persia | paissad: The former closes bugs in the Debian BTS (if uploaded to Debian), and the latter Ubuntu bugs in launchpad (if uploaded or synced to Ubuntu). | 23:27 |
| sistpoty | paissad: for ubuntu, it's LP: #<bugnumber>, for debian closes: #<bugnumber> | 23:27 |
| sistpoty | paissad: for ubuntu, just look at the generated .changes file. it should contain "launchpad-bugs-fixed: <bugnumber" | 23:27 |
| paissad | here is the changelog file http://pastebin.com/f102f3ec6 .. would you like to correct it please ? | 23:27 |
| rmunn | FYI for anyone else looking at http://revu.ubuntuwire.com/p/python-nltk, I'll be on for another 30 minutes then I have to leave. So if you have any other concerns that I might need to address, please let me know now. :-) | 23:28 |
| sistpoty | paissad: version number should be 1.20+svn386-0ubuntu1 | 23:28 |
| paissad | sistpoty, ok thanks ... i will add it | 23:29 |
| sistpoty | paissad: otherwise it *looks* correct | 23:29 |
| rmunn | Shouldn't it be "Initial release. (Closes LP: #521180)" in the changelog? | 23:29 |
| rmunn | (I.e., you need to add the word "Closes") | 23:29 |
| persia | rmunn: probably not. | 23:29 |
| sistpoty | rmunn: no, afaict the regexp is just LP: [0-9]+ | 23:29 |
| paissad | sistpoty, why 0-ubuntu1 ? ..... if i rebuild the same version of the package, how must i rename it ? | 23:30 |
| persia | rmunn: That *might* work (but I don't think so) in the unlikely event that one managed to have the *same* bug number in the Debian BTS and launchpad/ubuntu | 23:30 |
| geser | no, the regex matches on lp: #xxxxx (in small or big letters) | 23:30 |
| sistpoty | geser: thanks! | 23:30 |
| sistpoty | paissad: if the package is uploaded in debian, the revision would be -1 | 23:30 |
| sistpoty | paissad: in Ubuntu we try to sync/merge what we can from debian, so the version should be lower | 23:31 |
| sistpoty | paissad: so -0ubuntu1 is lower than the initial debian version | 23:31 |
| paissad | sistpoty, ok i got it now :) thanks | 23:31 |
| sistpoty | yw | 23:31 |
| geser | the exact regexp is: /lp:\s+\#\d+(?:,\s*\#\d+)*/ig | 23:32 |
| * sistpoty just relies on vim highlighting *g* | 23:33 | |
| sistpoty | geser: I see you've got a sponsor request open for main (bug #520648). Teach me how to use bzr, and I'll happily upload for you ;) | 23:35 |
| ubottu | Launchpad bug 520648 in mknbi "Re-add -fno-stack-protector to CFLAGS" [Undecided,New] https://launchpad.net/bugs/520648 | 23:35 |
| geser | sistpoty: sure, https://wiki.ubuntu.com/DistributedDevelopment/Documentation in case you want to read it yourself | 23:36 |
| geser | do you have bzr and bzr-builddeb installed? | 23:37 |
| sistpoty | geser: bzr: yes, bzr-builddeb: no clue, but I can install that | 23:37 |
| jariq | What should be the right status of "needs-packaging" bug after package was accepted ??? | 23:38 |
| sistpoty | geser: ok, I just did bzr branch lp:... and got some files now (it worked, for $whatever reasons, usually that failed since I don't want to set the bzr-lp cookie thingy) | 23:38 |
| geser | sistpoty: bzr merge lp:~geser/ubuntu/lucid/mknbi/bug-520648 inside the branch | 23:39 |
| sistpoty | geser: oh, I only got your branch *g*... /me retries | 23:40 |
| geser | ah, you need to do bzr branch lp:ubuntu/mknbi to get the packaging branch | 23:40 |
| geser | first | 23:40 |
| geser | and merge my branch on top of it | 23:41 |
| sistpoty | already at it, I think I'm on a route to find out the workflow | 23:41 |
| sistpoty | geser: ok, bzr diff looks good. what now? | 23:43 |
| * sistpoty would go bzr diff > debdiff now, and apply that to the sourcepackage, but there's for sure an easier way | 23:43 | |
| geser | bzr commit | 23:43 |
| sistpoty | geser: does that mean I upload the package already? | 23:44 |
| sistpoty | geser: I'd like to first test-build it | 23:44 |
| geser | bzr bd -S | 23:44 |
| geser | with commit you commit the changes to your local branch (it doesn't get into LP unless you push it) | 23:45 |
| sistpoty | geser: ah, right I slowly recall bzr | 23:45 |
| geser | (only with a checkout a commit would go directly to LP) | 23:45 |
| sistpoty | heh, I'm still mainly used to central VCSes through work | 23:46 |
| sistpoty | geser: ftbfs on amd64: first32.c:1: error: CPU you selected does not support x86-64 instruction set | 23:47 |
| geser | if you need to pass any other debuild options to "bzr builddeb" (long for of "bzr bd") pass them after a --, e.g.: bzr bd -S -- -us -uc | 23:47 |
| sistpoty | thanks! | 23:48 |
| geser | sistpoty: :) you need to build on i386 | 23:48 |
| geser | it's i386 only in P-a-s | 23:48 |
| sistpoty | geser: ah, crap, need to get a proper chroot for that first... give me some time... but anyways I think I know the basics now, thanks a lot! :) | 23:48 |
| geser | sistpoty: https://edge.launchpad.net/~geser/+archive/ppa/+sourcepub/962826/+listing-archive-extra | 23:49 |
| geser | I had the same problem and used my PPA for a test-build on i386 | 23:49 |
| geser | the only difference to the merge proposal is the package revision string | 23:50 |
| sistpoty | <- doesn't have a ppa, yeah, I'm just oldschool probably *g* | 23:50 |
| dupondje | need some help on a merge. I have downloaded newest version from debian sid, added a dpatch in the patch folder, removed a dpatch, did a dch -i with some comments, then did a debuild but then ? how to get it into Lucid ? | 23:51 |
| sistpoty | geser: I just want to rebuild it myself... doesn't mean I wouldn't fully trust your merge, but I never upload things I cannot rebuild myself (*with only one exception so far, which gladly was rejected due to a wrong version number) | 23:54 |
| geser | dupondje: have you already created a debdiff? | 23:55 |
| dupondje | just created a debdiff ... new bugreport and post the debdiff ? | 23:56 |
| geser | yes | 23:56 |
| lfaraone | Does anybody have time to do a pre-flight-check of groundcontrol? It's an app that does LP nautilus integration, and all the problems that persia found have been fixed. http://revu.ubuntuwire.com/details.py?upid=7663 | 23:56 |
| geser | sistpoty: let me know when you are done with test-building | 23:56 |
| geser | lfaraone: you mustn't edit files from other packages (/etc/xdg/user-dirs.defaults) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
