[01:45] <chilicuil> hi, I'm confused about how to generate a .dsc file from the kernel package, I downloaded an upstream kernel, applied some patches and on top of it ubuntu packaging files http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12.1-trusty/ (0001 and 0002), however it seems to require some special steps, I can see a debian/ and a debian.master/ folders, and debuild -S fails since debian/ doesn't contain a changelog.txt and control files, do I re
[01:47] <chilicuil> if I run $ fakeroot make-kpkg --initrd kernel_image kernel_headers modules_image it compiles and creates .deb files correctly, though
[02:19] <bjf> chilicuil, run fakeroot debian/ruls clean first
[02:19] <bjf> chilicuil, then run the debuild command
[02:20] <bjf> chilicuil, are you wanting to upload the package to your own ppa to have it built there?
[02:20] <chilicuil> bjf: yep
[02:22] <bjf> chilicuil, then you want to first "fakeroot debian/rules clean"   followed by: "debuild -S -I -i -uc -us -sa"
=== gerald is now known as Guest85875
[02:29] <chilicuil> bjf: ok, yep, it seems to work, do you know by change how to change the version pkg?, I tried s/3.12.1-031201.201311201654/3.12.1+chilicui~ck1/ and when running d/rules clean it fail with: debian/rules.d/0-common-vars.mk:9: *** first argument to `word' function must be greater than 0. Stop, line 9 in the mentioned file seems to look at the package version to set revision, revision ?= $(word $(words $(revisions)),$(revisions)) 
[03:47] <bjf> chilicuil, change the version string in the first line of debian.master/changelog
[03:49] <chilicuil> bjf: awesome, I may even take a look at how to do a flavour, the files start to make sense, thanks for your  help!
[03:49] <bjf> chilicuil, after you do that you need to run "fakeroot debian/rules clean" again
[03:51] <bjf> chilicuil, you should then have a debian/changelog that has your version in it
[03:53] <chilicuil> it's clear, thanks for your help =)
[03:54] <bjf> chilicuil, np
=== _ruben_ is now known as _ruben
[08:43] <ppisati> moin 
[09:14] <apw> moin
=== psivaa-afk is now known as psivaa
=== shuduo_ is now known as shuduo
[13:09] <rtg> apw, have you been looking at why the ppc64el 64K config change broke the build ?
[13:19] <infinity> rtg: *blink* ... It did?
[13:20] <rtg> infinity, or rather, it has broken thecross compile (at least)
[13:20] <infinity> Is it actually a 1-liner to the config, or did he oops something? :P
[13:21] <rtg> infinity, as far as I can tell it is a legitimate change
[13:21] <apw> rtg, not yet no
[13:21] <rtg> apw, maybe I'm just being stupid, but it doesn't work for me
[13:21]  * apw has a look
[13:22]  * apw bets it is the subpage stuff it offered me
[13:22] <infinity> -# CONFIG_PPC_HAS_HASH_64K is not set
[13:22] <infinity> +CONFIG_PPC_HAS_HASH_64K=y
[13:22] <infinity> That bit?
[13:23] <apw> nope
[13:23] <apw> oh stupid zone order issues
[13:23] <infinity> Oh, subpage_prot.  I don't even know what that does.
[13:24] <infinity> Seems suspicious that it landed in common.ubuntu when it wasn't set before, though.
[13:25] <infinity> Unless it's only a dep of 64K, I guess.
[13:25] <apw> but the first issue is zone bit sizes
[13:25]  * apw sorted out the spagetti
[13:26] <infinity> Anyhow, are we actually ready to make that change?  Are we satisfied on the state of the openldap issue?
[13:27] <rtg> infinity, apw thinks he's proved it to be a test issue and can repro it using amd64 (IIRC)
[13:28] <rtg> unless I completely misread his analysis, which is a distinct possibility
[13:28] <infinity> rtg: Yeah, I'm familiar with the state of the bug.  But we were still not going to move until it was fixed.
[13:29] <apw> infinity, the plan was to get the change ready, and when we are ready to upload again check with the    state of play in the bug
[13:29] <apw> seems it was good idea, to make sure it builds even :)
[13:30] <apw> we can revert it off if we arn't ready, i had hoped for more movement
[13:30] <infinity> apw: Fair enough.  Easy enough to revert the commit (well, 2 commits now, probably), if we decide we're not ready.
[13:30] <infinity> apw: I'm backchannel escalating a response on the matter. :P
[13:30] <rtg> apw, since it is HEAD, how about just lopping it off
[13:30] <apw> rtg, lop it sure, i'll queue it here
[13:31] <apw> with the second half if htis builds
[13:33] <rtg> apw, lemme know when you're done. I've got some mei cherry-picks to push
[13:33] <rtg> (which I have test built)
[13:35] <apw> rtg, zap that commit and shove over it, i'll branch here to keep this safe
[13:36] <rtg> apw, done, and pushed
[13:39] <apw> rtg ack thanks
[14:40] <rsalveti> apw: can you also bump the meta packages in the ppa?
[14:40] <rsalveti> guess it changed the abi for every device/kernel
[14:49] <rsalveti> argh, got disconnected 
[14:49] <rsalveti> apw: can you also bump the meta packages in the ppa?
[14:49] <rsalveti> guess it changed the abi for every device/kernel
[15:02] <rsalveti> Feb 27 15:02:08 ubuntu-phablet rtkit-daemon[1552]: Successfully made thread 3042 of process 1546 (n/a) owned by '32011' RT at priority 5.
[15:02] <rsalveti> Feb 27 15:02:08 ubuntu-phablet rtkit-daemon[1552]: Supervising 3 threads of 1 processes of 1 users.
[15:02] <rsalveti> looks good now
[15:02] <rsalveti> ogra: ^
[15:17]  * ogra has a hard time to type .... just chopped two trees in the garden 
[15:18] <ogra> (cant feel my fingers)
[15:19] <rsalveti> hahah
[15:19] <ogra> but i won !
[15:20] <ogra> :)
=== zequence_ is now known as zequence
[15:47] <apw> rsalveti, yep can do
[15:47] <apw> ogra, whats the bug number for that second one
[15:48] <rsalveti> thanks
[15:48] <ogra> apw, havent filed it ... will do so ... soon 
[15:48] <ogra> i wanted to check on all devices first 
[15:49] <ogra> i'll get that done today
[16:41] <henrix> kamal: hi! while processing 8d80390cfc9434d5aa4fb9e5f9768a66b30cb8a6 for stable kernels, i had to hack the notify-stable-patch-queued script
[16:41] <henrix> kamal: here's a proposed patch: http://pastebin.ubuntu.com/7005732/
[16:42] <henrix> kamal: the reason is the SMTP RFC that seems to limit lines to 998 chars :)
[16:42] <henrix> kamal: a similar change will need to be done for the -review script
[16:44] <kamal> henrix, looks fine to me
[16:44] <henrix> kamal: cool!  i'll push it to kteam-tools
[16:45] <henrix> kamal: and don't forget to use that new option in the next batch of 3.8 emails :)
[16:46] <kamal> henrix, ok, I'll try to remember ... what's the effect if you don't use it?  it just stops in the middle of the notify run?
[16:47] <henrix> kamal: no, it won't stop -- it will fail to send the 8d80390cfc patch, and hopefully you'll notice that :)
[16:47] <kamal> henrix, ack
[16:57] <henrix> kamal: ok, fix pushed
[19:48] <miseria> "el amor inicia con la velocidad de tus ojos, aterriza en el poder de tu mente se cristaliza con la piel de tus manos" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
[19:57] <smoser> sforshee, 
[19:57] <smoser> oops.
[20:48] <rtg> jsalisbury, 'cifs: use standard token parser for mount options' is a giant patch
[20:51] <jsalisbury> rtg, yeah, I figured it would be too big for inclusion in stable.  
[20:51] <rtg> jsalisbury, I'm thinking we could just backport  the relevant part of 'cifs: set MAY_SIGN when sec=krb5'. After all, its a one line patch.
[20:53] <jsalisbury> rtg, the problem is the one line is in a function named cifs_parse_security_flavors, that gets added in the other large patch(8830d7e)
[20:55] <jsalisbury> rtg, Maybe the bug reporter can use the lts-backport kernel 
[20:59] <rtg> jsalisbury, vol->secFlg exists in the old code. I think its just a matter of adding that flag. See line 1116 in fs/cifs/connect.c in Precise
[20:59] <rtg> Using the LTS kernel is also an option
[21:02] <jsalisbury> rtg, cool, thanks for the pointer.  I'll build a test kernel with that one line change and also propose the LTS kernel.
[21:21] <jackbrown> rec and arecord commands don't capture any sound on my machine could anyone help me to check how to set the proper device to capture sound ?
=== hughhalf_ is now known as hughhalf