| StevenK | directhex: I love the "migrated-to-git" in that path | 00:00 |
|---|---|---|
| directhex | StevenK, well, yes. but the version in git doesn't use a patch anymore it ships an entire replacement ltmain.sh (as every update to the toolchain broke patching). and i can't work out how to display that old version in the web gui | 00:01 |
| StevenK | And people say git isn't hostile to users. | 00:02 |
| MTecknology | I like git | 00:03 |
| MTecknology | I have yet to really learn it... but it's nice | 00:04 |
| directhex | StevenK, git isn't hostile to users, it's hostile to *potential* users! | 00:06 |
| === golddragon24_ is now known as golddragon24 | ||
| MTecknology | How was it that you apply a patch? | 00:41 |
| mok0_ | MTecknology: patch < file | 00:42 |
| rhpot1991 | for anyone who knows library packages well, I have one that I patched upstream's build process to include soname data into the library, now my resulting file seems ok (I think), but the symlink is a little off: | 00:43 |
| rhpot1991 | -rw-r--r-- 1 root root 63K 2010-01-29 16:09 /usr/lib/libhdhomerun.so.1.0.0 | 00:43 |
| rhpot1991 | lrwxrwxrwx 1 root root 21 2010-01-29 16:43 /usr/lib/libhdhomerun.so.1.0.0.1 -> libhdhomerun.so.1.0.0 | 00:43 |
| persia | What's wrong with that? | 00:43 |
| MTecknology | mok0_: so simple :P - first chunk good second bad | 00:44 |
| MTecknology | time to dig into it | 00:44 |
| persia | Or did you want libhdhomerun.so ? | 00:44 |
| rhpot1991 | it should be libhdhomerun-so.1 -> libhdhomerun.so.1.0.0 I think | 00:44 |
| rhpot1991 | lintian throws a warning too, let me get that | 00:44 |
| rhpot1991 | also hi persia | 00:44 |
| persia | No need to paste. | 00:44 |
| mok0_ | rhpot1991: libdhomerun.so.1 -> etc. | 00:44 |
| persia | Easy way to fix is to not install the link with dh_install, and use dh_link to make the links you want (.so.1 in libfoo, .so in libfoo-dev) | 00:45 |
| mok0_ | rhpot1991: and in the -dev package libhomerun.so -> etc. | 00:45 |
| mok0_ | Hi persia, up so early? | 00:45 |
| rhpot1991 | hmmm, I am using the dev package for some library files thare are needed to install | 00:45 |
| persia | mok0_: It's not that early :) | 00:46 |
| rhpot1991 | https://code.launchpad.net/~rhpot1991/libhdhomerun/trunk | 00:46 |
| rhpot1991 | if you guys want to look | 00:46 |
| rhpot1991 | doesn't include the latest patching yet, as I'm still working on that | 00:46 |
| rhpot1991 | so after the resulting build I have libhdhomerun.so.1.0.0, does that sound correct? | 00:46 |
| mok0_ | rhpot1991: that file should have some bytes in it | 00:47 |
| rhpot1991 | mok0: sorry don't understand what you are saying | 00:47 |
| mok0_ | rhpot1991: the .so.1 file is just a symlink | 00:47 |
| rhpot1991 | ya | 00:47 |
| mok0_ | rhpot1991: sorry, the so.1.0.0 file is a real file with some size | 00:48 |
| rhpot1991 | mok0: the issue here is that upstream wasn't keeping any soname data so I am trying to fix thigns and get them a patch | 00:48 |
| rhpot1991 | yep | 00:48 |
| persia | That filename looks sane. Just play with dh_link for the other bits. | 00:48 |
| rhpot1991 | so I make that file, symlink | 00:48 |
| mok0_ | rhpot1991: are they using libtool etc? | 00:48 |
| rhpot1991 | .so to it, so I don't break the build | 00:48 |
| rhpot1991 | mok0: just gcc, I think | 00:49 |
| rhpot1991 | mok0: http://bazaar.launchpad.net/~rhpot1991/libhdhomerun/trunk/annotate/head%3A/Makefile | 00:49 |
| MTecknology | directhex: I'm trying out that patch now | 00:49 |
| rhpot1991 | thats the no symlink file version, I just fixed the gcc command | 00:49 |
| rhpot1991 | persia: yep I think I'm on the right path, just trying to figure out why my linkage is off. Do I need to do libfoo.so in my dev package? | 00:50 |
| rhpot1991 | right now my dev package is just some .h files that are build dependencies for the GUI | 00:50 |
| mok0_ | Well, you need at least a symlink called *.so.1 | 00:50 |
| mok0_ | rhpot1991: persia is right, just do it with dh_link | 00:51 |
| rhpot1991 | mok0: ya, I was hoping that debhelper 7 would do all that magic for me but it did it incorrectly, so I'll see what I can do with dh_link | 00:51 |
| mok0_ | rhpot1991: if users need to be able to use the library for developement, you need another symlink called *.so | 00:51 |
| mok0_ | rhpot1991: that symlink is normally included in the -dev package | 00:52 |
| rhpot1991 | mok0: the library is only used when running the GUI, if its safer to add it to the dev package I can | 00:52 |
| persia | rhpot1991: dh(1) does the magic dh_link call, but you need to feed it the source data. | 00:52 |
| rhpot1991 | persia: would make sense, I have a very minimal rules file | 00:52 |
| mok0_ | persia: eerr? source data? | 00:53 |
| persia | mok0_: debian/links | 00:53 |
| mok0_ | ah source of the symlink? | 00:53 |
| mok0_ | heh ok | 00:53 |
| rhpot1991 | persia: mok0: ok so doing dh_link does what I want, I still have that incorrect link hanging around though, do I need to override something in rules to get it to stop doing that? | 01:13 |
| rhpot1991 | still have the same lintian error/warning too: | 01:13 |
| rhpot1991 | E: libhdhomerun1: ldconfig-symlink-missing-for-shlib usr/lib/libhdhomerun.so.1.0.0.1 usr/lib/libhdhomerun.so.1.0.0 libhdhomerun.so.1.0.0.1 | 01:13 |
| rhpot1991 | W: libhdhomerun1: package-name-doesnt-match-sonames libhdhomerun1.0.0.1 | 01:13 |
| persia | rhpot1991: So, you have debian/libhdhomerun.install and debian/libdhhomerun-dev.install, right? Just construct the globs in these files not to include the link you don't like. | 01:14 |
| rhpot1991 | persia: yes, but neither of those do the symlinking or call ldconfig or anything, I think dh7 is automagically making that happen | 01:15 |
| rhpot1991 | persia: also I have no idea where libhdhomerun.so.1.0.0.1 is coming from, all I make is 1.0.0 | 01:15 |
| persia | rhpot1991: ldconfig is called by dh_makeshlibs, which doesn't make the symlink. The symlink is likely constructed by the upstream build system, and then copied by dh_install. | 01:17 |
| persia | But try setting DH_VERBOSE=1 in debian/rules, and check the log to see more details. | 01:17 |
| === zooko` is now known as zooko | ||
| rhpot1991 | persia: yep, I screwed up the soname injection and thats where the extra came from. So the file name itself will be .so.1.0.0, should the soname data be 1 or 1.0.0? | 01:25 |
| persia | rhpot1991: I usually just use upstream SONAME & .so (in -dev). I don't know precisely how the fallback searches work. | 01:30 |
| rhpot1991 | persia: I see another complication arising, their GUI looks for .so specifically, will it be an issue if that is symlinked in libhdhomerun1 or should I depends on -dev? | 01:32 |
| persia | rhpot1991: How does the GUI depend on .so? Please double-check with nm. | 01:33 |
| rhpot1991 | nm? | 01:34 |
| persia | If the GUI is manually checking for the .so, that's probably pointless in a distribution context. | 01:34 |
| persia | man nm :) | 01:34 |
| rhpot1991 | heh sorry | 01:34 |
| rhpot1991 | lets find somewhere that I still have it installed | 01:34 |
| persia | sispoty gave a session about this a while ago, with some nice nm usage notes: https://wiki.ubuntu.com/MOTU/School/LibraryPackaging | 01:35 |
| rhpot1991 | persia: it fails to run if its not there | 01:35 |
| rhpot1991 | thanks, looking now | 01:35 |
| persia | There's probably either something broken in the linking, or in how the SONAME is advertised at link time. | 01:36 |
| rhpot1991 | persia: keep in mind they had no SONAME data at all | 01:36 |
| rhpot1991 | persia: maybe I haven't read enough yet, but there are no object files here in the source | 01:38 |
| persia | An ELF executable is an object file. | 01:39 |
| rhpot1991 | nm: /usr/bin/hdhomerun_config_gui: no symbols | 01:39 |
| rhpot1991 | persia: I'll finish up my work with the library first and verify that it errors with the SONAME'd library in place | 01:40 |
| rhpot1991 | then I'll worry about it then if its still an issue | 01:41 |
| persia | Good luck :) | 01:41 |
| rhpot1991 | thanks | 01:41 |
| rhpot1991 | I'll let you know how it goes, and maybe you can take a look at the package then | 01:41 |
| spwelton | hi guys! Quick question: If I wrote an app in python that I think might be well-served in the universe repository, how might I go about getting it added? It's already in my personal PPA on launchpad. | 01:47 |
| persia | spwelton: Well, you'd need a developer to upload it, and that developer would be encouraged to get peer review. | 01:49 |
| persia | We tend to use REVU as a platform for this, but just uploading it there doesn't always get the interested developer to upload it. | 01:49 |
| persia | !REVU | 01:49 |
| ubottu | REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU | 01:49 |
| spwelton | persia: Hmmm, that looks interesting, I'll give that a look | 01:50 |
| persia | An alternate strategy would be to get it into Debian, and then Ubuntu would sync it. | 01:50 |
| persia | But getting into Debian is a similar model, in that you need a Debian Developer to upload it. | 01:50 |
| spwelton | its a realllllly simple program, only like 200 lines | 01:51 |
| persia | Mind you, you could become an Ubuntu or Debian Developer, but that's a *lot* of effort if your goal is just to get one app included :) | 01:51 |
| spwelton | its just a countdown timer, for cooking and whatnot, since i couldn't find anything in the repo | 01:51 |
| spwelton | also what all is entailed in being an ubuntu dev? I've always wanted to contribute something, but I'm a grad student and don't have a whole lot of free time | 01:52 |
| persia | spwelton: For GNOME, I use the Alarm Clock applet, which can do timers or set times. | 01:54 |
| persia | Some of our most active contributors are grad students who need excuses to avoid theses :) | 01:54 |
| spwelton | persia: hmm, i must've missed that one.. oh well the app is already written | 01:54 |
| persia | But it's mostly a matter or working with one of the dev teams to help solve their problems. My personal recommendation is to file patches to fix bugs that bother you with your installation to get started. | 01:55 |
| spwelton | can i fix bugs at leisure even if I'm not a dev? | 01:57 |
| persia | Sure. You just can't upload. | 01:58 |
| persia | The process tends to work about like this: someone starts providing patches, and ends up finding communication channels for a dev team with similar interests. | 01:58 |
| persia | That person ends up getting a lot of work sponsored by that team, and the team encourages the person to apply. | 01:58 |
| persia | The person joins the team, and is now an Ubuntu Developer, and can upload. | 01:59 |
| spwelton | cool | 02:00 |
| spwelton | ok, so i set up REVU and sent my program via dput, does it take a few minutes to show up like launchpad? | 02:02 |
| persia | I think the cronjob is running about once every five minutes. If it doesn't show, ask here for a REVU admin to look and see why it didn't appear. | 02:03 |
| spwelton | ah-ha! I see it now | 02:03 |
| persia | Cool! | 02:03 |
| spwelton | http://revu.ubuntuwire.com/p/eggtimer | 02:05 |
| spwelton | the page reports a few warnings, is this normal? | 02:05 |
| RAOF | spwelton: It's common, and in that sense it's normal. You *do* want to fix all of them, though. | 02:12 |
| RAOF | spwelton: The two lintian warnings should be easy to fix, and should be fixed. The maintainer field, likewise. | 02:13 |
| spwelton | it says i need an @ubuntu.com e-mail... where do i get that/ | 02:13 |
| RAOF | spwelton: It also says that the @ubuntu.com email address should usually be the MOTU team's address. | 02:14 |
| RAOF | Running “update-maintainer” in your source directory will probably do the right thing. | 02:15 |
| RAOF | The only warning that you *might* not have to fix before someone is willing to sponsor is the debian/watch / get-orig-source warning. I'm not sure how strict sponsors are being at the moment about that. Everything else should definitely be fixed, and as it's really easy to fix the watch file warning too, it should be fixed. | 02:16 |
| spwelton | the email I'm finding for the MOTU is universe-bugs@lists.ubuntu.com is this correct? | 02:17 |
| === mdomsch_ is now known as mdomsch | ||
| wrapster | hi | 04:17 |
| wrapster | i was building the 64bit version of tspi.. and it was working fine all the while all of a sudden i get this error.. http://pastie.org/804147 | 04:23 |
| wrapster | i have not made any changes.... | 04:23 |
| wrapster | why so.. | 04:23 |
| micahg | is it bad form to e-mail a DD about whether or not they plan on upgrading a package? | 04:33 |
| slytherin | micahg: Was there already a bug about upgrade? | 04:36 |
| micahg | no, I'm just wondering if I should file one or contact the DD directly | 04:36 |
| micahg | it's for sqlite | 04:36 |
| persia | micahg: Yes. It's better form to submit a bug to the BTS asking the question. This will notifiy the maintainer in a way that they prefer. | 04:37 |
| micahg | persia: k, I'll do that, thanks | 04:37 |
| slytherin | micahg: Ideally bug filing is the first step you do. If the maintainer does not respond for long time (say a month) then you can mail him. | 04:37 |
| micahg | slytherin: I'm worried about freeze | 04:38 |
| persia | Definitely file a bug. It's impossible to know who happens to be the person most likely to do the upgrade from the inforamtion available from the last upload (although one can make good guesses), whereas it's a certainty that whoever does the next upload should have at least reviewed the bugs in the BTS. | 04:39 |
| slytherin | micahg: Which freeze? Debian's or Ubuntu's? | 04:39 |
| micahg | ubuntu | 04:39 |
| slytherin | In worst case you will have to request for freeze exception for package. | 04:39 |
| StevenK | As in, DIF? | 04:39 |
| micahg | slytherin: k | 04:39 |
| micahg | is there any chance of approval? | 04:39 |
| StevenK | Don't worry about DIF, you can still request syncs manually without approval after DIF | 04:39 |
| micahg | StevenK: Ubuntu FF in 2 weeks | 04:39 |
| StevenK | micahg: If it's just a bug fix release and doesn't include any features, it doesn't require an FFe | 04:40 |
| micahg | StevenK: says there's enhancements... | 04:41 |
| MTecknology | install -m 644 -D lal.1.gz ${DESTDIR}/${PREFIX}/share/man/man1/lal.1.gz | 04:48 |
| MTecknology | -D should create the directory if it doesn't exist, right? | 04:49 |
| persia | Yes | 04:49 |
| MTecknology | it doesn't | 04:49 |
| slytherin | MTecknology: AFAIK, no. | 04:49 |
| MTecknology | install: accessing `/usr/local/share/man/man1/lal.1.gz': Not a directory | 04:50 |
| persia | It should, from the manpage | 04:50 |
| persia | Ah, nevermind. syntax. | 04:50 |
| persia | Should be install -m 644 -D lal1.gz ${DESTDIR}/${PREFIX}/share/man/1 | 04:50 |
| slytherin | MTecknology: You can simply create a file debian/package.manpages and add the name of manpage file in it. Then dh_installman will take care of the rest. | 04:50 |
| persia | slytherin: This is an *upstream* makefile that's being constructed. | 04:51 |
| slytherin | Oh. I thought it was rules file | 04:51 |
| MTecknology | :D | 04:52 |
| persia | Common mistake :) I think MTecknology is off-topic, but it's worth kinda supporting upstreams. We ought have a channel for that. | 04:52 |
| MTecknology | persia: I actually submitted a lot of code for this project that is in there now; never saw the code until a week ago when I decided I want to package it :) | 04:53 |
| MTecknology | persia: #ubuntu-upstream? | 04:54 |
| MTecknology | persia: interesting is that it doesn't want to install; it doesn't throw errors - but the files don't seem to be there | 04:59 |
| MTecknology | persia: install -m 644 -D lal.1.gz /usr/local/share/man/man1; that installs the file at man1 which makes man1 not a directory but the man page itself | 05:06 |
| MTecknology | install -m 644 -D lal.1.gz /usr/local/share/man/man1/; doesn't work either | 05:06 |
| MTecknology | eh - I'll look into it more tomorrow - g'night | 05:09 |
| lifeless | MTecknology: install -m 644 -D lal.1.gz /usr/local/share/man/man1/lal.1.gz | 05:09 |
| MTecknology | lifeless: if the directory doesn't exist that doesn't work though.. | 05:09 |
| MTecknology | lifeless: unless I screwed it up earlier.... | 05:10 |
| MTecknology | yup..... | 05:11 |
| persia | lifeless: Hrm. That's very confusing, but thanks for the correction. | 05:12 |
| MTecknology | yup - I screwed it up prior | 05:13 |
| MTecknology | thanks :D | 05:13 |
| lifeless | no probs | 05:13 |
| MTecknology | sleep! | 05:15 |
| === micahg1 is now known as micahg | ||
| micahg | I seem to be having a problem with a locale in a control file | 05:25 |
| micahg | the text is grabbel from the iso-codes xml file, but somehow it gets mangled from UTF8 to ISO-8801-15 (or whatever) | 05:25 |
| micahg | *grabbed | 05:26 |
| micahg | any ideas? | 05:26 |
| breinera | is there a place where I can find out how to package a python program? I followed the instructions giving during the Ubuntu Developer Week, but it didn't cover how to include images along with python files | 05:38 |
| persia | breinera: Images meaning graphics? | 05:42 |
| breinera | yes, I have two graphics that I want to include one for the background of the application and another for decoration | 05:43 |
| persia | Well, there's two ways to do it. Are you upstream, or just packaging? | 05:43 |
| breinera | it's a personal program that I am packaging | 05:44 |
| micahg | how can I make my shell use UTF8? | 05:44 |
| persia | breinera: In that case, I'd recommend doing it in setup.py. | 05:44 |
| persia | micahg: Easiest way is to operate in a UTF8 environment. I tend to set system default. Try running `touch 日本語のファイル` | 05:45 |
| micahg | persia: I need to set it in a rules script | 05:46 |
| persia | If that works, then your UTF8 works. If not, fiddle with locale. | 05:46 |
| persia | micahg: Why? What's the build failure? | 05:46 |
| micahg | for some reason, one of the character encodings isn't behaving when I grab the info | 05:46 |
| micahg | it's using xpath to grab the locale info from the iso-codes xml | 05:47 |
| persia | Hrm. Dunno then :( | 05:47 |
| micahg | but when xpath outputs, it's garbled | 05:47 |
| micahg | I wanted to just force it in the control file to avoid environment issues if possible | 05:47 |
| micahg | persia: does this command show up right? xpath -e "//*[@iso_639_1_code=\"nb\"]/@name" /usr/share/xml/iso-codes/iso_639.xml | 05:48 |
| micahg | or rather that name | 05:48 |
| micahg | ah, I'm using the default locale | 05:50 |
| * micahg thinks his system was messed up | 05:53 | |
| breinera | persia: thanks | 06:14 |
| breinera | persia: is there a way to use a relative path inside my program, currently I have "pix = gtk.gdk.pixbuf_new_from_file_at_size ("./image/search.png", 24, 24);" but when I build the package and install it says it cannot find it, do I have to use absolute paths? | 06:29 |
| persia | Unfortunately, I don't know the syntax for setup.py at all (maybe someone else does). | 06:30 |
| persia | The other option is to do it in the packaging (with dh_install), but that's less portable to different distributions. | 06:32 |
| breinera | persia: I got setup.py working it is a matter of the python program finding the images and whether I can use relative paths or absolute paths inside my program | 06:33 |
| slytherin | breinera: What does the directory structure of installed package look like? | 06:33 |
| breinera | the python programs are inside /usr/share/pyshare/PyAffinity and the images are inside /usr/share/pyshared/PyAffinity/image and finally the executable program is inside /usr/bin | 06:34 |
| breinera | what I think is happening is when it sees "./image/search.png" it is looking where the executable file is located (/usr/bin) and not where the python files are located (/usr/share/pyshared/PyAffinity) | 06:36 |
| zooko | Whoo! Tahoe-LAFS v1.6 is released! | 06:39 |
| breinera | thanks for everyone's help, just going to use absolute paths | 06:50 |
| slytherin | Is anyone aware of any ebook reader using Debian/Ubuntu as OS? | 08:59 |
| al-maisan | Hello there! Currently working on bug #225151. | 10:25 |
| ubottu | Launchpad bug 225151 in soyuz "Please add support for .orig.tar.bz2" [High,Triaged] https://launchpad.net/bugs/225151 | 10:25 |
| al-maisan | I understand Debian source package format version 1 may not have bz2 orig tar balls | 10:25 |
| al-maisan | but version 3 may | 10:25 |
| al-maisan | is there a Debian source package format version 2? | 10:26 |
| al-maisan | If yes: may a version 2 source package contain a bz2 orig tar ball? | 10:26 |
| al-maisan | Is this documented anywhere? | 10:27 |
| geser | man dpkg-source | 10:28 |
| geser | it describes a v2 format but I have never seen it in use | 10:28 |
| al-maisan | geser: thank you very much! | 10:34 |
| directhex | v2, commonly known as "wig and pen", was never fully supported anywhere | 10:36 |
| slytherin | al-maisan: .bz2 was not supported before version 3. | 10:38 |
| randomaction | Hmm, I believe I *did* get uploads of tar.bz2 accepted: https://launchpad.net/ubuntu/lucid/+source/gpe-bluetooth/0.56-3ubuntu1 | 10:38 |
| directhex | format 1.0 supported tar.bz2, but DAK did not accept them | 10:39 |
| directhex | and having divergence between soyuz and dak in terms of package support would be ungood | 10:40 |
| slytherin | hmm, I need to read properly before I speak. | 10:40 |
| al-maisan | well, according to slangasek's comment (#7) in https://bugs.edge.launchpad.net/soyuz/+bug/225151 there are debian packages that fail to sync at present due to .orig.tar.bz2 files | 10:40 |
| ubottu | Ubuntu bug 225151 in soyuz "Please add support for .orig.tar.bz2" [High,Triaged] | 10:40 |
| randomaction | it's probably only a problem during syncs | 10:41 |
| slytherin | randomaction: We are talking about the time when source format 3 was not supported. | 10:41 |
| al-maisan | I was wondering whether the packages that slangasek referes to are version 3 packages | 10:42 |
| al-maisan | in any case this seems to be a package sync (as opposed to a package upload) issue | 10:43 |
| randomaction | al-maisan: comment #6 there probably points out the real problem | 10:44 |
| al-maisan | randomaction: ack | 10:45 |
| |xaka| | hi all! what i should do if i need cleanup pyc (compiled Python files) files after package removing? what is the better way? | 10:52 |
| feuloren | Are there packages for babl-0.1 in lucid ? | 10:56 |
| randomaction | |xaka|: doesn't python-support handle it? | 11:02 |
| |xaka| | randomaction: nope, because it's my theme package which uses KID templates. kid files automatically compiles to pyc at runtime | 11:03 |
| randomaction | |xaka|: I think you should clean up in a postrm script then | 11:04 |
| randomaction | feuloren: https://launchpad.net/ubuntu/+source/babl | 11:05 |
| feuloren | that's strange, there's nothing for 0.1 and launchpad tell me "The source babl - 0.1.2-1 is already accepted in ubuntu/lucid and you cannot upload the same version within the same distribution" when I upload to my ppa | 11:13 |
| randomaction | this means you already have this version in your PPA and can't upload it again | 11:18 |
| |xaka| | is it possible to know package name in prerm script? | 11:21 |
| |xaka| | or it should be hardcoded? | 11:22 |
| slytherin | |xaka|: Why do you need to know package name? | 11:22 |
| |xaka| | to find list of installed files, then convert names from *.kid -> *.pyc and remove *.pyc | 11:22 |
| |xaka| | because *.pyc is the garbage | 11:22 |
| slytherin | |xaka|: Can you just do 'find /package/install/path -name *.pyc|xargs rm -rf'? | 11:25 |
| |xaka| | too hardcoded way :) i want more elegant if it's possible | 11:26 |
| slytherin | |xaka|: the postrm is specific to package. So I don't see a problem with hardcoding the path | 11:27 |
| feuloren | randomaction: my ppa is empty https://launchpad.net/~florent-thevenet/+archive/florent-thevenet | 11:28 |
| randomaction | feuloren: I think you should ask in #launchpad about this | 11:29 |
| === traveller_ is now known as traveller | ||
| hakaishi | Hello everyone -^_^- I need one more advocation for qt-shutdown-p. Would anyone please look at qt-shutdown-p and perhaps advocate it? http://revu.ubuntuwire.com/p/qt-shutdown-p | 13:04 |
| hakaishi | * one more "advocate" (is what I meant...) | 13:10 |
| menesis | where can I see the NEW queue? I was told that some of my packages were uploaded, how can I verify that? | 14:06 |
| persia | launchpad.net/ubuntu/lucid/+queue | 14:06 |
| menesis | thanks | 14:11 |
| mok0 | persia, what time is the meeting today? | 14:41 |
| mok0 | Ah 15 UTC | 14:44 |
| ScottK | ~15 minutes, right? | 14:45 |
| geser | yes, hopefully the sprint folks are already awake | 14:45 |
| mok0 | 14 minutes now... | 14:46 |
| mok0 | I going over there to grab a good seat | 14:46 |
| spwelton | OK, so i managed to get my code built 'mostly' properly for REVU, but it still reports a few errors... Most of them are due to the maintainer field having my name in it.. I know I should put the MOTU in there, but what e-mail do I use, and do I need to mark the changelog as NMU, as lintian suggests? | 15:05 |
| ScottK | NMU is Debian only. So no, but it suggests some other error. | 15:07 |
| randomaction | version number should be UPSTREAMVERSION-0ubuntu1 | 15:08 |
| randomaction | Maintainer should be Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> | 15:09 |
| randomaction | XSBC-Original-Maintainer should be you | 15:09 |
| spwelton | ok, what if this is a new package? I made a launchpad bug and 'closed' it in the changelog | 15:10 |
| spwelton | so my version is 0.4, it should be 0.4~0ubuntu1 ? | 15:10 |
| randomaction | dash, not tilde | 15:11 |
| spwelton | whoops | 15:11 |
| spwelton | 0.4-0ubuntu1 | 15:11 |
| spwelton | and how do i fix this error: This package has no debian/watch file or get-orig-source rule. | 15:11 |
| spwelton | i assume i need to create debian/watch, but what goes in it? | 15:12 |
| ScottK | spwelton: See man uscan | 15:12 |
| spwelton | hrmm, i don't have a man page for that | 15:12 |
| spwelton | i'll check the web | 15:13 |
| spwelton | hahaha.... I wasn't ssh'd into my dev box... that's why i didn't have the man page | 15:14 |
| persia | spwelton: manpages.ubuntu.com can also help you find any missing ones :) | 15:14 |
| spwelton | :) I've got it now that I'm on the right computer! haha | 15:15 |
| spwelton | ok I ran uscan on my directory here, and it didn't add a watch file.. am I doing this wrong? | 15:20 |
| micahg | spwelton: https://wiki.ubuntu.com/PackagingGuide/Complete#Creating and Using a debian/watch File | 15:22 |
| spwelton | ok, and I use the ubuntu name and e-mail here, too, right? | 15:23 |
| randomaction | in watch file? no | 15:24 |
| spwelton | ok | 15:25 |
| spwelton | also, should I be using the URL from my REVU page in the watch file? I don't understand where it would get previous versions if there are no versions of this program published... | 15:26 |
| persia | spwelton: You need to construct the watch file manually. Once complete, you can use it to check or download upstream sources. | 15:26 |
| persia | spwelton: The URL in the watch file should reference the upstream release site. | 15:28 |
| spwelton | so if the only place this has ever been published is in my PPA and on REVU, where would that be? | 15:29 |
| persia | Heh. Do you have any upstream project registration, for instance on launchpad or sourceforge? | 15:31 |
| spwelton | no, I don't believe I do | 15:32 |
| spwelton | I mean, I have a PPA on launchpad, but that's it | 15:32 |
| persia | OK. You'll want to register some project on some open-source hosting site to track bugs, etc. | 15:33 |
| persia | While you may be offering it to Ubuntu, it may also be adopted by other distributions, etc. and there should be a place to coordinate upstream issues vs. issues observed in Ubuntu. | 15:34 |
| spwelton | ah ok, so I should make a page for it then... okay that would explain why something seemed to be missing | 15:34 |
| rhpot1991 | persia: ok I did some tests on that lib, the GUI does require a .so in place :( | 15:56 |
| persia | rhpot1991: nm declares a direct dependency, or the app reports a problem? | 15:57 |
| rhpot1991 | persia: the app reports a problem when you launch | 15:57 |
| rhpot1991 | nm said there was no dependency | 15:57 |
| rhpot1991 | so at this point should I do that in -dev and depend on that, or symlink in my lib package? | 15:58 |
| === neversfelde is now known as neversfelde|mobi | ||
| === neversfelde|mobi is now known as neversfelde | ||
| rhpot1991 | I can report the issue to upstream when I submit the soname patch, but I don't think its something that will get fixed before the FF | 15:58 |
| persia | rhpot1991: The app needs to be patched not to check. That's a bug. | 15:58 |
| persia | It's probably a way that upstream is trying to solve the same issues that SONAMEs are usually used to solve :) | 15:59 |
| rhpot1991 | persia: I'll try to dig in the source and see if I can find that, think we can have a fallback plan if I can't get it patched? I'd really like to get this done for lucid | 16:00 |
| persia | rhpot1991: The fallback plan would be to try to document why it's required, and get someone (who understands the side effects better than I) to review the way it's implemented to make sure it won't break stuff. | 16:01 |
| === yofel_ is now known as yofel | ||
| rhpot1991 | persia: I'm pinging someone from upstream to see if they can point me in the right direction | 16:03 |
| persia | Good luck :) | 16:04 |
| rhpot1991 | thanks, hopefully it goes betterr than asking them why there is no SONAME data :) | 16:04 |
| persia | Also, I strongly encourage you to ask questions generally. I think you ended up trying to catch me initially because I've read the library packaging guide, and written many kilobytes of interpretation in this channel, but I'm not necessarily the best person to explain or investigate the subtle corners of why the policy is as it is. | 16:05 |
| spwelton | ok, does it look like i set this page up properly? I ran bzr push lp:..... and it completed just fine, but I don't see my code on there | 16:05 |
| spwelton | https://launchpad.net/eggtimer | 16:05 |
| ScottK | spwelton: Questions for how to make a LP project work are better asked in #launchpad. | 16:05 |
| kklimonda | Is there a way to use merge-upstream when directory in the upstream tarball is missing version? | 16:06 |
| spwelton | ok | 16:06 |
| rhpot1991 | persia: well I was working with someone else behind the scenes and heard you know your libs, thats why I pinged you outright, but good point | 16:06 |
| persia | Sure, but I can't be here as many hours as I'd like :) | 16:06 |
| persia | And even when I'm around, sometimes I'm laggy or distracted. | 16:06 |
| slangasek | al-maisan: they are version 3 packages, yes | 16:07 |
| rhpot1991 | persia: for the record you've helped me out a ton here, gotten me over most of my issues | 16:07 |
| al-maisan | slangasek: OK .. jelmer is on the bug .. so it should be resolved in a few days. | 16:07 |
| slangasek | ok, great :) | 16:08 |
| persia | rhpot1991: I just feel bad because sometimes I see you looking for me, and I haven't gotten back to you for 50-100 Ksec, and I know someone else would have had a faster answer. | 16:09 |
| rhpot1991 | persia: no problem, I tend to ping and run sometimes too | 16:10 |
| rhpot1991 | pretty sure that issue is coming from this in the makefile: L../../libhdhomerun -lhdhomerun | 16:40 |
| rhpot1991 | also thats the unpatched version so it should read -L/usr/lib -lhdhomerun | 16:40 |
| * rhpot1991 double checks that | 16:40 | |
| lifeless | persia: https://bugs.edge.launchpad.net/xorg-server/+bug/516123 | 16:46 |
| ubottu | Ubuntu bug 516123 in xorg-server "xvfb does not support randr" [Undecided,New] | 16:46 |
| === Guest58331 is now known as NCommander | ||
| spwelton | OK, so i managed to get my package on REVU down to one common lintian error, anyone car to take a look? :D :D http://revu.ubuntuwire.com/p/eggtimer | 17:50 |
| persia | lifeless: Cool! Thanks. | 18:01 |
| lifeless | persia: I'm poking at glx now | 18:05 |
| persia | Excellent! | 18:06 |
| lifeless | and about to upload a xorg-server with my patch | 18:06 |
| zooko | Folks: how do I go about submitting Tahoe-LAFS v1.6 for inclusion in Lucid? | 18:12 |
| zooko | Ubuntu currently has Tahoe-LAFS v1.5. Debian doesn't have it yet. | 18:12 |
| zooko | I'm the upstream maintainer. | 18:12 |
| randomaction | zooko: open a bug, post a .diff.gz there, give a link to original tarball, subscribe ubuntu-universe-sponsors | 18:21 |
| zooko | randomaction: what is the .diff.gz? | 18:24 |
| randomaction | one of the files that constitute a source package | 18:24 |
| Laney | who maintains it in Debian? | 18:25 |
| Laney | oh, nobody | 18:26 |
| kamalmostafa | What's the name of that tool that determines whether a package name is already in use? | 18:26 |
| randomaction | apt-get? | 18:26 |
| zooko | randomaction: I mean, it is a diff between what and what? | 18:26 |
| maco | rmadison? | 18:27 |
| rmunn | So I've been working for a couple days on packaging python-nltk (http://www.nltk.org/), get on Launchpad to file a needs-packaging report, and find https://bugs.launchpad.net/ubuntu/+bug/514936 has already been filed. Looking at that package, I think mine is probably better (more work done on debian/copyright, for instance). What should I do: take over the bug report? Who should I contact besides the original reporter about this? | 18:28 |
| ubottu | Ubuntu bug 514936 in ubuntu "[needs-packaging] nltk (Natural Language Toolkit)" [Wishlist,In progress] | 18:28 |
| kamalmostafa | No, its neither apt-get nor rmadison... Given a "proposed" new package name, this tool queries multiple different open-source hosting sites, to determine whether some package already exists by that name. I used it a couple weeks ago after learning about it (here, I think) but now don't remember what it was called. | 18:29 |
| kamalmostafa | Found it... It is "Namecheck". | 18:30 |
| randomaction | zooko: technically, it is a diff between upstream distribution and packaged software; it's part of the source package along with original tarball and .dsc file | 18:30 |
| kamalmostafa | s/Namecheck/namecheck/ | 18:31 |
| zooko | randomaction: okay, got it. | 18:31 |
| zooko | So I'll copy the diff.gz that was used for Tahoe-LAFS v1.5 packaging and see if anything in it needs to be changed for v1.6. | 18:31 |
| Laney | rmunn: well, the person is actively working on it so it would be pretty off for someone to take over | 18:31 |
| Laney | maybe you could privately mail your improvements | 18:31 |
| randomaction | zooko: actually, the diff from 1.5 is kinda strange, it looks like the original tarball contains debian/ directory | 18:32 |
| randomaction | kamalmostafa: wow, namecheck is nice | 18:34 |
| kamalmostafa | randomaction: Yes, but its own name is just so... "generic"! ;-) | 18:35 |
| * randomaction runs namecheck on itself, just for the fun of it | 18:36 | |
| kamalmostafa | randomaction: Well that's just silly!: The name 'namecheck' doesn't appear to be in use. | 18:37 |
| zooko | randomaction: here's the upstream source: http://allmydata.org/trac/tahoe/browser | 18:37 |
| zooko | There is a misc/debian directory. | 18:37 |
| randomaction | What I find really strange is that the tarballs at https://launchpad.net/ubuntu/+source/tahoe-lafs/1.5.0-0ubuntu1 and http://pypi.python.org/packages/source/a/allmydata-tahoe/ are different | 18:44 |
| persia | Was there a repack? If not, that ought be sorted (even with a +reallyX upload). | 18:45 |
| randomaction | diff show deletion of binaries, addition of debian/ directory and some random changes | 18:55 |
| randomaction | s/show/shows/ | 18:55 |
| randomaction | zooko: was version 1.6 already released? | 18:56 |
| zooko | randomaction: yes! We released v1.6 last night. And it rocks! | 19:33 |
| blueyed | I've messed up a package by (apparently) "bzr merge-upstream" with a orig.tar which contained a debian directory (which was the previous one from diff.gz). How do I get this straight again? Also, how does the "upstream" branch for bzr-builddeb work. How can I switch to it? | 19:34 |
| blueyed | you can see it in lp:ubuntu/popfile | 19:41 |
| micahg | \sh: dojo is in debian and migrated to testing | 19:54 |
| arand | The reason of tor:s demise in the ubuntu repos was due to lack of a motu and or tor devs being a bit peeved by the update/security lag tor had in ubuntu repos? | 20:02 |
| ahe | could someone take a look at my package http://revu.ubuntuwire.com/p/rubyripper please? | 20:07 |
| breinera | I have a project hosted on launchpad and I just built the dsc, deb, changes, and tar.gz files, and I was wondering how I upload them to launchpad | 21:00 |
| breinera | do I need to store them in a PPA? | 21:01 |
| === emma_ is now known as emma | ||
| ChogyDan | breinera: yeah, you can upload the source to a ppa, then people can install the ppa as a repo | 21:04 |
| breinera | currently the project page says "The project does not have any download files.", how do I go about linking my ppa to this project, then? | 21:05 |
| randomaction | breinera: #launchpad is a better place for your question | 21:21 |
| breinera | oh, thanks | 21:22 |
| Odd-rationale | rmunn: I'm here too, if you need anything. :) | 22:12 |
| rmunn | Odd-rationale: Thanks | 22:12 |
| Philip5 | hi guys! what's the best way to solve it when i want to add a binary file (a .png) to a package so the diff from the original source doesn't complain? | 23:02 |
| Philip5 | i was thinking that i have seen png files turned into unicode or something but am not sure how to get it into the build in that case | 23:03 |
| Philip5 | any pointers to a howto or docs on this? | 23:03 |
| Laney | Philip5: you want uuencode and uudecode | 23:03 |
| Laney | or source format 3.0 | 23:03 |
| Philip5 | which is best? | 23:03 |
| Laney | i couldn't say | 23:03 |
| sebner | hi Laney :) | 23:04 |
| Philip5 | do i encode the file to png in debian/rules if i go by usinging uuencode/uudecode? | 23:04 |
| Laney | hiya sebner | 23:04 |
| Laney | you uuencode it in debian/ yourself | 23:06 |
| Laney | and then uudecode in rules | 23:06 |
| Philip5 | Laney: ok, thanks... i'll just read about how the thing works :) | 23:08 |
| crimsun | 49 | 23:22 |
| crimsun | bah, sorry | 23:22 |
| Philip5 | Laney: it worked like a charm! thanks again | 23:24 |
| Laney | no worries (don't forget to remove the decoded file in clean) | 23:24 |
| Philip5 | i will :) | 23:24 |
| kamalmostafa | Today james_w ran my sync request for 'libexplain'. The sync seems to have worked fine, but I received two robo-emails from Ubuntu Installer <archive@ubuntu.com> a couple minutes apart: The first message says that libexplain 0.19.D001-1 was "Accepted". The second message says "Rejected. The source libexplain - 0.19.D001-1 is already accepted in ubuntu/lucid ...". What's that all about? (Is this a motu question or a launc | 23:49 |
| james_w | hi kamalmostafa, sorry for the noise, there's nothing to worry about | 23:50 |
| kamalmostafa | james_w: okay no problem... I saw nothing... ;-) | 23:50 |
| kamalmostafa | james_w: and thanks for the sync btw. | 23:51 |
| james_w | np | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!