[12:36] <shwag> what kernel does  dapper server  install by default ?
[12:37] <BenC> the -server kernel
[12:37] <shwag> what is the difference between  linux-image-686  and  linux-686-smp  ?  they both actually appear to be SMP
[12:43] <joefso23jh> with and wihtout preempt?
[12:43] <JanC> -smp is a meta-package
[12:44] <joefso23jh> I pulled 2.6.19 from git today
[12:45] <joefso23jh> and I got: http://pastebin.ca/270903
[12:45] <JanC> to make sure those who had an smp kernel in previous versions of Ubuntu didn't get stuck with an old useless kernel after an upgrade
[12:45] <joefso23jh> (while building the same config from 2.6.19 feitsy)
[12:45] <joefso23jh> s/the/with the/g
[12:47] <JanC> shwag: almost all kernels are smp-ready since dapper
[12:47] <kylem> joefso23jh, so?
[12:48] <joefso23jh> is there any fix?
[12:48] <shwag> Yah it looks like, linux-686-smp   is preemt ... while  linux-image-server   is not preemt.
[12:48] <kylem> it's in git. not uploaded.
[12:48] <joefso23jh> so it's known?
[12:48] <kylem> why don't you go get the source from feisty.
[12:48] <joefso23jh> cause packages.ubuntu doesn't seem to be uptodate
[12:49] <shwag> uhh...how do I safely remove  linux-686-smp from my system ?
[12:50] <joefso23jh> apt-get remove --purge ?
[12:52] <shwag> joefso23jh: will that put grub back properly ?
[12:59] <gnomefreak> i use synaptic its much neater for kernel removal i have found
[01:01] <qhartman> Intel has released a security advisory about a buffer overflow in their e100/e1000 nic drivers at http://support.intel.com/support/network/sb/CS-023726.htm
[01:02] <qhartman> this seems to affect Ubuntu, given the versions they mention.
[01:14] <shwag> so I installed a kernel image and now I regret it. How do I put grub back to the old kernel ?
[01:24] <shwag> common team...that should be an easy question.
 shwag: you can select a kernel for the next boot with grub-reboot (check man grub-reboot).
 shwag: reboot and select the older kernel to boot. Then remove the new kernel with 'sudo apt-get --purge remove linux-kernel-(version of the new one)'. The grub entry will be removed automagically
[01:28] <JanC> shwag: this is not a support channel...
[01:28] <shwag> my bad
[01:29] <JanC> and tehre is no kernel in the -smp package
[04:53] <BenC> Paravirtualization support (EXPERIMENTAL) (PARAVIRT) [N/y/?]  (NEW)
[04:53] <BenC> yummy
[04:58] <BenC>   10. Core 2/newer Xeon (MCORE2) (NEW)
[04:58] <BenC> hmm...wonder if it's worth it to do a Core2 kernel
[05:04] <mjg59> Doubt it
[05:25] <bronson> BenC: building with dpkg-buildpackage did indeed get rid of the -rel- like you said.
[05:26] <bronson> But now it has the identical name to Ubuntu's package.
[05:27] <bronson> Is there any easy way to insert my version in the package name?
[05:27] <bronson> Something like EXTRAVERSION = .14-ubuntu1-vs<IP_ADDRESS>
[05:28] <bronson> ...  actually, I think I know the answer.  I need to add a changelog entry?
[05:30] <bronson> Is there any way with dpkg-buildpackage to only build 386?  These 5 hour compile cycles are killing me!
[05:51] <BenC> bronson: rm configs you don't want from debian/config/i386
[05:51] <bronson> BenC: thanks.
[07:00] <Game_Ender> Is this the proper channel to discuss compiling a kernel module from upstream?
[07:01] <Game_Ender> I am looking at the Attansic L1 Ethernet driver
[07:02] <lifeless> yes, I think so
[07:04] <Game_Ender> Can someone point me the right direction of what I would do with patch set once I get it?
[07:05] <Game_Ender> The driver is being worked on as a patch for 2.6.19
[07:05] <Game_Ender> So I could remove my current kernel module (compiled from the source on my motherboard CD)
[07:06] <Game_Ender> then try to apply the patch to ubuntu kernel module
[07:06] <Game_Ender> I would then have to configure the entire kernel to build that one module correct?
[07:12] <Game_Ender> well its off to sleep
[07:12] <Game_Ender> I should probably try when its not 11PM - 1AM in the US
[07:35] <joefso>   CC [M]   ubuntu/misc/dm-bbr.o
[07:35] <joefso> ubuntu/misc/dm-bbr.c:102:59: error: macro "INIT_WORK" passed 3 arguments, but takes just 2
[07:35] <joefso> ubuntu/misc/dm-bbr.c: In function 'bbr_alloc_private':
[07:35] <joefso> ubuntu/misc/dm-bbr.c:102: error: 'INIT_WORK' undeclared (first use in this function)
[07:35] <joefso> ubuntu/misc/dm-bbr.c:102: error: (Each undeclared identifier is reported only once
[07:35] <joefso> ubuntu/misc/dm-bbr.c:102: error: for each function it appears in.)
[07:35] <joefso> make[3] : *** [ubuntu/misc/dm-bbr.o]  Error 1
[07:35] <joefso> make[2] : *** [ubuntu/misc]  Error 2
[07:35] <joefso> make[1] : *** [ubuntu]  Error 2
[07:35] <joefso> i'm trying to compiles 2.6.19 on edgy
[07:35] <joefso> using make oldconfig
[07:35] <joefso> however, it fails as we see
[09:15] <gebruiker> 2.6.19 doesn't build on edgy
[09:22] <dade`> I think it does
[09:23] <gebruiker> YOU THINK?
[09:23] <gebruiker> jeejz
[09:24] <dade`> yes I can think
[09:30] <gebruiker> ubuntu/misc/dm-bbr.c:102:59: error: macro "INIT_WORK" passed 3 arguments, but takes just 2
[09:30] <gebruiker> ubuntu/misc/dm-bbr.c: In function bbr_alloc_private:
[09:30] <gebruiker> ubuntu/misc/dm-bbr.c:102: error: INIT_WORK undeclared (first use in this function)
[09:30] <gebruiker> ubuntu/misc/dm-bbr.c:102: error: (Each undeclared identifier is reported only once
[09:30] <gebruiker> ubuntu/misc/dm-bbr.c:102: error: for each function it appears in.)
[09:31] <dade`> how  do you compile it ?
[09:32] <gebruiker> sudo make-kpkg --rootcmd fakeroot --initrd --append-to-version=-1 kernel-image kernel-headers
[09:32] <dade`> is this a git kernel ?
[09:32] <gebruiker> yes
[09:32] <dade`> ok wait
[09:32] <dade`> https://wiki.ubuntu.com/KernelCustomBuild
[09:32] <dade`> read this
[09:33] <gebruiker> yes I did?
[09:33] <dade`> no you didn'y
[09:33] <dade`> t
[09:36] <gebruiker> dude
[09:36] <gebruiker> even if the code is *not* from git
[09:37] <gebruiker> the code fails with the same error when using linux-source-2.6.19_2.6.19-7.11.tar.gz
[09:38] <dade`> well, I don't know, but compiling a git kernel with that command is wrong.
[09:39] <gebruiker> there is no guide on compiling git kernels the proper way
[09:39] <dade`> I just gave you
[09:40] <gebruiker> kernelcostumbuild?
[09:40] <gebruiker> have you read it?
[09:40] <dade`> yes
[10:37] <gebruiker> what a bunch of crap dade` even invoke just 'make' makes the build fail
[10:38] <dade`> ..
[10:39] <gebruiker> ubuntu/misc/dm-bbr.c:102:59: error: macro "INIT_WORK" passed 3 arguments, but takes just 2
[10:39] <gebruiker> ubuntu/misc/dm-bbr.c: In function bbr_alloc_private:
[10:39] <gebruiker> ubuntu/misc/dm-bbr.c:102: error: INIT_WORK undeclared (first use in this function)
[10:39] <gebruiker> ubuntu/misc/dm-bbr.c:102: error: (Each undeclared identifier is reported only once
[10:39] <gebruiker> ubuntu/misc/dm-bbr.c:102: error: for each function it appears in.)
[10:39] <gebruiker> make[2] : *** [ubuntu/misc/dm-bbr.o]  Fout 1
[10:39] <gebruiker> make[1] : *** [ubuntu/misc]  Fout 2
[10:39] <gebruiker> make: *** [ubuntu]  Fout 2
[10:52] <gebruiker> BenC broke the tree ;\
[10:54] <lifeless> gebruiker: sounds like you are building against an upstream kernel, not an ubuntu one
[10:55] <gebruiker> no
[10:55] <gebruiker> it's pulled from git
[10:55] <gebruiker> according to the kernelGitGuide
[10:55] <gebruiker> i don't thing dm-bbr.c is in vanilla
[10:55] <lifeless> its not
[10:56] <lifeless> its part of the evms patchset
[10:59] <dade`> have you tried using 'AUTOBUILD=1 fakeroot debian/rules binary-debs ...' on a clean git source ?
[11:05] <gebruiker> how does one let it build it's own config without affecting the debian tree/
[11:05] <gebruiker> ?
[11:16] <gebruiker> UTOBUILD=1 fakeroot debian/rules binary-debs flavours=386 doesnt' even work
[11:16] <gebruiker> +a
[02:58] <zul> BenC: ping
[02:59] <BenC> zul: yo
[02:59] <zul> i was thinking that the vmi (vmware stuff) can go straight into the generic kernel but the xen bits of paravirt would need its own flavour...of course i would have to test tis
[03:03] <zul> *this
[03:03] <zul> damn i need more coffee
[03:56] <zul> hey kylem
[03:57] <BenC> yay, ubuntu-2.6 is building again
[03:58] <zul> workqueues fixed?
[03:58] <BenC> workqueue, freezer, crypto API's, SLAB_* crap
[03:59] <zul> cool
[03:59] <BenC> 2.6.20 is a bigger leap than 2.6.19, which scares me
[03:59] <zul> heh ill break it again for you dont worry..:)
[03:59] <BenC> $ debian/rules printchanges | wc -l
[03:59] <BenC> 2423
[03:59] <kylem> jesus.
[03:59] <zul> ouch..
[03:59] <BenC> zul: upstream is doing a fine job of it already :)
[04:00] <dade`> now git is .20 ?
[04:00] <BenC> dade`: 2.6.20-pre
[04:01] <BenC> Keybuk: ping
[04:03] <Keybuk> BenC: yo
[04:03] <BenC> Keybuk: I think I figured out the missing bit for "the plan"
[04:04] <dade`> maybee this one will sleep WITH macbook
[04:04] <BenC> Keybuk: I was wondering how all this would work when udev didn't have a "rule" for device->driver, and we wanted binding to just work...udev had no info on this
[04:04] <dade`> (wow sexy)
[04:04] <Keybuk> go on?
[04:04] <BenC> Keybuk: So what I am going to do is make the kernel send a "match" event for when it would normally bind with a device, so that udev can send that bind to the driver
[04:05] <Keybuk> how do you mean?  over the netlink socket?
[04:05] <Keybuk> how would you know udev was on the other end?
[04:06] <BenC> if auto-bind is disabled, the kernel would send an event of some kind saying "this driver and device match, do something", and whatever is on the other end would do that thing
[04:07] <BenC> Keybuk: unless I'm missing something, in the plan you have now, if udev disables auto-bind in the kernel, there's nothing that says to actually do the binding on devices that don't have a specific driver rule
[04:09] <BenC> kylem: I don't see CVE-2006-4572 listed in your dapper changelog
[04:09] <kylem> BenC, i still haven't heard back from patrick, i pinged him again last night.
[04:09] <Keybuk> BenC: the plan was that there'd be a generic rule
[04:10] <BenC> kylem: So are we uploading dapper without 4572 fix?
[04:10] <Keybuk> make DRIVER= work like NAME=, so the first one sticks
[04:10] <Keybuk> then just do specific stuff early
[04:10] <kylem> BenC, yes, pitti wanted it uploaded because of a local root hole, iirc
[04:10] <Keybuk> and as a final rule, just have a general ENV{MODALIAS}=="?*", DRIVER="modprobe $env{MODALIAS}"
[04:10] <Keybuk> (where modprobe is the udev builtin thing)
[04:10] <zul> so breezy is ok as well since it doesnt have CVE-2006-4572 and its already been uploaded previously
[04:11] <Keybuk> BenC: the one thing I was thinking; bind and unbind override the usual device tables, yes?
[04:11] <BenC> Keybuk: Sure, that will load the driver, but I mean what will cause the bind?
[04:11] <kylem> BenC, 4572 isn't exactly what i'd call a critical hole...
[04:11] <BenC> kylem: Ok, just making sure I had everything
[04:12] <Keybuk> BenC: I was thinking we just make udev always do it
[04:12] <Keybuk> so as well as making /dev nodes, one of its other primary functions is to bind devices and drivers
[04:13] <Keybuk> so after processing a rule, if there's any DRIVER set, it binds it
[04:13] <BenC> Keybuk: but what if there's no driver set? :)
[04:13] <Keybuk> we'd set one from the alias tables?
[04:13] <Keybuk> as a default rule
[04:16] <BenC> ok
[04:45] <zul> i so much dislike rpm
[06:24] <joefso> where can I get a list of patches that are applied to ubuntu kernel tree?
[06:24] <zul> git
[06:24] <joefso> yes git can pull them in
[06:25] <joefso> howveer I want a _list_ of patches
[06:25] <joefso> that are applied to the src tree
[07:32] <BenC> joefso: Is this ubuntu-2.6?
[07:34] <bronson> Can anyone suggest a version number for my linux-vserver enabled kernel?  I'm basing it off kernel <IP_ADDRESS>-10.35 and adding vserver <IP_ADDRESS>
[07:35] <bronson> Would that be <IP_ADDRESS>.vserver<IP_ADDRESS>-10.35?
[07:36] <bronson> Or should I change something else?
[07:42] <BenC> bronson: I actually suggest just making a new flavour
[07:43] <bronson> BenC: sounds good.  How do I do that?
[07:43] <BenC> bronson: Copy debian/config/i386/*.generic to *.vserver-<IP_ADDRESS>
[07:43] <BenC> and edit was needed
[07:43] <BenC> then do : debian/rules debian/control.stub
[07:43] <bronson> Ah, OK.
[07:43] <BenC> and do the normal build
[07:44] <bronson> Would it make sense to have generic-vserver<IP_ADDRESS>, server-bigiron-vserver<IP_ADDRESS>, etc?
[07:45] <bronson> That would make sense to me, anyway.  :)  I'll try it.
[08:44] <bronson> BenC: I also need to change the files in debian/abi/2.6.17-10.34/i386 right?
[08:44] <BenC> no
[08:44] <BenC> ignore those
[08:45] <BenC> bronson: Edit debian/rules and set skipabi=true
[08:45] <bronson> ah, ok.  Will do.
[08:45] <bronson> I notice that the kernel is .34 but the abi is still .33 in the 2.6.17 git tree.
[08:47] <BenC> .33 is not the ABI
[08:47] <BenC> the ABI is 10
[08:47] <BenC> .33 and .34, those are the release revs
[08:48] <BenC> it increments everytime we do an upload...the 10 is only incremented when the ABI changes
[08:48] <bronson> I mean, the directory is named debian/abi/2.6.17-10.33
[08:49] <BenC> right, we keep the previous abi's to compare with the current build
[08:49] <bronson> cool.
[08:49] <BenC> current ABI's are only known after the build, so we can't very well keep those in the upload
[08:49] <bronson> :)  got it.
[08:49] <bronson> thanks.
[08:56] <bronson> BenC: skipabi was true because I'm using AUTOBUILD=1.
[08:56] <bronson> I think there's a missing skipabi check at line 238?
[08:57] <bronson> That exit 1 always fires regardless of the value of skipabi.
[09:04] <bronson> Yes, adding '-a "$(skipabi)" != "true"' to debian/rules line 238 appears to work.
[09:16] <joefso> Benc Yes.
[09:17] <BenC> joefso: debian/rules diffupstream > ubuntu.diff
[09:17] <joefso> BenC, however i want to apply -rt but acpi problems
[09:17] <bronson> BenC: I just thought of something.  My packages are built from a different source tree than the ubuntu kernel.  But if I only change the flavor, then my packages will claim to be built from the regular Ubuntu kernel source.
[09:18] <bronson> I need to change the package name too?
[09:18] <joefso> BenC, would it beneift community if we would package -ck kernels ontop of the -generic patched kernels?
[09:18] <BenC> joefso: No
[09:18] <joefso> or s/lowlatency/ck
[09:18] <joefso> BenC, could you eleborate a bit?
[09:18] <BenC> lowlatency is just a config option change
[09:18] <joefso> i noticed hz change
[09:18] <BenC> I'm adding any any very obtrusive patches to our tree
[09:18] <joefso> but wha'ts the reason that -ck tree wouldn't benefit community?
[09:19] <BenC> it wont benefit our users
[09:19] <BenC> 1) Creating too many kernel package options confuses users
[09:19] <bronson> joefso: what -ck feature do you want?
[09:19] <BenC> 2) Adding huge patches to our tree makes it hard to maintain
[09:20] <joefso> well 1) we already have lowlatency in feitsy 2) ck isn't that dificult to main, most of the time it applies clieanly ontop of the git tree
[09:20] <BenC> joefso: You are more than welcome to provide such kernel packages yourself though
[09:21] <BenC> joefso: You've no idea what it takes to maintain the kernel once you've added patches that modify stock kernel code
[09:21] <BenC> security, updates, changes from upstream, all these things break it
[09:21] <BenC> I just spent the past two days getting our ubuntu/* drivers to build under 2.6.20-pre git
[09:22] <BenC> that's easy because it didn't touch stock kernel code
[09:22] <joefso> well, most of the time con just takes vanilla and then inclues latest stable into his patchset. However just applying them from broken-out is not much work until now, atleast those a re my experiences. And I have used it for quite some time now. The only thing I havn't really done is benchmark them to ubuntu kernels.
[09:23] <joefso> well perhaps I should take it for testing through ubuntuforums?
[09:23] <joefso> and see where it gets me
[09:23] <joefso> and how the community reacts
[09:23] <BenC> joefso: What is in -ck that would be so beneficial?
[09:24] <joefso> mm-*prio
[09:24] <joefso> *-ionice
[09:24] <BenC> why are those patches not in mainline kernel?
[09:25] <BenC> that's not really a question, it's more of a statement
[09:25] <joefso> yes I noticed
[09:25] <BenC> they aren't in there because they aren't stable yet
[09:25] <joefso> did you ever had time to take a look at it?
[09:26] <BenC> give me a URL?
[09:26] <joefso> and I remember some time where andrew morton would put ck code into -mm
[09:26] <joefso> http://members.optusnet.com.au/ckolivas/kernel/
[09:27] <BenC> -mm isn't a stable tree by any means :)
[09:27] <BenC> eh, it already gets a big NO
[09:27] <BenC> latest is against .18, and we are doing .20pre
[09:27] <joefso> take a look at the patches dir
[09:28] <joefso> perhaps i(havn't looked yet) there are patches for .20pre in testing patches
[09:28] <BenC> even .19 is not good enough
[09:29] <joefso> and if it's worth con kolivas could even provide it, if we would just ask, or else fix up the broken diffs our selves. Form the point I have seen it all he does until now is keepon syncing code with current stable.
[09:30] <BenC> joefso: 33 changes files, and 125k diff
[09:30] <BenC> that's more than our current delta against the mainline kernel
[09:30] <BenC> by almost double
[09:30] <bronson> BenC: Instead of creating different flavors, I need to create packages with an entirely different base name?  Does that sound right or am I missing something?
[09:30] <BenC> bronson: Why?
[09:31] <bronson> Because if I only change the flavor, my package will still claim to be built from Ubuntu's source package.
[09:31] <bronson> It's not though...  I've applied the linux-vserver patch.
[09:32] <BenC> it will be linux-image-2.6.17-10-vserver package name though
[09:32] <bronson> But it still claims to be built from linux-source-2.6.17-10 right?
[09:32] <BenC> if you want that much differentiation from our source, I can't help you...way too much involved
[09:33] <bronson> Well, the source issues are solved.  It's the packaging issues that are stumping me.  :)
[09:36] <BenC> you're getting into common packaging questions that are probably best solved in #ubuntu
[09:37] <bronson> Am I?  Not many people there have dealt with control.stub...
[09:37] <bronson> Or kernel flavors.
[09:38] <BenC> but you want to change the source package
[09:38] <BenC> which actually is as simple as editing the changelog
[09:39] <bronson> Or building with -sa.
[09:42] <bronson> I guess you're right -- it's not a problem.  I must have screwed up reprepro somehow.
[09:43] <bronson> My package's source package: linux-source-2.6.17_<IP_ADDRESS>-10.34.vserver<IP_ADDRESS>.tar.gz  :)
[09:43] <bronson> I don't think there's quite enough version numbers in there...  maybe I could add grsecurity.
[10:31] <low_> hi
[10:32] <bronson> hi low
[10:43] <joefso23> hello
[10:44] <joefso23> I'm unable to use "!" when invoking dialog --yesno "tekst" 5 80
[10:44] <kylem> and?
[10:45] <joefso23> when i add a ! to the "tekst" I get: rror: Expected no more than 3 tokens for --yesno, have 5
[10:45] <kylem> how is this a kernel problem.
[10:45] <joefso23> damn wrong channel
[10:45] <joefso23> excuse me
[10:45] <kylem> ps: add a \
[10:46] <joefso23> no won't do, but anyway excuse me
[10:47] <kylem> works in zsh. ;-) try single quotes instead of double in bash.
[10:59] <bronson> BenC: When I run debian/rules debian/control.stub, a bunch of packages get "-ref" added to their names.
[10:59] <bronson> Is there an easy way to make -ref not appear?
[11:00] <BenC> bronson: no
[11:00] <bronson> So just live with it?  :)
[11:00] <bronson> OK.
[11:00] <BenC> you're trying to do stuff that the build system there wasn't designed to do
[11:00] <BenC> you're sort of on your own :)
[11:01] <bronson> True.  I can live with that.  Hope you don't mind if I ask you easy questions though.
[11:07] <BenC> joefso23: I wrote this up real quick, since your question about including patches comes up quite often
[11:07] <BenC> joefso23: It explains things in more detail
[11:07] <BenC> https://wiki.ubuntu.com/KernelPatches
[11:09] <bronson> BenC, can you tell me briefly where -ref comes from?
[11:09] <BenC> what do you mean by -ref?
[11:09] <bronson> linux-headers-2.6.17-10-ref
[11:09] <BenC> I don't know what -ref is
[11:09] <bronson> (from the debian/control file)
[11:10] <BenC> is that what it actually says?
[11:10] <bronson> Yes, it showed up when I ran debian/rules debian/control.stub.
[11:10] <bronson> I'll dig deeper.
[11:10] <BenC> if you actually see "-ref" then you likely buggered something to make it do that
[11:10] <BenC> head -1 debian/changelog
[11:10] <BenC> let me see that
[11:11] <bronson> The full line is "Package: linux-headers-2.6.17-10-ref"
[11:11] <bronson> not all names have -ref, just some.
[11:11] <bronson> here you go: linux-source-2.6.17 (<IP_ADDRESS>-10.34.vserver<IP_ADDRESS>) edgy; urgency=low
[11:14] <bronson> No, it didn't show up when I ran debian/rules debian/control.stub .  That went OK.
[11:15] <bronson> I'll dig into this further before asking more.  And start with a fresh git tree.
[11:17] <BenC> that's the problem
[11:17] <BenC> do not add the .vserver<IP_ADDRESS> in the versioning
[11:19] <bronson> Ah, good.
[11:19] <bronson> Is there a place I can maintain a rev number?  I don't expect to get this package right the first time.  :)
[11:20] <bronson> Or do I just need to bump the .34 to .35 and diverge from your upstream package?
[11:21] <BenC> that's the idea
[11:21] <bronson> OK, will do.
[11:21] <bronson> Thanks.
[12:10] <cassidy> guys, i'll pay you a beer at next FOSDEM or GUADEC if you package the fix for this bug ASAP https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/63418  :)
[12:11] <cassidy> i just received my new laptop and it's very frustrating to not be able to use it ;)
[12:16] <BenC> cassidy: is this the ipw3945 softlockup when rfkill is on?


[01:33] <leftist> evening. does compiz run in studio?
[02:09] <studio-user153> Good Night
[02:10] <OvenWerks> leftist: Studio uses xfce
[02:11] <OvenWerks> the guys in xubuntu probably have a better answer.
[02:12] <OvenWerks> leftist: Studio is (right now) based on xubuntu with system tweaks and kernel to allow better lowlatency work
[02:12] <leftist> yes i use it
[02:13] <leftist> works fabulously
[02:13] <leftist> i'm still a compiz head from the old days but i'll just use compiz on another laptop and just keep studio native since it works right
[02:14] <leftist> yeah  i will just keep it native
[02:14] <leftist> thanks video toaster opps oven guy ;D
[02:14] <leftist> oven werks :D
[02:16] <OvenWerks> :)
[07:39] <arc_love> hello
[14:09] <SoundPro69> Hi there, good morning / afternoon to everyone. I am trying to install the dvdae_7.2.0_amd64.deb package (downloaded from http://www.dvdae.com/dvdae/dvdae_7.2.0_amd64.deb) which is for DVDAudioExtractor and it is failing the Lintian test as "bad quality", mostly due to wrong-file-ownwer uids and bad permissions. Any clues please?
[14:10] <SoundPro69> I am on a DELL Latitude E6230 laptop running i5 with 8GB or ram on Ubuntu Studio 15.10
[19:45] <antonionegrao> ok
[23:12] <SoundPro69> Hi there, good morning / afternoon to everyone. I am trying to install the dvdae_7.2.0_amd64.deb package (downloaded from http://www.dvdae.com/dvdae/dvdae_7.2.0_amd64.deb) which is for DVDAudioExtractor and it is failing the Lintian test as "bad quality", mostly due to wrong-file-ownwer uids and bad permissions. Any clues please?
[23:12] <SoundPro69> I am on a DELL Latitude E6230 laptop running i5 with 8GB or ram on Ubuntu Studio 15.10
[23:25] <SoundPro69> Anyone there who can give me clue?
[23:26] <SoundPro69> What does failing the Lintian test as "bad quality", mostly due to wrong-file-ownwer uids and bad permissions mean? Should I install anyway?
[23:35] <SoundPro69> No one there apparently...
[23:44] <zequence> SoundPro69: Lintian test measures a package accoring to https://www.debian.org/doc/debian-policy/
[23:45] <zequence> Yes, we are all here, but not active all the time :)
[23:45] <SoundPro69> So, how dangerous is it to install anyway if the issues are as per above?
[23:45] <zequence> That is mostly a question of how much you trust the packager
[23:46] <SoundPro69> I noticed more than one downloaded .deb package gives me the warning.
[23:46] <SoundPro69> I guess it's pretty strict
[23:46] <zequence> The Debian policy tries to make sure the package is ok, but just because a package breaks against the policy in some way doesn't mean it automatically is bad
[23:47] <SoundPro69> I see.
[23:47] <zequence> The Debian policy takes into account the infrastructure of the whole system
[23:47] <zequence> A single package may not be so broadminded
[23:48] <zequence> If you really want to know in which way it is bad, you need to learn in which way it breaks agains the policy
[23:49] <zequence> The error message should give you a clue
[23:49] <SoundPro69> Yes. It says due to wrong-file-ownwer uids and bad permissions
[23:51] <zequence> uid stand for "user id". Not sure why the files in the binary package has the wrong uid's. Usually root (i.e. uid == 0) owns those files
[23:52] <zequence> I'm not an expert in the policy in any way
[23:52] <zequence> Bad permissions I don't know how to interpret, but perhaps that is related
[23:53] <zequence> If you want to see what happened after installation, chech which files were installed with the command: dpkg -L <package>
[23:55] <zequence> In any case, if it is a binary package, you never know what you get, unless you study the code. If there's no source code, it's pretty hard to tell.
[23:56] <zequence> SoundPro69: This sort of stuff is not specific to Ubuntu Studio, so if you would like more eyes on the problem I would use more generic channels, such as #ubuntu, or the like
[23:56] <SoundPro69> Is it easy to remove a deb if it complicates things in my system or could it leave bad dependencies on?
[23:56] <zequence> You are always welcome here too, of course :)
[23:57] <zequence> A .deb file in itself does not add any non-system dependencies
[23:57] <zequence> So, in that sense, it is pretty safe
[23:57] <SoundPro69> You're the man! Thank you so much for all your help! Happy new year!
[23:57] <zequence> SoundPro69: To you as well!
[23:57] <SoundPro69> :-)


[00:01] <michaelh1> Hi there.  libatomic-ops-dev needs a one line source code fix to compile on later ARM versions.  I'm new to this - could someone point me at the documentation on how to do this and submit it? (http://www.debian.org/doc/maint-guide/ch-build.en.html assumes a quilt patchset)
[00:17] <geser> michaelh1: https://wiki.ubuntu.com/SponsorshipProcess https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff that should hopefully help you for the start
[00:28] <achiang> is there a way to get dpkg to just download the .deb of a package?
[00:28] <ebroder> achiang: aptitude has an aptitude download
[00:28] <achiang> ebroder: ah, thank you. i'll go read the man page
[00:28] <ebroder> I think I heard mvo say he added an apt-get download recently (i.e. natty only)
[00:30] <achiang> ebroder: aptitude download works.... almost. now i want to get a different arch. :)
[00:31] <achiang> ah, append=
[02:03] <c2tarun> i was using "sudo pbuilder build <name>.dsc" to build a package, pbuilder found some packages and start downloadiing them. can anyone please tell where can i see the log of this activity???
[02:50] <c2tarun> i got this error while i was practicing packaging from a tutorial. http://paste.ubuntu.com/535431/ please help :(
[02:53] <ajmitch> c2tarun: that looks like quite an old version of brasero you're working with
[02:53] <c2tarun> i was working on a tutorial on this page    https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate
[02:54] <ajmitch> I suspect that needs to be updated to use a newer package. I think that version of brasero needs some patches to work on a recent system :)
[02:55] <c2tarun> ok, sorry sir i m not familiar with patching stuff now. infact brasero was my first package. any suggestions for me??
[02:56]  * ajmitch is just trying to think of a fairly simple package that wouldn't be too problematic
[02:56] <c2tarun> ok thank you sir :) i'll go for small and easy packages.
[02:57] <ajmitch> yeah, there should be a few that you could practice on :)
[03:10] <abuDawud> if a packaging assignment has been assigned to someone for a year and I want to work on it, is it okay for me to unassign it from them?
[03:11] <ajmitch> I'd generally comment on the bug first & see if there's any response after a few days, though you can probably get started on doing the packaging work
[03:11] <RAOF> abuDawud: I'd try pinging them first, in case there's a reason why it's been hanging around for a year.
[03:13] <ajmitch> also, check that it's not already in ubuntu, debian or on revu
[07:56] <dholbach> good morning!
[08:01] <quadrispro> hi dholbach !
[08:03] <dholbach> hey quadrispro
[11:01] <quadrispro> hi all
[12:09] <andol> I have a question regarding the instructions on https://wiki.ubuntu.com/PbuilderHowto. Wouldn't I also want to have something like this in my configuration, to build against the latest packages? OTHERMIRROR="deb http://se.archive.ubuntu.com/ubuntu/ $DIST-updates main restricted universe multiverse"
[12:09] <andol> (Actually I do suspsect there might be a good reason for only building against the base packages, I just don't know what it is.)
[12:11] <Rhonda> In some cases it's needed to build against updates, but in general it's preferred to not do so.
[12:11] <soren> Rhonda: Why?
[12:11]  * soren always builds with -updates and -security enabled.
[12:12] <ari-tczew> BlackZ: how do you feel after meeting? are you discouraged to contribute? do you will continue strengthen main?
[12:13] <Rhonda> soren: To have least surprises. "Why not?"
[12:17] <BlackZ> ari-tczew: 1. it's ok; 2. no; 3. certainly. Why do you ask?
[12:20] <ari-tczew> BlackZ: I'm watching on contributors behaving and motivation.
[12:22] <soren> Rhonda: Because it's what the buildd's would do.
[12:22] <soren> Rhonda: ...and it's what my own box would do outside of a pbuilder.
[12:23] <Rhonda> soren: The buildds would do? Didn't check their configuration, with same priority, i.e. always pulling in updates, no matter if build-depends are sufficient in the regular release?
[12:23] <soren> Rhonda: Sure.
[12:24] <Rhonda> Actually that's not so "sure" to me
[12:24] <Rhonda> Otherwise I wouldn't ask or be astonished. :)
[12:25] <soren> Rhonda: -proposed builds against -updates and -security.
[12:26] <soren> If we don't even trust -updates ourselves, how could we expect our users to? :)
[12:47] <ari-tczew> how can I avoid to creating files in quilt3 'debian-changes'XXX' ?
[12:47] <kklimonda> ari-tczew: make sure that there are no inline changes to the source.
[12:48] <ari-tczew> kklimonda: there are not... it's related to handle debian/patches
[12:49] <BlackZ> ari-tczew: are you introducing a new patch or is it an existing one?
[12:49] <ari-tczew> BlackZ: I removed deprecated patch and add refreshed
[12:50] <BlackZ> ari-tczew: then pick up the reapplied changes from there and add them to the "deprecated patch". Be sure to run 'pop quilt -a' then remove the generated patch during the build
[12:51] <ari-tczew> BlackZ: example: bug 676303
[12:53] <BlackZ> ari-tczew: usually if upstream introduced minor changes in the files to be patched it should not be a problem to refresh the related patch(es)
[12:55] <BlackZ> ari-tczew: ah sorry, I mean "quilt pop -a" and not "pop quilt -a" :)
[12:58] <Rhonda> BlackZ: rather quilt pop, not pop quilt ;)
[12:58] <Rhonda> oh, you corrected already
[12:58] <BlackZ> Rhonda: :)
[13:00] <ari-tczew> lol
[13:56] <om26er> i am backporting a fix to a debian synced package and debuild does not work unless 'Maintainer' has a @ubuntu email. what should i do?
[13:57] <hrw> om26er: strange - my ubuntu packages have non ubuntu email
[13:57] <tumbleweed> om26er: run update-maintainer
[13:57] <dholbach> (from ubuntu-dev-tools)
[13:57] <dholbach> https://wiki.ubuntu.com/DebianMaintainerField has the reason for it
[14:00] <om26er> tumbleweed, thanks worked
[14:01] <hrw> new-dev-process question: are persons who want to endorse me on a wiki page needs themself to be ubuntu developers?
[14:03] <ScottK> hrw: It's not strictly required, but endoresements from developers are weighed more heavily.
[14:03] <hrw> ok thx
[14:03] <hrw> ScottK: and I understand why
[14:05] <gaurava> hey all ... i am trying to set up a serial console in ubuntu 10.10 for debugging purpose but no luck till this time
[14:06] <siretart> quadrispro: congrats to core-dev membership!
[14:07] <quadrispro> siretart, thank you very much :)
[14:07] <hrw> gaurava: you want to have serial console access to machine or to connect from your machine to serial console?
[14:07] <gaurava> i want to have serial console access to the machine ..
[14:08] <hrw> gaurava: ok
[14:08] <gaurava> actually i am following this article https://help.ubuntu.com/community/SerialConsoleHowto
[14:08] <gaurava> i did all the steps as mentioned in it .. but still not getting any output on my serial console
[14:08] <hrw> gaurava: cd /etc/init/ cp tty1.conf ttyS0.conf?
[14:09] <siretart> hrw: that's not enough
[14:09] <siretart> "sed s,tty1,ttyS0, /etc/init/tty1.conf > /etc/init/ttyS0.conf" should do it
[14:09] <gaurava> currently my ttyS0 contains the following content:
[14:09] <gaurava> start on stopped rc RUNLEVEL=[2345]
[14:09] <gaurava> stop on runlevel [!2345]
[14:09] <gaurava> respawn
[14:09] <gaurava> exec /sbin/getty -L 115200 ttyS0 vt102
[14:11] <gaurava> do i still need to do the changes as suggested by sietart ??
[14:11] <ari-tczew> gaurava: you can press [TAB] for autocomplete nicks
[14:14] <zul> soren: just updated the workitems for the openstack-integration spec fyi
[14:14] <soren> zul: url?
[14:14]  * soren likes things he can click on
[14:14] <zul> soren: one sec
[14:14] <zul> https://blueprints.launchpad.net/ubuntu/+spec/cloud-server-n-openstack-integration
[14:15] <gaurava> ari-tczewsorry i didn't get it
[14:28] <soren> zul: What are "zone files"?
[14:29] <zul> soren: memory and disk sizes...ill change that in the spec
[14:29] <soren> zul: eh?
[14:29] <achiang> mdeslaur: hi, thank you for uploading pbuilder for me; i see that it experienced a FTBFS, but looking at the build log, it looks... unrelated to my change
[14:30] <zul> soren: ie how much memory  you allocate for m1.small
[14:30] <soren> How is that a "zone"?
[14:31] <mdeslaur> achiang: oh?
[14:31]  * mdeslaur looks
[14:31] <mdeslaur> achiang: ugh :)
[14:31] <zul> soren: its not ill update the spec
[14:31] <achiang> mdeslaur: does that build log make any sense to you?
[14:32] <soren> zul: Yay.
[14:32] <mdeslaur> achiang: not yet, but i'm looking into it now
[14:33] <achiang> mdeslaur: i wonder if it's just natty toolchain issues, and not related to the uploaded debdiff at all. has pbuilder been built in natty yet anyway?
[14:34] <mdeslaur> achiang: it had (and it did locally for me with my outdated schroot)
[14:35] <mdeslaur> achiang: but I updated my schroot and it's not building locally anymore
[14:37] <achiang> mdeslaur: a quick scan of pbuilder.8 doesn't show any obviously illegal characters in vim
[14:37] <mdeslaur> achiang: yeah, and doing "LANG=C MANWIDTH=80 man --warnings -E UTF-8 -l pbuilder.8 >/dev/null" in a natty schroot works...
[14:55] <geser> I can reproduce this in my natty pbuilder (but not in my natty chroot)
[14:55] <geser> achiang: I've tested rebuilding 0.199ubuntu1 which fails too
[14:56] <achiang> geser: well, it's a small comfort to know that i didn't directly cause this issue. :-/ thanks
[15:36] <akoskm> hi! if some package is available in the updates/universe repo, how can I enable that repo in pbuilder?
[15:42] <quadrispro> akoskm, by setting COMPONENTS properly in your pbuilderrc file (see man 5 pbuilderrc)
[15:45] <akoskm> quadrispro, thank you
[15:45] <quadrispro> you're welcome
[15:52] <hyperair> quadrispro: i hear you're a core dev now. congrats! =)
[15:53] <quadrispro> thanks hyperair !
[15:53] <hyperair> =)
[17:05] <mdeslaur> achiang: pbuilder is fixed. not your fault :)
[17:09] <achiang> mdeslaur: thank you. i did read some of the scrollback in #ubuntu-devel and saw that a) it was related to locales and b) you were doing a fine job of handling it, so decided to let you keep going. :)
[17:10] <mdeslaur> achiang: by "doing a fine job", you mean "panicking", right? :P
[17:11] <achiang> mdeslaur: i note that the word 'euphemism' is composed of two greek words, 'eu', meaning 'good or beautiful' and 'phemism' meaning 'possible interpretation of random irc text'.
[17:11] <achiang> ;)
[17:12] <mdeslaur> hehehe
[17:25] <achiang> can someone help me recover from a bad natty dist-upgrade? it looks like xulrunner's postinst is hanging indefinitely. i killed the apt-get. my next thought was to purge xulrunner from my system since i use chrome, not firefox, but attempting to purge it seems to cause apt to want to reconfigure it or something...
[17:27] <persia> achiang, maintainer scripts live in /var/lib/dpkg/info/... and can be edited by root.  If you make them completable, you can complete the dpkg operations.  Fixing the system afterwards is an exercise for the user :)
[17:31] <achiang> persia: good hint. i'm a developer, i should be able to fix broken stuff, right? ;)
[17:31] <\sh> achiang: that depends ;)
[17:32] <achiang> persia: is there a way to make apt a little more chatty? can i just stick a 'set -x' at the top of all the xulrunner maintainer scripts and try to see what's going on?
[17:32] <\sh> achiang: you can set -x to the maintainer script in the directory persia mentioned before and start it manually if you want
[17:32] <Sarvatt> achiang: fixed xulrunner-1.9.2 was uploaded already, hopefully it wont be too much longer :)
[17:32] <Sarvatt> achiang: https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/663294 is the problem
[17:33] <achiang> Sarvatt: ah, thank you for the fish. i am now requesting a fishing lesson. :)
[17:34] <achiang> \sh: ok, right, that makes sense. i was just wondering if there was a more generic way to do it, but that's fine too
[17:35]  * persia usually modifies the stubborn maintainer script and then calls it with `dpkg --configure -a`
[18:23] <ari-tczew> cjwatson: is it true, that do you planning sponsor bug 662276? if not, I'll subscribe ubuntu-sponsors
[18:25] <ari-tczew> BlackZ: I found the merge bug, which could interest you ;) bug 507778
[18:28] <micahg> version is out of date
[18:33] <ari-tczew> micahg: ?
[18:34] <micahcowan> ari-tczew, perhaps he means that the current Debian testing version is 1:2.0.6-1
[18:34] <micahg> yep
[18:35] <ari-tczew> micahg: and?
[18:35] <ari-tczew> do you know, that launchpad has got option like edit bug?
[18:35] <geser> ari-tczew: as far as I know cjwatson will sponsor it (once it reached the top of his queue)
[19:58] <blueyed> I have backported a PHP snapshot, based on the ubuntu package, but the build fails (without any clear error): http://launchpadlibrarian.net/59509213/buildlog_ubuntu-lucid-i386.php5_5.3.4%7Esnap201011231530-0ubuntu1%7Eblueyedppa1_FAILEDTOBUILD.txt.gz - "dpkg-buildpackage: error: debian/rules build gave error exit status 2", but no real reason apparently. Hints?
[20:01] <micahcowan> blueyed, Not "no reason". Search above that point to find the errors that resulted in the final error returned by "debian/rules build".
[20:01] <micahcowan> build -> build-pear-stamp -> install-pear, apparently.
[20:02] <micahcowan> At which point it appears that some rule was running wget to download a file from pear.php.net (as part of the build process?!), but wget couldn't resolve the pear.php.net hostname
[20:03] <micahcowan> Haven't done launchpad builds myself, and don't know much about them, but I wouldn't be surprised if normal external net access were disallowed for security reasons or somesuch.
[20:03] <blueyed> micahcowan: thanks, missed that and yes, that makes sense. I am not sure if the regular buildds allow network access?! will have to look into this later.
[20:07] <geser> blueyed, micahcowan: the buildds don't have net access
[20:21] <Sarvatt> achiang: fixed xulrunner-1.9.2 is out now
[20:22] <achiang> Sarvatt: ta!
[20:26] <achiang> Sarvatt: much better, thank you
[20:27] <Sarvatt> achiang: thank chrisccoulson, he found the problem fast when I bugged him about it :)
[20:29] <achiang> Sarvatt: yes, i peeked at the bug and it looked hairy, having to read the disassembly to figure out the answer. /me thanks chrisccoulson


[08:30] <leonel> hello :  are there any plans for Ubuntu  with   icedtea ?  http://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00067.html
[08:52] <man-di> leonel: we are working on it
[09:26] <jamesstansell> are the plans being tracked anywhere, for upcoming changes of java on ubuntu?
[09:28] <man-di> we are doing them in Debian and then file sync/merge bugs
[09:29] <man-di> there is not much more tracking then in Debian BTS
[10:12] <leonel> man-di: no ubuntu specific ..  ok  thank you
[10:14] <man-di> leonel: no, why should it?
[10:17] <leonel> never mind


[02:52] -queuebot:#ubuntu-quality- Builds: Ubuntu GNOME Desktop amd64 [Trusty 14.04.5] has been marked as ready
[02:52] -queuebot:#ubuntu-quality- Builds: Ubuntu GNOME Desktop i386 [Trusty 14.04.5] has been marked as ready
[08:47] <vigo> Hi!
[08:47] <vigo> someone to lend a hand with iso testing?
[08:48] <tsimonq2> vigo: sure, what do you need help with? :)
[08:50] <vigo> I was testing lvm+encryption but once the kvm rebooted gt stuck on splash screen
[08:50] <vigo> ubuntu and dots, due to encryption should take a little longer?
[08:51] <tsimonq2> vigo: try pressing the Esc key to see the boot process
[08:52] <vigo> ok
[08:52] <vigo> thanks!
[08:52] <vigo> =)
[09:07] -queuebot:#ubuntu-quality- Builds: Ubuntu Kylin Desktop amd64 [Trusty 14.04.5] has been updated (20160803)
[13:41] <davmor2> vigo: type in your password for the encryption it sometimes disappears on kvm due to the crappy gfx
[13:44] <vigo> thanks!
[13:52] -queuebot:#ubuntu-quality- Builds: Netboot amd64 [Trusty 14.04.5] (20101020ubuntu318.40) has been added
[13:52] -queuebot:#ubuntu-quality- Builds: Netboot armhf [Trusty 14.04.5] (20101020ubuntu318.40) has been added
[13:53] -queuebot:#ubuntu-quality- Builds: Netboot powerpc [Trusty 14.04.5] (20101020ubuntu318.40) has been added
[13:53] -queuebot:#ubuntu-quality- Builds: Netboot arm64 [Trusty 14.04.5] (20101020ubuntu318.40) has been added
[13:53] -queuebot:#ubuntu-quality- Builds: Netboot ppc64el [Trusty 14.04.5] (20101020ubuntu318.40) has been added
[13:53] -queuebot:#ubuntu-quality- Builds: Netboot i386 [Trusty 14.04.5] (20101020ubuntu318.40) has been added
[15:33] -queuebot:#ubuntu-quality- Builds: Ubuntu Base amd64 [Trusty 14.04.5] has been updated (20160803)
[15:33] -queuebot:#ubuntu-quality- Builds: Ubuntu Base armhf [Trusty 14.04.5] has been updated (20160803)
[15:33] -queuebot:#ubuntu-quality- Builds: Ubuntu Base powerpc [Trusty 14.04.5] has been updated (20160803)
[15:33] -queuebot:#ubuntu-quality- Builds: Ubuntu Base arm64 [Trusty 14.04.5] has been updated (20160803)
[15:33] -queuebot:#ubuntu-quality- Builds: Ubuntu Base ppc64el [Trusty 14.04.5] has been updated (20160803)
[15:33] -queuebot:#ubuntu-quality- Builds: Ubuntu Base i386 [Trusty 14.04.5] has been updated (20160803)
[15:53] -queuebot:#ubuntu-quality- Builds: Ubuntu Server amd64+mac [Trusty 14.04.5] has been updated (20160803)
[15:53] -queuebot:#ubuntu-quality- Builds: Ubuntu Server amd64 [Trusty 14.04.5] has been updated (20160803)
[15:54] -queuebot:#ubuntu-quality- Builds: Ubuntu Server i386 [Trusty 14.04.5] has been updated (20160803)
[15:54] -queuebot:#ubuntu-quality- Builds: Ubuntu Server ppc64el [Trusty 14.04.5] has been updated (20160803)
[15:54] -queuebot:#ubuntu-quality- Builds: Ubuntu Server powerpc [Trusty 14.04.5] has been updated (20160803)
[16:00] -queuebot:#ubuntu-quality- Builds: Ubuntu GNOME Desktop amd64 [Trusty 14.04.5] has been updated (20160803)
[16:00] -queuebot:#ubuntu-quality- Builds: Ubuntu GNOME Desktop i386 [Trusty 14.04.5] has been updated (20160803)
[16:01] -queuebot:#ubuntu-quality- Builds: Mythbuntu Desktop amd64 [Trusty 14.04.5] has been updated (20160803)
[16:01] -queuebot:#ubuntu-quality- Builds: Mythbuntu Desktop i386 [Trusty 14.04.5] has been updated (20160803)
[16:07] -queuebot:#ubuntu-quality- Builds: Ubuntu Kylin Desktop amd64 [Trusty 14.04.5] has been updated (20160803.1)
[16:07] -queuebot:#ubuntu-quality- Builds: Ubuntu Kylin Desktop i386 [Trusty 14.04.5] has been updated (20160803.1)
[16:09] -queuebot:#ubuntu-quality- Builds: Xubuntu Desktop amd64 [Trusty 14.04.5] has been updated (20160803)
[16:09] -queuebot:#ubuntu-quality- Builds: Xubuntu Desktop i386 [Trusty 14.04.5] has been updated (20160803)
[16:24] -queuebot:#ubuntu-quality- Builds: Lubuntu Desktop amd64 [Trusty 14.04.5] has been updated (20160803)
[16:24] -queuebot:#ubuntu-quality- Builds: Lubuntu Desktop powerpc [Trusty 14.04.5] has been updated (20160803)
[16:24] -queuebot:#ubuntu-quality- Builds: Lubuntu Desktop i386 [Trusty 14.04.5] has been updated (20160803)
[16:35] -queuebot:#ubuntu-quality- Builds: Kubuntu Desktop i386 [Trusty 14.04.5] has been updated (20160803)
[16:35] -queuebot:#ubuntu-quality- Builds: Kubuntu Desktop amd64 [Trusty 14.04.5] has been updated (20160803)
[17:55] -queuebot:#ubuntu-quality- Builds: Ubuntu Desktop amd64+mac [Trusty 14.04.5] has been updated (20160803)
[17:55] -queuebot:#ubuntu-quality- Builds: Ubuntu Desktop i386 [Trusty 14.04.5] has been updated (20160803)
[17:55] -queuebot:#ubuntu-quality- Builds: Ubuntu Desktop amd64 [Trusty 14.04.5] has been updated (20160803)
[19:10] -queuebot:#ubuntu-quality- Builds: Edubuntu DVD i386 [Trusty 14.04.5] has been updated (20160802)
[19:10] -queuebot:#ubuntu-quality- Builds: Edubuntu DVD amd64 [Trusty 14.04.5] has been updated (20160802)
[19:15] -queuebot:#ubuntu-quality- Builds: Ubuntu Studio DVD i386 [Trusty 14.04.5] has been updated (20160803)
[21:30] -queuebot:#ubuntu-quality- Builds: Ubuntu GNOME Desktop amd64 [Trusty 14.04.5] has been marked as ready
[21:30] -queuebot:#ubuntu-quality- Builds: Ubuntu GNOME Desktop i386 [Trusty 14.04.5] has been marked as ready
[22:01] -queuebot:#ubuntu-quality- Builds: Ubuntu Studio DVD amd64 [Trusty 14.04.5] has been updated (20160803.1)
[22:01] -queuebot:#ubuntu-quality- Builds: Ubuntu Studio DVD i386 [Trusty 14.04.5] has been updated (20160803.1)
[22:11] -queuebot:#ubuntu-quality- Builds: Edubuntu DVD i386 [Trusty 14.04.5] has been updated (20160803.1)
[22:11] -queuebot:#ubuntu-quality- Builds: Edubuntu DVD amd64 [Trusty 14.04.5] has been updated (20160803.1)


[10:12] <xnox> does the test require machine isolation? then it didn't run on armhf, and we don't test on riscv64..... hence all arches?!
[10:29] <schopin> slyon: could you please run this test again ? It seems to fail when acquiring an external resource... https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=armhf&package=dub&trigger=dub/1.24.0-1
[10:29] <schopin> TIA
[10:31] <schopin> slyon: meh, scratch that, someone already tried.
[10:31] <schopin> sorry.
[10:37] <slyon> :)
[11:48] <mwhudson> "livecd-rootfs/amd64 in main cannot depend on brz in universe" oh ffs
[11:49] <mwhudson> cc vorlon
[15:08] <vorlon> mwhudson: oh yes, there's that too
[20:14] <jawn-smith> I've determined that aspectc++ autopkgtests will pass with glibc and gcc-11 from impish-proposed
[20:15] <jawn-smith> so I think I've cobbled together a URL to make that happen if a core dev is so inclined: https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=amd64&package=aspectc%2B%2B&trigger=glibc/2.34-0ubuntu1&trigger=gcc-11/11.2.0-1ubuntu3
[20:22] <ginggs> jawn-smith: clicked
[20:25] <jawn-smith> thanks ginggs!
[20:26] <ginggs> yw!
[20:59] <mwhudson> vorlon: ideas? we might be able to download a tarball of the translations branch via loggerhead
[21:02] <mwhudson> https://bazaar.launchpad.net/~canonical-foundations/subiquity/translations-export/tarball/5?start_revid=5 -> HTTP 500
[21:03] <mwhudson> maybe we get the translations from subiquity git and try to be strict about updating them from lp regularly
[21:03] <mwhudson> (not that anyone is translating them at the moment because we haven't told anyone where the translations are)
[21:21] <jawn-smith> appears I was wrong about the gcc-11 thing. continuing to investigate
[21:35] <vorlon> mwhudson: putting them into subiquity git seems like a good idea
[21:36] <vorlon> mwhudson: part of why we're doing this is to support translation updates separately from updating subiquity, but that's also mostly for supporting targets/layers that aren't necessarily part of the Ubuntu build?
[23:33] <mwhudson> vorlon: yes
[23:34] <mwhudson> vorlon: we'll need to add the names / decriptions of the layers to the subiquity source so they end up in the pot file
[23:34] <mwhudson> we'll need to think about where translations for the desktop installer's source catalogs live i guess
[23:36] <bdmurray> mwhudson: Come to find out an apport change like this has happened before https://paste.ubuntu.com/p/8SmKsyP8bp/
[23:36] <mwhudson> bdmurray: sigh
[23:37] <bdmurray> anyway I did a bunch of stuff to convince myself its fine then found this


[00:03] <nagerst> Hello
[00:04] <nagerst> How do i fix resolution problems and flickering with the kms nv driver. Running curses apps.
[00:05] <nagerst> I bet that the resolution is wromg somehow, with the entire screen a bit to far to left.
[00:06] <nagerst> can i set KMS at 1920x1080@60hz?
[00:07] <nagerst> If i can find no help here, where should i look?
[00:27] <brainwash> nagerst: maybe #xorg
[11:42] <framac> Hi guys I'm thinking to upgrade to trusty but I need to disable the extras repositories, what are the implications of that action?
[11:53] <framac> Any thoughs?
[12:44] <BluesKaj> 'Morning folks
[20:24] <wallzero> I can't install the Cuda toolkit in Trusty. The nvidia-cuda-toolkit relies on nvidia-opencl-dev, which conflicts with nvidia-libopencl1-331 from the nvidia-331 drivers. Please advise.


[07:58] <Ddorda> hey all
[13:10] <adiroiban> hi. can you please add a logger bot in #launchpad-translators . I registered the channel and added freenode staff and ubuntuirccouncil members
[13:12] <jpds> adiroiban: You mean ubuntulog?
[13:13] <jussi01> adiroiban: you need to email rt about that.
[13:13] <adiroiban> jussi01: ok. thanks rt at ubuntu.com ?
[13:14] <jpds> adiroiban: That's the one.
[13:14] <adiroiban> jpds: thanks.
[14:09] <erUSUL> what is the correct way to disable gdm starting (Xserver) on boot. what is the equivalent of « sudo update-rc.d -f gdm remove » ?? found this http://ubuntu-ky.ubuntuforums.org/showthread.php?t=1322949
[14:10] <erUSUL> but it is way too hacky
[14:10] <erUSUL> for karmic that is
[15:31] <m4v> erUSUL: why would you want to do that?
[15:32] <erUSUL> m4v: becouse i could in jaunty; why not in karmic ? ;P
[15:34] <tsimpson> the init.d script has been replaced with an upstart job, editing the /etc/init/gdm.conf file is the way to do
[15:34] <tsimpson> * it
[15:39] <erUSUL> tsimpson: yep that's the way described in the link i posted. but i find it too hackish; isn't it ?
[15:40] <tsimpson> erUSUL: #upstart looks like a good place to start asking ;)
[15:43] <erUSUL> tsimpson: i asked. no better option than that offered ;)
[15:43] <tsimpson> file a bug then
[15:44] <erUSUL> tsimpson: btw doing « sudo mv /etc/init/gdm.conf /etc/init/gdm.conf.disabled » would disable it but you wont be able to do « sudo start gdm » after boot
[16:25] <LjL> erUSUL: so you basically can't set a service as manually started now? that's a silly regression if so :(
[16:35] <m4v> having to comment 3 lines isn't hackish, is the same as removing a script from rc2.d, just that there isn't a script for that.
[16:49] <erUSUL> LjL: you can commenting out the lines mentioned in the forum.
[16:50] <erUSUL> m4v: the helper script would help people making mistakes imho
[18:31] <bterm> can i get a cloak please https://launchpad.net/~bterm
[18:32] <Pici> bterm: Ubuntu cloaks are only available for Ubuntu Members
[18:32] <jussi01> bterm: you can get an unaffiliated cloak from freenode in #freenode - you need to be an ubuntu member to get an ubuntu cloak
[18:32] <Pici> !member
[18:32]  * jussi01 hugs Pici
[21:07] <Pici> niko: do you have a moment?
[21:07] <niko> yes


[05:13] <ScottK> Anyone around and awake and interested enough to look at a Java packaging bug?
[05:14] <ScottK> https://bugs.edge.launchpad.net/ubuntu/+source/jlha-utils/+bug/256275
[08:47] <catto> hello
[08:47] <catto> when I run aptitude show sun-java6-jre
[08:48] <catto> exist a conflict with j2se-common
[08:48] <catto> so the virtual machine doesnt work
[09:16] <persia> ScottK: I'm tempted to say NotABug: the dependencies are mostly that of Java itself.  That said, there's some efforts to make headless java (not requiring X, sound, etc.) work better, at which time this is more soluable.
[09:39] <kaaloo> Hi I'm working on packaging grails, learning a lot about packaging ! :)  There are existing packages for most build dependencies, however some major ones are missing, like hibernate3 or spring for instance.  Is it ok for the source package to include the needed jars ?  Or am I facing a recursive packaging problem ?
[09:44] <persia> kaaloo: There is a need for recursive packaging.
[09:45] <persia> The main reasoning for this is 1) it's best to have code in only one place, so by packaging the dependencies separately, any package that wants then can use the same one (and bugs fixed provide common benefit).  2) There's an interest in linking one package to one upstream release file for ease of updating later: this vastly simplifies the work of keeping the packages up to date.
[09:46] <persia> I suppose 3) it makes licensing easier when using one source might also apply, but it may not, depending on the specific packages considered.
[10:06] <kaaloo> persia: thanks for the insights !  so I should start with a subcomponent then.  There is actually something small I would like to change in the existing groovy package which is a build and runtime dependency for grails.  It depends on sun-java6-jdk instead of default-jdk.  Once I've made that change in the control file I can test the build with pbuilder.  If it builds ok, how do I submit a patch for that ?
[10:08] <persia> kaaloo: Ideally, file a bug and attach a debdiff for a new candidate revision that fixes it.  Then subscribe the sponsors queue.  For help getting your work into Ubuntu, #ubuntu-motu can help
[10:08] <persia> (for help figuring out Java packaging, this is a good place)
[10:12] <kaaloo> persia: thanks I'll work on doing that then for the groovy package, and work on it from there for grails. first things first ! :)
[10:12] <persia> kaaloo: Thanks for helping!
[10:18] <kaaloo> persia: yes I would like to help, have to learn more about packaging though, I hope there are not too many dependent packages to do from scratch though.  Oh !  One more thing, I was wondering about debian, if I manage to package grails and the missing dependent packages for intrepid, will they get included in the upstream distribution at some point ?
[10:22] <persia> kaaloo: Not automatically.  If you get them in shape, it would be great to also get them in Debian.
[10:23] <kaaloo> persia: ok I'm going to file a bug on the groovy package then and I will try to submit the patch then for the default-jdk dependency, hope that will get me started !
[10:24] <persia> I'll admit that I'm not sure exactly how the Debian Java team takes new packages, but perhaps you can discover it from http://java.debian.net/
[10:24] <persia> kaaloo: Excellent.
[10:24] <kaaloo> persia: what's strange is that there is a groovy project in launchpad, and there is the groovy package in the ubuntu project in lp, they don't seem to be related
[10:25] <kaaloo> persia: oh there is already another dependency bug listed for another component, I can check that one out at the same time
[10:25] <persia> kaaloo: Yeah.  Name conflicts are interesting.  For amusement, take a look at the git and epiphany packages some time.
[10:27] <kaaloo> persia: hmm, better stick to my original intent, but I'm going to see what I can do
[10:28] <kaaloo> persia: oh its not a name conflict, its the same stuff, it talks about linking to upstream, but its now a package in ubuntu since hardy apparently
[10:49] <kaaloo> persia: to maintain compatibility with hardy, should I add default-jdk as an alternative to the existing sun-java6-jdk build dep ?  I see you can combine them with pipe
[10:49] <slytherin> kaaloo: hardy doesn't have default-jdk package
[10:50] <kaaloo> slytherin: yes I know, I wanted to update the groovy package build dep to default-jdk
[10:51] <kaaloo> slytherin: for instance in the jbossas4 package I see depends like default-jre | java1-runtime | java2-runtime
[10:51] <slytherin> kaaloo: if you are doing that for intrepid, sure go ahead. Of course you need the dependency or only if you ever plan to request backport for hardy.
[10:51] <slytherin> kaaloo: otherwise default-jdk | sun-java6-jdk is not really needed.
[10:52] <kaaloo> slytherin: ok thanks, yes I'm doing it for intrepid, but I suppose since hardy is a its its better to be compatible with hardy backports, what do you think ? (I'm quite new at this)
[10:52] <kaaloo> slytherin: sorry an LTS
[10:53] <kaaloo> slytherin: I suppose if default-jdk is backported then we're ok, I'll focus on intrepid
[10:54] <slytherin> kaaloo: backports are not officially supported package. The only reason to keep sun-java6-jdk is to allow backport without change. May be you can remove sun jdk and add it later to facilitate backport if someone requests it.
[10:55] <kaaloo> slytherin: yes that's what I meant :)  cool.  Now I just want to try to build the new package with pbuilder, how can I updated the .dsc file ?  The instructions I have are pbuilder *.dsc but its the original version
[10:57] <slytherin> kaaloo: when you change control file, add an entry in debian/changelog with an increased version number. 'dch -i' should help you. Then do a debuild -S -sa which will generate .dsc for new version.
[10:59] <kaaloo> syltherin: ok thanks !  yes I updated the changelog, but didn't know about the -i option.  I'll generate the new .dsc and try that build then
[11:00] <slytherin> kaaloo: the dch -I was for auto adding a changelog entry.
[11:01] <kaaloo> slytherin: ok thanks
[11:03] <kaaloo> slytherin: let's see if the pbuilder build works
[11:22] <persia> kaaloo: Personally, I think it's better to make the transition for intrepid, even though it won't backport: we should really clean up the Java dependencies.  See https://bugs.edge.launchpad.net/ubuntu/+source/jlha-utils/+bug/256275 for an example of what can go wrong.
[11:26] <slytherin> persia: if it is a command line program, shouldn't it have *-jre-headless as dependency?
[11:27] <persia> slytherin: Yes.  I thought I remembered Koon saying something about headless not being ready yet.  If you think it can just be switched, that sounds good to me.
[11:28] <slytherin> persia: I will talk with Koon first to understand what exactly means by 'not ready'
[11:30] <persia> slytherin: It could also be my poor memory.
[11:30] <kaaloo> persia: yes I'll stick to intrepid, but I'm currently having problems with JAVA_HOME and pbuilder not having that env var setup
[11:31] <slytherin> persia: please take a look at the attachments on the gtk LNF bug.
[11:31] <slytherin> kaaloo: check debian/rules file. The JAVA_HOME should be /usr/lib/jvm/default-java
[11:31] <persia> slytherin: As I said before, personally I think that switching it is sensible.  I just fear complaints from Kubuntu folk.
[11:32] <slytherin> persia: I have left message for yuriy and subscribed him to the bug.
[11:32] <kaaloo> slytherin: oh sorry, I should have looked in the jbossas4 package for that
[11:37] <kaaloo> pbuilder is amazing ! 8-)
[11:45] <kaaloo> I'm now having an issue with dpkg-source: error: cannot represent change to groovy-1.5.6/target/docs/api/resources/inherit.gif: binary file contents changed.  It seems to pop up frequently in google, otherwise the build went well.
[12:20] <kaaloo> so that's done ! I submitted the debdiff on lp.
[12:32] <persia> kaaloo: You can't add binary files (e.g. a .gif) in the debdiff.  You'd have to encode it in ascii somehow.
[12:58] <kaaloo> persia:well I didn't attempt to add binaries, it seems to be a consequence of javadoc generating the groovy doc
[13:00] <persia> kaaloo: How did you generate the source package?
[13:00] <persia> I suspect you may need to delete something extra in the clean rule.
[13:01] <slytherin> I wonder why people use gif files for static images.
[13:01] <kaaloo> persia: I'm using pdebuild, ok I'll look into that
[13:06] <persia> slytherin: Legacy habits, mostly.
[13:06] <persia> kaaloo: I'll recommend building the source package with `debuild -S` and then building binaries.  That helps separate build problems from source build problems.
[13:09] <kaaloo> persia:  yes I first used debuild -S, then pbuilder, then I tried pdebuild when I learned about it, what's strange is that I did not change anything related to that part, just some dependencies
[13:10] <persia> kaaloo: It may be that you've discovered another bug.  No reason to only fix one at a time.
[13:11] <kaaloo> persia : exactly ! :)  I'll look into that so I can understand how that works
[13:11] <persia> kaaloo: Good luck.
[13:13] <kaaloo> persia: Thanks, and thanks for your help ! I posted a debdiff on the bug report already though, should I bump the version again for this problem ?
[13:15] <slytherin> kaaloo: no, your latest debdiff will be used anyway. So don't bump the version.
[13:16] <kaaloo> slytherin: ok thanks
[15:36] <ScottK> persia: I filed it because it prevents me using that package in a situation where it might be useful and because I knew headless Java was something that was being worked on in Intrepid, so I thought it might actually be solvable.
[15:36] <ScottK> Thanks
[15:37] <persia> ScottK: It's being looked at for intrepid, but I believe it unlikely to be solved for Hardy.  Note that those who have reviewed it so far are not yet entirely sure, but if it's safe, it will be fixed.
[15:38] <ScottK> Right, I didn't figure it'd be backportable.
[15:38] <persia> More generally, there's likely a lot of these that need review to better support server-side stuff.  As a server developer, might you have time to complain about this?
[15:39] <ScottK> Isn't that what the bug is?
[15:39] <persia> (Because most of the Java devs have complete JREs, so may not notice the problem, except where there is a specific goal of headless use that is part of the post-packaging testing)
[15:39] <persia> Yes:  There's probably about 30-50 of those bugs,  Finding them is more tricky.  It is hoped that the general review to migrate to openJDK will do most of it, but more eyes always help.
[15:40] <ScottK> I'll keep filing bugs if I find cases.  Is there a tag you want on such bugs and it sounds like some policy needs writing if it hasn't.
[15:41] <persia> doko sent instructions to the ML talking about the need for changing dependencies: I'm not sure we need more explicit policy.
[15:41] <persia> How about "java-headless" as a tag?
[15:41]  * persia tags the current bug as an example
[15:42] <persia> Grr.  edge.
[15:42] <ScottK> What tag to use would be an important thing to have written down and communicated to bugsquad I'd think.
[15:42] <persia> Indeed.
[15:43]  * ScottK notes that there is a current job posting on the Canonical web site for a Launchpad U/I developer and it includes a requirement for Flash experience.
[16:00] <kaaloo> I fixed the clean problem for groovy and submitted the debdiff for intrepid.
[16:00] <persia> kaaloo: Excellent.  Which bug?
[16:01] <kaaloo> https://bugs.edge.launchpad.net/ubuntu/+source/groovy/+bug/256325
[16:01] <kaaloo> persia: I'm going to check out the other bug that's listed there
[16:06] <kaaloo> persia: hmm, I have a doubt, should my debdiff be named groovy_1.5.6-1ubuntu1.debdiff or rather groovy_1.5.6-2ubuntu1.debdiff ?  I didn't add an ubuntu suffix at all.
[16:07] <persia> kaaloo: Your version in the changelog should be 1.5.6-1ubuntu1
[16:08] <persia> Also, don't forget the Debian Maintainer Field adjustment.
[16:08] <kaaloo> persia: ok I'll fix that then, yes I just saw that going through the other bug, thanks
[16:08] <persia> You may find that #ubuntu-motu is a good place to ask about general Ubuntu packaging and procedures (when it isn't Java specific)
[16:15] <kaaloo> persia:ok thanks I'll join that channel
[16:38] <kaaloo> persia: I updated the debdiff file, now taking a look at the other bug which doesn't seem valid to me.
[16:41] <persia> kaaloo: Excellent.  Ideally you'll be able to close all the bugs (either fixing or deciding that they aren't actually bugs) for the upload.
[16:42] <kaaloo> persia: I can close it myself once the debdiff is attached ?
[16:44] <persia> kaaloo: No, it gets closed when it gets uploaded.  Include the string (LP: #nnnnnn) in your changelog for each thing you did to indicate which bug to close.
[16:45] <kaaloo> persia: Ouch, I put (Closes LP: #256325), do you think it will still get caught ?
[16:54] <persia> kaaloo: Avoid "closes" for uploads to Ubuntu: that is reserved for uploads to Debian.
[16:56] <kaaloo> persia: ok thanks
[17:21] <kaaloo> persia: I'm getting problems with groovysh, I saw this yesterday for another java program, java.lang.UnsatisfiedLinkError: Can't load library: /usr/lib/jvm/java-6-openjdk/jre/lib/i386/motif21/libmawt.so
[17:23] <persia> kaaloo: Hmm..  I remember there being issues with Motif, but don't remember the details.  Some Motif is considered non-free.  Does it run with sun-java6 ?
[17:24] <kaaloo> persia: I think so, let me check.  The program yesterday was PortableSigner for signing pdf files and it run ok with sun-java6
[17:25] <persia> kaaloo: Might be an issue with what is implemented in OpenJDK vs. what is implemented in sun-java6.
[17:29] <istarex> Did you run a particular program in groovysh?  I can run it okay w/ openjdk
[17:37] <persia> istarex: So the dependency on sun-java6 would be for the programs run under groovysh, rather than groovysh itself?
[17:38] <istarex> maybe
[17:38] <istarex> I just executed groovysh at the commandline and it starts okay
[17:42] <kaaloo> istarex: sorry I was testing some stuff
[17:43] <kaaloo> istarex: the problem is that openjdk does not support the MToolkit for awt
[17:43] <kaaloo> istarex: I did export AWT_TOOLKIT=XToolkit and groovysh runs fine under openjdk
[17:44] <kaaloo> istarex: be careful because startGroovy doesn't seem to take update-alternatives into account, you have to manually set JAVA_HOME
[17:46] <persia> kaaloo: Ah, if that's all, just be sure to set a different toolkit by default: it's better to only require OpenJDK than it is to provide Motif widgets (especially because almost nobody is used to them anymore)
[17:47] <kaaloo> persia: yes I'm just wondering how to set that env variable up in the package, anyhow open jdk says they won't support MToolkit because too old
[17:47]  * persia suspects it's something about licensing as well
[17:48] <persia> kaaloo: One mechanism used to set environment variables at runtime is to have /usr/bin/$(package) be a shell script that sets stuff up and calls a real binary somewhere.
[17:48] <kaaloo> persia: http://www.openjdk.org/groups/awt/ -> '... Here you will also find code for MToolkit, requiring a proprietary Motif library. However, this is considered obsolete and isn't built as part of OpenJDK. ...'
[17:49] <kaaloo> persia: oh of course, I'll patch the groovyStart script or the groovysh script, but actually this should be in the openjdk package, its general to openjdk
[17:50] <kaaloo> There are some bugs about this in openjdk, I'll post my findings there.
[17:51] <persia> kaaloo: Good idea.
[17:52] <kaaloo> persia: actually they are all over the place in different application packages (of course) :(
[17:53] <kaaloo> persia:  I'll go through that later on today and patch the openjdk package, I hope it won't be too hairy
[17:57] <persia> kaaloo: Good luck.