| === Logan_ is now known as Fluffer | ||
| === Fluffer is now known as k | ||
| === k is now known as Logan_ | ||
| === Amaranthus is now known as Amaranth | ||
| dholbach | good morning | 06:57 |
|---|---|---|
| === mpounta__ is now known as mpounta | ||
| === mpounta is now known as cbountalis | ||
| AnAnt | How can I find out whether the reverse-deps of a library package need the static library or not ? | 07:20 |
| === cbountalis is now known as mpounta2 | ||
| === mpounta2 is now known as cbountalis | ||
| tumbleweed | packages shouldn't be linking to other things in the archive statically | 07:22 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| AnAnt | tumbleweed: that's what I thought, but I got asked this question on LP #1048152 | 08:14 |
| ubottu | Launchpad bug 1048152 in fribidi (Ubuntu) "Sync fribidi 0.19.4-1 (main) from Debian experimental (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/1048152 | 08:14 |
| tumbleweed | lintian knows how to detect some libraries linked statically, I doubt this one, though | 08:17 |
| tumbleweed | a simple starting point could be packages that B-D on libfribidi-dev but don't produce any binaries depending on libfribidi0 | 08:18 |
| tumbleweed | but that doesn't help with indirect B-Ds | 08:18 |
| Laney | seems like an unnecessary change given we are post-FF | 08:18 |
| tumbleweed | agreed | 08:19 |
| === almaisan-away is now known as al-maisan | ||
| AnAnt | ok, in quantal+1 then ? | 08:42 |
| Laney | sure | 08:43 |
| Laney | if the new upstream is worthwhile then you could still bring that in | 08:43 |
| === dholbach_ is now known as dholbach | ||
| AnAnt | Laney: well, it is an update to Unicode 6.1.0 | 09:11 |
| AnAnt | Laney: the previous version was for Unicode 5.1.0 | 09:11 |
| Laney | AnAnt: Sounds reasonable, if you want to get it in | 09:26 |
| Laney | just take the Debian package and revert the dropping of the static lib | 09:26 |
| Laney | then propose it for sponsorship | 09:26 |
| AnAnt | Laney: static lib was dropped by upstream | 09:34 |
| xnox | AnAnt: I don't get static libs, there are little reasons for anyone to use, and even less for a distro to ship. | 09:50 |
| xnox | even in the initramfs we have shared libraries. | 09:50 |
| === Guest8229 is now known as Zic | ||
| === dholbach changed the topic of #ubuntu-motu to: Quantal: Archive open | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://bit.ly/fz6AyQ | http://qa.ubuntuwire.com/ftbfs | http://people.canonical.com/~ubuntu-archive/NBS | http://qa.ubuntuwire.com/bugs/rcbugs | Small tasks: http://goo.gl/bSual | ||
| === Phantomas1 is now known as Phantomas | ||
| effiejayx | hey dholbach, I think I found the reason why the package would not build correct. changes in binary files, when doind bzr bd -- -S -sa. the -S stands for source only, are binaries allowed at all? | 12:33 |
| xnox | effiejayx: depends on the package format | 12:35 |
| RainCT | effiejayx: Hey. Dunno really what you're talking about, but -S is to generate (.diff.gz/.debian.tar.gz)+orig.tar.gz vs .deb, which is completely unrelated to having binary files in debian/ or in the diff | 12:35 |
| xnox | effiejayx: in 3.0 (quilt) format you can specify included-binaries if you need to. | 12:35 |
| xnox | effiejayx: that will allow "patching" binaries. the ones that you list. | 12:36 |
| xnox | effiejayx: if you use 1.0 format than you cannot patch "binaries" | 12:36 |
| cjwatson | that said: "changes in binary files" messages that you weren't expecting often actually mean that your clean target is broken. | 12:37 |
| cjwatson | that's why these are errors that you have to go to some lengths to resolve, rather than dpkg-source silently sorting it out for you. | 12:38 |
| cjwatson | because if it just silently sorted this out, we'd end up with lots of source packages that include binary junk that's part of the build process and should have been cleaned up. | 12:38 |
| effiejayx | RainCT, it is quilt 3, but once i do bzr import-upstream I guess new images for the application raise the errorhttp://pastebin.ubuntu.com/1195944/ | 12:54 |
| effiejayx | xnox, yes it is quilt 3, now if you check the warnings on new binaries, (mostly images) http://pastebin.ubuntu.com/1195944/ | 12:55 |
| RainCT | effiejayx: I'm not familiar with bzr-buildpackage, but I guess you may need to bump the version number in changelog or something | 12:56 |
| effiejayx | before when I did it with debuild -S -sa it would not stat the same | 12:56 |
| effiejayx | RainCT, I think I did that already, let me double check | 12:57 |
| effiejayx | RainCT, yep it used to be 1.6.9 now it is 1.7.6~a1 | 12:58 |
| RainCT | effiejayx: Did you merge the new upstream changes after running import-upstream? | 13:00 |
| RainCT | Anyway, I guess other people here will be able to better help you out | 13:01 |
| xnox | effiejayx: clear your build-area/*.tar* and ../*.tar.* | 13:01 |
| xnox | effiejayx: make sure the tarball you want to build against is the one you had imported into the packaging branch | 13:01 |
| effiejayx | RainCT, thanks, I think I didn't | 13:01 |
| effiejayx | xnox, ok | 13:01 |
| xnox | effiejayx: looks like something somewhere doesn't match | 13:01 |
| xnox | effiejayx: unpack the "expected" tarball and do $ diff -r -U 4 unpacked-tarball/ bzr-branch/ | 13:02 |
| xnox | to make sure bzr stored the "right" binaries. | 13:02 |
| effiejayx | ls | 13:02 |
| effiejayx | ok | 13:02 |
| effiejayx | xnox, I think I did not merge the changes | 13:06 |
| effiejayx | i did bzr import-upstream but there | 13:07 |
| xnox | effiejayx: you want $ bzr merge-upstream | 13:07 |
| xnox | import only imports the tarball and tree into a 1.1.1 dot revision | 13:08 |
| effiejayx | xnox, that did it | 13:12 |
| effiejayx | I was missing the merge-upstream bit. | 13:13 |
| effiejayx | xnox, RainCT thanks owe you a $self.precious_beverage | 13:23 |
| === Quintasan_ is now known as Quintasan | ||
| === al-maisan is now known as almaisan-away | ||
| effiejayx | xnox, now I get a checksum mismatch after doing bzr builddeb | 14:51 |
| xnox | effiejayx: clean your ../build-area/* & ../*.tar.gz | 14:52 |
| xnox | effiejayx: and you should have started with a clean branch ( the one that never saw import-upstream ) | 14:53 |
| xnox | as the pristine-tarball checksum got stored now. | 14:53 |
| effiejayx | xnox, so i do not need to do import-upstream when doing a package update? | 14:57 |
| xnox | effiejayx: no, just merge-upstream | 14:58 |
| effiejayx | ok | 14:58 |
| xnox | effiejayx: import-upstream was introduced after merge-upstream & pristine-tarball. Such that "old" branches could hook their history up with pristine-tarball deltas. In that case you do need import-upstream cause you really really do not want to merge. | 14:59 |
| xnox | effiejayx: another case of import-upstream is when you base your packaging on $upstream-bzr or $upstream-bzr-import branch | 14:59 |
| cjwatson | But basically if you don't know why you need import-upstream, you don't. | 14:59 |
| effiejayx | ok | 14:59 |
| xnox | cjwatson++ | 15:00 |
| effiejayx | thanks for the patience guys | 15:01 |
| exodus | Thanks xnox and cjwatson | 15:09 |
| exodus | That was useful for me too | 15:09 |
| exodus | I'm learning about UDD | 15:09 |
| Laney | glib2.0_2.33.12-4.dsc exists in .; copying to chroot | 15:34 |
| Laney | E: E: Failed to copy './glib2.0_2.33.12.orig.tar.xz' to '/«CHROOT»/«BUILDDIR»': No such file or directory | 15:34 |
| Laney | whatever is this | 15:34 |
| Laney | oh | 15:36 |
| * Laney failed | 15:36 | |
| === nxvl_ is now known as nxvl | ||
| radu_ | hi everyone | 17:55 |
| radu_ | I have a question. I've submitted recently a patch to one of the Ubuntu packages, but the approver mentioned that the package does not build - that it needs a proper debian/patches patch | 18:04 |
| radu_ | he already fixed this, but I'd like to know what's the proper way to deal with this. | 18:05 |
| radu_ | Using bzr builddeb -- -S -us -uc, I get the error: dpkg-source: error: aborting due to unexpected upstream changes; dpkg-source: info: you can integrate the local changes with dpkg-source --commit | 18:06 |
| radu_ | and I can build it using : bzr builddeb -- -S -us -uc --source-option=--auto-commit without getting any errors | 18:07 |
| micahg | right, but for a distro patch, it needs to go in debian/patches for a 3.0 (quilt) package | 18:08 |
| === yofel_ is now known as yofel | ||
| radu_ | um, ok, I kind of got that...but what does this mean? I just create a patch and put it in the debian/patches directory? | 18:09 |
| micahg | yeah, bzr diff -p1 with your changes uncommitted should give you a proper patch | 18:13 |
| tumbleweed | micahg: neat trick. I didn't know one could do --prefix 1 :) | 18:15 |
| micahg | yeah, otherwise it would break as a debian/patches patch unless you're using manual patching logic or dpatch | 18:16 |
| tumbleweed | I've always done --prefix old/:new/ | 18:16 |
| micahg | FWIW, I just discovered it myself :) | 18:16 |
| tumbleweed | and it's even there in the help | 18:16 |
| tumbleweed | there I was thinking it was an easter egg :P | 18:17 |
| ScottK | You can also bzr diff -c [revno] for stuff that's been committed. | 18:18 |
| micahg | right, but if someone's going for a merge proposal into the archive, having it committed isn't correct here | 18:20 |
| radu_ | hm, so what is the correct way if you are preparing a merge proposal? | 18:21 |
| micahg | radu_: committing a debian/patches patch | 18:23 |
| radu_ | a, ok :) | 18:23 |
| MohamedAlaa98 | hello MOTUs :) | 18:35 |
| MohamedAlaa98 | anybody here :/ | 18:37 |
| daniel31415 | yes | 18:37 |
| MohamedAlaa98 | hello daniel31415 | 18:38 |
| MohamedAlaa98 | :) | 18:38 |
| MohamedAlaa98 | I'm planing to join ubuntu motu | 18:38 |
| daniel31415 | i am only here because i did one bugfix in my whole life :P | 18:38 |
| MohamedAlaa98 | LOL | 18:39 |
| MohamedAlaa98 | I don't know from where I should start | 18:40 |
| MohamedAlaa98 | I've read the ubuntu packaging guide | 18:40 |
| daniel31415 | and - how is it? | 18:41 |
| MohamedAlaa98 | nice :) | 18:42 |
| MohamedAlaa98 | but Can you please give me simple operation I can do? | 18:42 |
| === GiggAz is now known as Petaz | ||
| daniel31415 | i am a total noob here | 18:42 |
| MohamedAlaa98 | ohh like me :( | 18:43 |
| Petaz | whats this channeol all about? | 18:43 |
| MohamedAlaa98 | About ubuntu MOTU | 18:43 |
| MohamedAlaa98 | :D | 18:44 |
| radu_ | MohamedAlaa98: there are a number of tasks listed here: https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative | 18:44 |
| Petaz | whats a MOTU? | 18:44 |
| micahg | !motu | 18:44 |
| ubottu | motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See http://wiki.ubuntu.com/MOTU | 18:44 |
| Petaz | great | 18:45 |
| MohamedAlaa98 | radu_: thanks | 18:45 |
| MohamedAlaa98 | radu_: is the bug fixing part of motu's work? | 18:48 |
| MohamedAlaa98 | *is bug fixing | 18:50 |
| radu_ | I don't know, I'm new around here myself. I suppose only if it's related to packaging the software (build errors, etc). Most of the bug fixing is done upstream, i assume. | 18:51 |
| MohamedAlaa98 | :/ ok radu_ thank you :) | 18:51 |
| micahg | not especially, MOTUs will integrate fixes from other places, but it's more about packaging fixes that specific bug fixes | 18:52 |
| MohamedAlaa98 | micahg: from which point should I start to become a motu? | 18:55 |
| micahg | MohamedAlaa98: start fixing stuff? | 18:56 |
| MohamedAlaa98 | micahg: yes | 18:56 |
| MohamedAlaa98 | anyway I'll search for simple bugs to fix it | 19:00 |
| MohamedAlaa98 | and Excuse me for my bad english :) | 19:01 |
| micahg | MohamedAlaa98: http://harvest.ubuntu.com/ | 19:01 |
| MohamedAlaa98 | oh, thank you :) | 19:02 |
| === gallth is now known as tgall_foo | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!