=== dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [01:20] hi [03:40] hello everybody [03:41] I'm using Ubuntu 12.04 beta [03:42] and last time that I ran apt-get upgrade the flash-plugin crashed. [03:49] lsmagalhaes: When was that? [03:50] today, at afternoon. [03:52] There were a number of fixes for it done yesterday. === 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 [10:45] infinity: are you aware of the dependency loop between libomxil-bellagio0 and libomxil-bellagio-bin when you fixed bug #921523? [10:45] 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:46] geser: Sure, can you show me where it causes a problem in practice? [10:46] geser: Dependency loops aren't disallowed, only discouraged (since the tools need to arbitrarily break the loop). [10:47] 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:48] ok then, I remember to avoid dependency loops when possible [10:48] And well you should. [10:48] Libraries calling stuff from lib*-bin in their postinsts are probably broken. :P [10:49] is this dependency loop safer at this moment instead of a "sync" with Debian? (merge -bin into the library) [10:49] (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:50] geser: Well, it would be safe to do that right up until someone decides to multiarch the package. [10:50] 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:51] (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:52] Given the nearly nonexistant rdep list for libomxil-bellagio0, I have a hard time seeing the above as a particularly scary problem. [10:53] but in the long run it should be fixed properly, right? (without a dep loop) [10:53] In the long run, someone needs to examine if the library really needs to be calling that binary in its postinst. [10:53] If it does, the loops is unavoidable, really. [10:53] (see: libc and libc-bin) [10:54] It's not an ideal situation, but it happens sometimes. [10:54] If they're always found together, and produced from the same source, the dep loop isn't really catastrophic. [10:56] 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:58] thanks for the explanation [10:59] Anyhow, policy doesn't forbid loops, it just strongly suggests against them because it makes resolving and unpacking somewhat difficult. [10:59] In the case of libomxil-bellagio, the loop-breaking is actually deterministic. [11:00] "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] ^-- Since the library has a postinst, but the -bin doesn't, then we get "lib/bin unpacked in arbitrary order, bin configure, lib configured". === EyesIsServer is now known as EyesIsMine [12:59] 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. [13:09] Hm, you still need the Depends for the trigger though. [13:14] 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:16] 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 [14:28] hi, I have a question regarding patches [14:29] I have the command bzr diff -r 191..190 | bzr patch [14:29] but bzr complains it does not recognize patch [14:29] anyone know how to solve this?? [14:29] I took the info from http://mhall119.com/2012/03/contributing-to-unity-for-non-developers-package-patching/ [14:33] krnekhelesh: bzr patch is a part of the bzrtools plugin [14:35] jelmer: what is the package name? [14:35] krnekhelesh: bzrtools [14:37] thnx === Quintasan_ is now known as Quintasan === krnekhelesh is now known as nik90 [14:45] I branched totem, made my changes, converted it into a patch in debian/patches folder and in the series file [14:45] after reverting back using bzr diff -r 191..190 | bzr patch, which works [14:46] I try quilt push -a [14:46] but I do not get the output [14:47] I get the output File series fully applied, ends at patch 03_default_options.patch [14:47] but then my patch name was add_keywords.patch [14:47] hwo do I fix this? [14:48] jelmer, do you know? === raju is now known as raju-away [15:12] anybody [15:12] ? [15:14] nik90: did you add your patch to the series file [15:14] ? [15:14] echo add_keywords.patch >> debian/patches/series [15:15] yes [15:15] cat debian/patches/series [15:15] when I do that I see my patch included [15:16] nik90: cat debian/source/format [15:16] 3.0 (quilt) [15:16] the same as in your blog post [15:17] huh [15:17] nik90: run "quilt applied" [15:18] mhall119, it shows 3 other patches except my patch [15:18] nik90: now try "quilt unapplied" [15:18] File series fully applied, ends at patch 03_default_options.patch [15:19] huh... [15:19] and you have add_keywords.patch in debian/patches/ ? [15:19] that's wierd, because in my debian/patches folder I see the add_keywords.patch file [15:19] yes [15:19] try "quilt series" [15:20] no output [15:20] oh, hang on... [15:21] nik90: run "echo $QUILT_PATCHES" [15:21] a blank line output [15:21] export QUILT_PATCHES=debian/patches [15:22] then try "quilt series" and "quilt unapplied" again [15:22] quit series gives the following output 00_create_m4_folder.patch [15:22] 02_lpi.patch [15:22] 03_default_options.patch [15:22] add_keywords.patch [15:23] quilt unapplied shows only my patch [15:23] ah ha, that did the trick [15:23] now quilt push -a should apply it [15:23] yup it does now :) [15:23] nik90: copy http://paste.ubuntu.com/920422/ into ~/.quiltrc [15:24] someone here gave me that, seb I think, but it works [15:25] so do I have to run export QUILT_PATCHES=debian/patches everytime i restart> [15:25] or does the new .quiltrc fix that [15:26] I think quilt will run the quilt.rc every time [15:26] quiltrc [15:27] oh good...thnx for your help [15:29] np, thanks for the contributions :) === panda is now known as Guest10423 [15:48] mhall119, https://code.launchpad.net/~nik90/ubuntu/precise/totem/add_keywords_new/+merge/101209 [15:49] if you look at diff it added .pc/ since it was from your blog post...does the diff look normal? [15:53] nik90: are there any other files in .pc? [15:54] I *think* this is okay, but I'm not 100% sure [15:54] yes there are more file in .pc [15:54] I guess other patches made by other users [15:55] but those weren't added to bzr? [15:55] no...but I guess that because I did not create or modify those files [15:55] hmmm, my feeling is that it should probably be all or none, but I'm not sure which is more correct [15:56] the other files include other patch folders which was there when I branched the latest [15:56] and it being not only a weekend, but a holiday today, there's not likely anybody around who can give a definitive answer [15:57] I have anyway proposed a merge...so will what happens tomorrow or the day after [15:57] nik90: try asking in here tomorrow, someone should be around to help then [15:57] mhall119, yeah I will do that === 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 [19:30] jdstrand: poke re bug 967195 [19:30] 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 === ejat- is now known as ejat