| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| === dendrobates is now known as dendro-afk | ||
| Sonja | hi | 01:20 |
|---|---|---|
| lsmagalhaes | hello everybody | 03:40 |
| lsmagalhaes | I'm using Ubuntu 12.04 beta | 03:41 |
| lsmagalhaes | and last time that I ran apt-get upgrade the flash-plugin crashed. | 03:42 |
| ScottK | lsmagalhaes: When was that? | 03:49 |
| lsmagalhaes | today, at afternoon. | 03:50 |
| ScottK | There were a number of fixes for it done yesterday. | 03:52 |
| === malkauns_ is now known as malkauns | ||
| === genupulas is now known as raju-away | ||
| === raju-away is now known as raju | ||
| === raju is now known as ubucop | ||
| === Whoopie_ is now known as Whoopie | ||
| === ubucop is now known as raju | ||
| geser | infinity: are you aware of the dependency loop between libomxil-bellagio0 and libomxil-bellagio-bin when you fixed bug #921523? | 10:45 |
| ubottu | Launchpad bug 921523 in libomxil-bellagio (Ubuntu) "package libomxil-bellagio0 0.9.3-1ubuntu1 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 127" [Undecided,Fix released] https://launchpad.net/bugs/921523 | 10:45 |
| infinity | geser: Sure, can you show me where it causes a problem in practice? | 10:46 |
| infinity | geser: Dependency loops aren't disallowed, only discouraged (since the tools need to arbitrarily break the loop). | 10:46 |
| infinity | geser: It does guarantee that higher level tools feed both packages to dpkg in the same run, which give the desired result in this case. | 10:47 |
| geser | ok then, I remember to avoid dependency loops when possible | 10:48 |
| infinity | And well you should. | 10:48 |
| infinity | Libraries calling stuff from lib*-bin in their postinsts are probably broken. :P | 10:48 |
| geser | is this dependency loop safer at this moment instead of a "sync" with Debian? (merge -bin into the library) | 10:49 |
| infinity | (Though libc6 is another offender here, and the only reason it doesn't have a loop is because libc-bin incorrectly doesn't have a dep on libc) | 10:49 |
| infinity | geser: Well, it would be safe to do that right up until someone decides to multiarch the package. | 10:50 |
| infinity | geser: But there's nothing inherently unsafe about dep loops, they just make resolvers work harder and break more often. For something as leaf-ish as libomxil-bellagio, I doubt it'll cause an issue. | 10:50 |
| infinity | (Basically, a dep loop means that higher level tools MUST pass both packages to dpkg in the same run, which means if there are a bunch of rdeps, they often also end up in the same run, which hurts resolvers' brains) | 10:51 |
| infinity | Given the nearly nonexistant rdep list for libomxil-bellagio0, I have a hard time seeing the above as a particularly scary problem. | 10:52 |
| geser | but in the long run it should be fixed properly, right? (without a dep loop) | 10:53 |
| infinity | In the long run, someone needs to examine if the library really needs to be calling that binary in its postinst. | 10:53 |
| infinity | If it does, the loops is unavoidable, really. | 10:53 |
| infinity | (see: libc and libc-bin) | 10:53 |
| infinity | It's not an ideal situation, but it happens sometimes. | 10:54 |
| infinity | If they're always found together, and produced from the same source, the dep loop isn't really catastrophic. | 10:54 |
| infinity | I could artificially break the loop by making the -bin incorrectly not depend on the lib (like the libc case), but that's both silly and unnecessary. | 10:56 |
| geser | thanks for the explanation | 10:58 |
| infinity | Anyhow, policy doesn't forbid loops, it just strongly suggests against them because it makes resolving and unpacking somewhat difficult. | 10:59 |
| infinity | In the case of libomxil-bellagio, the loop-breaking is actually deterministic. | 10:59 |
| infinity | "If one of the packages in the loop has no postinst script, then the cycle will be broken at that package; this ensures that all postinst scripts are run with their dependencies properly configured if this is possible." | 11:00 |
| infinity | ^-- Since the library has a postinst, but the -bin doesn't, then we get "lib/bin unpacked in arbitrary order, bin configure, lib configured". | 11:00 |
| === EyesIsServer is now known as EyesIsMine | ||
| Laney | infinity: geser: I'm not sure it is actually necessary to call the binary on configure. From its man page: "By default, this will create a file named .omxregister under the home XDG data directory with all the components found in ${lib-dir}/libomxil-bellagio0.", yet this directory is empty in libomxil-bellagio0. | 12:59 |
| Laney | Hm, you still need the Depends for the trigger though. | 13:09 |
| nelson777br | hello, I'm having some trouble finding resources about how to integrate my application to Unity. I thought I would only create a .desktop file in /usr/share/app-install/desktop. But it's not working. I create the file and it doesn't appear in unity search. I do I make unity recognize my application ? | 13:14 |
| nelson777br | I also counldn't find any docs about this in developer.ubuntu.com. If anyone knows about some documentation about this subject I would appreciate it. Thnx | 13:16 |
| krnekhelesh | hi, I have a question regarding patches | 14:28 |
| krnekhelesh | I have the command bzr diff -r 191..190 | bzr patch | 14:29 |
| krnekhelesh | but bzr complains it does not recognize patch | 14:29 |
| krnekhelesh | anyone know how to solve this?? | 14:29 |
| krnekhelesh | I took the info from http://mhall119.com/2012/03/contributing-to-unity-for-non-developers-package-patching/ | 14:29 |
| jelmer | krnekhelesh: bzr patch is a part of the bzrtools plugin | 14:33 |
| krnekhelesh | jelmer: what is the package name? | 14:35 |
| jelmer | krnekhelesh: bzrtools | 14:35 |
| krnekhelesh | thnx | 14:37 |
| === Quintasan_ is now known as Quintasan | ||
| === krnekhelesh is now known as nik90 | ||
| nik90 | I branched totem, made my changes, converted it into a patch in debian/patches folder and in the series file | 14:45 |
| nik90 | after reverting back using bzr diff -r 191..190 | bzr patch, which works | 14:45 |
| nik90 | I try quilt push -a | 14:46 |
| nik90 | but I do not get the output | 14:46 |
| nik90 | I get the output File series fully applied, ends at patch 03_default_options.patch | 14:47 |
| nik90 | but then my patch name was add_keywords.patch | 14:47 |
| nik90 | hwo do I fix this? | 14:47 |
| nik90 | jelmer, do you know? | 14:48 |
| === raju is now known as raju-away | ||
| nik90 | anybody | 15:12 |
| nik90 | ? | 15:12 |
| mhall119 | nik90: did you add your patch to the series file | 15:14 |
| mhall119 | ? | 15:14 |
| mhall119 | echo add_keywords.patch >> debian/patches/series | 15:14 |
| nik90 | yes | 15:15 |
| mhall119 | cat debian/patches/series | 15:15 |
| nik90 | when I do that I see my patch included | 15:15 |
| mhall119 | nik90: cat debian/source/format | 15:16 |
| nik90 | 3.0 (quilt) | 15:16 |
| nik90 | the same as in your blog post | 15:16 |
| mhall119 | huh | 15:17 |
| mhall119 | nik90: run "quilt applied" | 15:17 |
| nik90 | mhall119, it shows 3 other patches except my patch | 15:18 |
| mhall119 | nik90: now try "quilt unapplied" | 15:18 |
| nik90 | File series fully applied, ends at patch 03_default_options.patch | 15:18 |
| mhall119 | huh... | 15:19 |
| mhall119 | and you have add_keywords.patch in debian/patches/ ? | 15:19 |
| nik90 | that's wierd, because in my debian/patches folder I see the add_keywords.patch file | 15:19 |
| nik90 | yes | 15:19 |
| mhall119 | try "quilt series" | 15:19 |
| nik90 | no output | 15:20 |
| mhall119 | oh, hang on... | 15:20 |
| mhall119 | nik90: run "echo $QUILT_PATCHES" | 15:21 |
| nik90 | a blank line output | 15:21 |
| mhall119 | export QUILT_PATCHES=debian/patches | 15:21 |
| mhall119 | then try "quilt series" and "quilt unapplied" again | 15:22 |
| nik90 | quit series gives the following output 00_create_m4_folder.patch | 15:22 |
| nik90 | 02_lpi.patch | 15:22 |
| nik90 | 03_default_options.patch | 15:22 |
| nik90 | add_keywords.patch | 15:22 |
| nik90 | quilt unapplied shows only my patch | 15:23 |
| mhall119 | ah ha, that did the trick | 15:23 |
| mhall119 | now quilt push -a should apply it | 15:23 |
| nik90 | yup it does now :) | 15:23 |
| mhall119 | nik90: copy http://paste.ubuntu.com/920422/ into ~/.quiltrc | 15:23 |
| mhall119 | someone here gave me that, seb I think, but it works | 15:24 |
| nik90 | so do I have to run export QUILT_PATCHES=debian/patches everytime i restart> | 15:25 |
| nik90 | or does the new .quiltrc fix that | 15:25 |
| mhall119 | I think quilt will run the quilt.rc every time | 15:26 |
| mhall119 | quiltrc | 15:26 |
| nik90 | oh good...thnx for your help | 15:27 |
| mhall119 | np, thanks for the contributions :) | 15:29 |
| === panda is now known as Guest10423 | ||
| nik90 | mhall119, https://code.launchpad.net/~nik90/ubuntu/precise/totem/add_keywords_new/+merge/101209 | 15:48 |
| nik90 | if you look at diff it added .pc/ since it was from your blog post...does the diff look normal? | 15:49 |
| mhall119 | nik90: are there any other files in .pc? | 15:53 |
| mhall119 | I *think* this is okay, but I'm not 100% sure | 15:54 |
| nik90 | yes there are more file in .pc | 15:54 |
| nik90 | I guess other patches made by other users | 15:54 |
| mhall119 | but those weren't added to bzr? | 15:55 |
| nik90 | no...but I guess that because I did not create or modify those files | 15:55 |
| mhall119 | hmmm, my feeling is that it should probably be all or none, but I'm not sure which is more correct | 15:55 |
| nik90 | the other files include other patch folders which was there when I branched the latest | 15:56 |
| mhall119 | and it being not only a weekend, but a holiday today, there's not likely anybody around who can give a definitive answer | 15:56 |
| nik90 | I have anyway proposed a merge...so will what happens tomorrow or the day after | 15:57 |
| mhall119 | nik90: try asking in here tomorrow, someone should be around to help then | 15:57 |
| nik90 | mhall119, yeah I will do that | 15:57 |
| === raju-away is now known as raju | ||
| === sharms_ is now known as sharms | ||
| === raju is now known as raju-away | ||
| === raju-away is now known as raju | ||
| tumbleweed | jdstrand: poke re bug 967195 | 19:30 |
| ubottu | Launchpad bug 967195 in ruby-rack (Ubuntu) "FFe: Sync ruby-rack 1.4.0-1 (universe) from Debian wheezy (main)" [Undecided,Incomplete] https://launchpad.net/bugs/967195 | 19:30 |
| === ejat- is now known as ejat | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!