[13:49] <Aki-Thinkpad> Ah; there are so many ubuntu development channels; #ubuntu+1, #ubuntu-app-devel, #ubuntu+2 ... is there any that I am missing?
[13:59] <dobey> Aki-Thinkpad: are you looking for something specific?
[14:00] <Aki-Thinkpad> dobey, I just like being up to date with the development cycle, partly because I am using the platform, and plan to contribute eventually.
[14:00] <Aki-Thinkpad> (Already developing ubuntu-touch stuff)
[14:01] <Aki-Thinkpad> for me, its a really exciting platform to be involved in.
[14:01] <dobey> lurking in irc is probably not the best way to be "up to date"
[14:02] <dobey> i don't know if there's a mailing list for all the changes that get uploaded/synced to the dev release, though
[14:06] <sergiusens> dobey: Aki-Thinkpad you can subscribe to the archive uploads I guess
[14:07] <Aki-Thinkpad> sergiusens, where is that?
[14:08] <Aki-Thinkpad> dobey, very true. Still, lurking irc is easy.
[14:08] <sergiusens> Aki-Thinkpad https://lists.ubuntu.com/mailman/listinfo/trusty-changes
[14:08] <Aki-Thinkpad> sergiusens, thanks!
[14:08] <sergiusens> Aki-Thinkpad: that isn't of use now though, you'll need to wait for the archive to open up for U
[14:08] <Aki-Thinkpad> oh I forgot one; #ubuntu-on-air
[14:11] <dobey> Aki-Thinkpad: and #ubuntu-desktop #ubuntu-kernel #ubuntu-packaging #ubuntu-release #ubuntu-xorg etc etc i think (plus kubuntu, xubuntu, etc specific channels if you want those)
[14:11] <Aki-Thinkpad> dobey, thanks, I appreciate it
[14:11] <Aki-Thinkpad> !cookie
[14:12] <dobey> !rum
[14:12] <dobey> bah
[14:12] <Aki-Thinkpad> ha ha
[14:12] <Aki-Thinkpad> I lol'd.
[14:12] <dobey> 10:10 <ubottu> Sorry, I don't know anything about rum
[14:12] <dobey> yes, that's obvious
[14:12] <Aki-Thinkpad> !wine
[14:12] <Aki-Thinkpad> there you go
[14:13] <dobey> http://www.yellow5.com/pokey/archive/index160.html
[14:14] <ali__> to every body:i want to get all processes that they are running in foreground
[14:15] <Aki-Thinkpad> dobey, o_O  sort of reminds me of hackles... but more abstract
[14:18] <Aki-Thinkpad> dobey, #ubuntu-tablet + #ubuntu-tv are also there. I
[14:18] <Aki-Thinkpad> -I
[15:39] <phunyguy> hey is this the correct channel to ask some questions regarding a ppa?
[15:39] <infinity> phunyguy: The owner of the PPA is probably the better person to ask.  Or #launchpad if you're looking for help with your own PPA.
[15:40] <phunyguy> ... I am the owner....
[15:40] <phunyguy> oh ok
[15:40] <phunyguy> thanks
[17:19] <jayaura> Hello, I am a kernel noob, and was building one the trusty. but dmesg says my module is not signed, and hence tainting the kernel. Is there a way I can get the private keys for signing those modules I Make?
[17:19] <jayaura> "building one ON the trusty"
[17:21] <jayaura> Of course I mean the keys for the one I am already running 3.13.0-24-generic
[17:21] <jayaura> or is that a *private* property of ubuntu ?
[17:23] <infinity> jayaura: It's not so much that it's private, but rather that it's not known even to us.  The key used to sign modules in the archive kernel is generated and thrown away during the build.
[17:24] <jayaura> infinity, hmm so it means I have to build my own kernel with module signing turned off to get away with this problem, right? Do I have any other solution ?
[17:24] <infinity> jayaura: If you're building your own kernel, that's not a problem, as you'd just sign with your own key.  But if you're building modules for use with the archive kernel (using dkms, or by hand), then you'll pretty much have to live with them being unsigned.  This is a known issue that we need to come up with a better solution for.
[17:25] <infinity> jayaura: We don't enforce signature checking, so your module will still load.
[17:25] <infinity> jayaura: The taint listing isn't fatal, just informative.
[17:26] <jayaura> infinity, yes, I get it. Thanks for the info! ,  and for the quick response! :)
[18:03] <stokachu> barry: for private python modules using entry_points in their setup.py do you know how to make sure that private python module path exists in sys.path?
[18:04] <stokachu> barry: right now a console script file is generated automatically, should i put that generated file in /usr/share/<module> and s ymlink it to /usr/bin?
[18:06] <stokachu> ls
[18:11] <barry> stokachu: you have to hack sys.path manually in your script.  some packages do the symlink dance and others just install into /usr/bin.
[18:11] <stokachu> barry: ok cool, i think ill just place the scripts in /usr/share/<mod> and add the file to the links file in the package
[18:12] <stokachu> was just curious what 'the right way' was
[18:13] <barry> stokachu: i think this is all debian policy has to say on the matter: https://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-current_version_progs
[18:13] <barry> i.e. nothing about /usr/bin
[18:13] <stokachu> ok cool
[18:14] <stokachu> i think this way is clean enough no-one will complain ;)
[18:15] <barry> cool
[18:35]  * ScottK hears rickspencer3 screaming "lost development velocity" in the distance.
[18:36]  * rickspencer3 shakes fist
[18:57] <orbisvicis> how do I pin/prefer a virtual package in pbuilder? For example PackageA depends PackageB and PackageC provides PackageB, how do I give PackageC priority over PackageB ?
[18:58] <orbisvicis> PackageC is local, PackageB remote, I already give local packages higher priority but PackageB still has priority
[19:06] <dobey> orbisvicis: change your build-depends to have "PackageA, PackageC | PackageB" rather than just PackageA; although if the dependency is already satisfied, i don't see why apt would pull the other one in, unless something else depends specifically on PackageB, in your dep tree
[19:12] <orbisvicis> s/PackageA depends/& on/
[19:12] <orbisvicis> dobey: that works, but I was hoping I could simply pin a virtual "provided" package rather than change the build-depends
[19:13] <orbisvicis> dobey: it seems pinning ignores virtual packages, PackageB is selected simply because the name matches
[21:45] <karab44> hello
[21:46] <karab44> when this bugfix will be available for update ? https://launchpad.net/~eugenesan/+archive/ppa/+sourcepub/4095467/+listing-archive-extra
[21:46] <karab44> okay #ubuntu-bugs I undersand :)
[22:23] <orbisvicis> this pinning stuff is very fragile. Can anyone provide an example to match/pin all nonlocal (repository) apache packages ?
[22:53] <orbisvicis> as soon as I use a package name, the pin no longer works. Only * works as Package:
[22:58] <orbisvicis> the mapping is shown in apt-cache policy but the priority is not applied, in apt-cache policy <packagename>
[23:42] <orbisvicis> hm, I didn't read the policy correctly. Actually the same priority is applied to all packages matching <package name>, irrespective of "Pin:" attributes