[01:20] <Sonja> hi
[03:40] <lsmagalhaes> hello everybody
[03:41] <lsmagalhaes> I'm using Ubuntu 12.04 beta
[03:42] <lsmagalhaes> and last time that I ran apt-get upgrade the flash-plugin crashed.
[03:49] <ScottK> lsmagalhaes: When was that?
[03:50] <lsmagalhaes> today, at afternoon.
[03:52] <ScottK> There were a number of fixes for it done yesterday.
[10:45] <geser> infinity: are you aware of the dependency loop between libomxil-bellagio0 and libomxil-bellagio-bin when you fixed bug #921523?
[10:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <infinity> Given the nearly nonexistant rdep list for libomxil-bellagio0, I have a hard time seeing the above as a particularly scary problem.
[10:53] <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:54] <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:56] <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:58] <geser> thanks for the explanation
[10:59] <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.
[11:00] <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".
[12:59] <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.
[13:09] <Laney> Hm, you still need the Depends for the trigger though.
[13:14] <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:16] <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
[14:28] <krnekhelesh> hi, I have a question regarding patches
[14:29] <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:33] <jelmer> krnekhelesh: bzr patch is a part of the bzrtools plugin
[14:35] <krnekhelesh> jelmer: what is the package name?
[14:35] <jelmer> krnekhelesh: bzrtools
[14:37] <krnekhelesh> thnx
[14:45] <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:46] <nik90> I try quilt push -a
[14:46] <nik90> but I do not get the output
[14:47] <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:48] <nik90> jelmer, do you know?
[15:12] <nik90> anybody
[15:12] <nik90> ?
[15:14] <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:15] <nik90> yes
[15:15] <mhall119> cat debian/patches/series
[15:15] <nik90> when I do that I see my patch included
[15:16] <mhall119> nik90: cat debian/source/format
[15:16] <nik90> 3.0 (quilt)
[15:16] <nik90> the same as in your blog post
[15:17] <mhall119> huh
[15:17] <mhall119> nik90: run "quilt applied"
[15:18] <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:19] <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:20] <nik90> no output
[15:20] <mhall119> oh, hang on...
[15:21] <mhall119> nik90: run "echo $QUILT_PATCHES"
[15:21] <nik90> a blank line output
[15:21] <mhall119> export QUILT_PATCHES=debian/patches
[15:22] <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:23] <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:24] <mhall119> someone here gave me that, seb I think, but it works
[15:25] <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:26] <mhall119> I think quilt will run the quilt.rc every time
[15:26] <mhall119> quiltrc
[15:27] <nik90> oh good...thnx for your help
[15:29] <mhall119> np, thanks for the contributions :)
[15:48] <nik90> mhall119, https://code.launchpad.net/~nik90/ubuntu/precise/totem/add_keywords_new/+merge/101209
[15:49] <nik90> if you look at diff it added .pc/ since it was from your blog post...does the diff look normal?
[15:53] <mhall119> nik90: are there any other files in .pc?
[15:54] <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:55] <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:56] <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:57] <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
[19:30] <tumbleweed> jdstrand: poke re bug 967195