=== asac_ is now known as asac
[15:38] <lamont> what piece where creates /var/run/reboot-required?
[15:38] <lamont> on kernel install, that is
[15:49] <rtg__> lamont: not sure. update-manager?
[15:51] <lamont`> rtg__: dunno... I just know that my ia64 box doesn't get it touched...
=== lamont` is now known as lamont_
=== lamont_ is now known as lamont__
[15:52] <rtg__> lamont: sounds like a Scott remnant question.
[15:52] <lamont__> kewl
=== lamont__ is now known as lamont
[15:53] <lamont> stupid nick
[16:41] <bullgard4> Are the /etc/default* files even relevant any more considering the use of upstart?
[17:04] <stgraber> hi there, I just installed 2.6.24-19 (taken from LP as the meta is stuck in new) and my mouse acceleration and scrolling speed are really weird
[17:04] <stgraber> I no longer have smooth scrolling and mouse seems slower than usually (that's what I feel at least)
[17:15] <rtg__> lamont: I just install kernel/lum/lrm/lbm using apt-get and now the upgrade manager is bugging me to restart, so it must be something in the kernel package that sets the hook.
[17:16] <lamont> rtg__: that was what I thought... and ia64 seems to be lacking that fix.
[17:16] <lamont> s/fix/change/
[17:16] <rtg__> lamont: I wonder why its special. 
[17:17] <lamont> rtg__: short bus. obviously.
[17:20] <rtg__> lamont: does /usr/share/update-notifier/notify-reboot-required exist as an executable?
[17:21] <lamont> rtg__: well, then.  that would explain it.
[17:22] <rtg__> lamont: in the git source its in ubuntu-hardy/debian/control-scripts/postinst , look for notifier. 
[18:06] <lamont> rtg__: next kernel upload (intrepid certainly, and for hardy-updates maybe?) could you make the *FS_XATTR flags for hppa match x86?
[18:07] <lamont> and would you like a bug to that effect in launchpad?
[18:08] <rtg__> lamont: yeah, Martin pretty much requires it for any SRU updates.
[18:08] <lamont> ok
[18:08] <rtg__> lamont: you could also attach a patch.
[18:08] <lamont> meh
[18:09] <lamont> that would mean fetching source and wearing my dev hat for longer than I want to today :-(
[18:09] <rtg__> lamont: whiner.
[18:09] <lamont> I might make a patch for it later today
[18:10] <rtg__> there is just the 4, right? CONFIG_CIFS_XATTR, CONFIG_EXT2_FS_XATTR, CONFIG_EXT3_FS_XATTR, CONFIG_REISERFS_FS_XATTR.
[18:10] <rtg__> ignore CONFIG_CIFS_XATTR
[18:10] <lamont> x86 has JFFS2_FS_XATTR as well... but yeah, just the 4
[18:11] <lamont> ls -l kinda bitches when it doesn't agree about that setting...
[18:11] <rtg__> lamont: ok, you make the SRU report and I'll do the patch.
[18:11] <lamont> SRU justification: "meh. it's hppa."
[18:11] <lamont> martin == pitti, yes?
[18:12] <rtg__> lamont: yes, martin == pitti
[18:12] <lamont> cool
[18:30] <lamont> rtg__: having learned more about the issue, I'm less certain I care enough to fix hardy, although it seems like a useful thing to allow people to use, eh?
[18:31] <lamont> fixing /bin/ls to not whine about the syscall returning EOPNOTSUP is certainly more correct (it's a legal return value, why are you whining ls??)
[18:34] <rtg__> lamont: well, what are extended attributes? security stuff?
[18:34] <lamont> rtg__: you ask that like I might know... :0)
[18:34] <infinity> lamont: Fixing hardy's kernel would be nice, especially if there's an SRU or security update queued "soon" anyway.
[18:35] <lamont> infinity++
[18:35] <lamont> whatever extended attributes are
[18:35] <rtg__> infinity: is there any reason that all the arches shouldn't have the same XATTR settings?
[18:36] <lamont> I mean, hell, even ia64 gets them.. :-)
[18:36] <infinity> rtg__: I see no reason why they shouldn't all be in sync in that regard.
[18:36] <lamont> I believe they should all be the same
[18:36] <rtg__> ok, simple enough.
[18:36] <infinity> rtg__: Honestly, configs for all arches should be nearly identical for everything that isn't pure hardware support.
[18:36] <lamont> I would be completely surprised if they were arch-specific
[18:37] <infinity> rtg__: This is, I fear, a problem that will be compounded by the ports/non-ports package split, but time will tell.
[18:37] <lamont> infinity: don't say that where hppa can here you... I brutalized that config quite sometime go
[18:37] <lamont> ago
[18:37] <rtg__> infinity: agreed.  I don't know how they drifted. I probably inherited it from Gutsy and never noticed.
[18:38] <lamont> rtg__: so I assume you'd still like a bug and me to poke pitti?
[18:39] <rtg__> lamont: just file the bug and poke me (since I get to make it happen)
[18:39] <lamont> cool
[18:41] <infinity> rtg__: Do we have a pending kernel update soonish, or should we roll our own fixed kernels for now?
[18:42] <lamont> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/237699
[18:42] <rtg__> infinity: I just uploaded -19 last night, so there isn't likely to be another before the point release unless there are regressions.
[18:42] <lamont> rtg__: fwiw, it's buildd-affecting :(  so we're happy to test a kernel for you...
[18:43] <infinity> rtg__: Damn, our timing sucks.
[18:43] <rtg__> infinity: some thing like this is a pretty minor update. I don't have a problem with it.
[18:43] <lamont> meanwhile, I'll see about the "fix ls" approach
[18:43] <rtg__> infinity: I just have to get it by slangasek.
[18:43] <lamont> tell him you polled the entire known hppa/ubuntu user community, and they said "please"
[18:44] <infinity> lamont: While I'll agree that coreutils is "wrong" in this case, I still want a kernel that matches the rest of the architectures.  We should at least NMU this to hardy-cat for now, until a fixed version hits -updates/-security
[18:44] <lamont> infinity: yeah
[18:44] <infinity> lamont: You want me to work up the patch and build it in -cat, or will you?
[18:45] <lamont> infinity: happy to let you do it if you want...
[18:45] <lamont> kernel muckery is requiring more and more bandwidth
[18:45] <infinity> Bandwidth is something I have plenty of now that I don't live in Australia.
[18:45] <lamont> I live in that small part of australia that is in colorado. :(
[18:45] <infinity> Brainpower, on the other hand, requires waking up.
[18:46] <lamont> go for the expresso.  who needs water diluting the caffeine?
[18:47] <infinity> I was thinking I'd just go for the fruit juice approach.
[18:50] <lamont> OMFG.  coreutils is dbs???
[18:51] <infinity> There are still DBS packages?
[18:51] <lamont> _essential_ dbs packages
[18:52] <infinity> Whacky.
[18:52] <infinity> I used to maintain a few, until public pressure forced me to change to dpatch.
[18:52] <lamont> hrm... I guess I can ask myself to install builddeps in the chroot, eh>?
[18:52] <infinity> Heh.
[18:53] <lamont> lamont: done.
[18:53] <lamont> :-)
[19:06] <Kano> hi, when will be intrepid kenrel update to rc5?
[19:08] <rtg__> Kano: sometime in the next few days I imagine. BenC has been handling it.
[19:09] <Kano> ok
[19:16]  * BenC starts the lum->linux merge
[19:17] <rtg__> BenC: are still creating the zinc accounts? I have a request from Mario for one.
[19:21] <munckfish> For those who are interested - tonight I will be building/patching testing the intrepid-ports kernel for PS3.
[19:29] <zul> that reminds me is the custom flavour git repo ready yet?
[19:35] <infinity> rtg__: Oh, I didn't realise that -19.33 was only in -proposed, not yet in -updates.  Perhaps there'd still be time to squeeze in the hppa fix, then? :)
[19:36] <rtg__> infinity: possibly. I have 7 days before it gets moved.
[19:41] <mkrufky> who should i talk to about packaging kernel modules directly for ubuntu bypassing upstream?
[19:42] <mkrufky> (for a canonical partner)
[19:42] <rtg__> mkrufky: me or BenC
[19:42] <mkrufky> ok... do you have a few minutes now?
[19:43] <mkrufky> the code i plan to sumbit is not ready, but i have a build system solution .....  i am not using DKMS, but i have good reason not to
[19:43] <rtg__> mkrufky: I'll answer if I can.
[19:43] <mkrufky> i just want to run it by u guys to make sure its OK before i lose time depending on it
[19:43] <mkrufky> ok.... so, this is for two new digital television devices
[19:43] <rtg__> this is something you want in LUM ?
[19:43] <mkrufky> i am adding new modules, and i am NOT replacing any preexisting modules
[19:44] <mkrufky> yes, i believe that lum is the right place for it
[19:44] <mkrufky> i believe that we're targetting 8.04.2
[19:45] <mkrufky> basically, i have a build system that allows me to patch linuxtv.org hg tree *and* produce backports to recent kernels without patch conflicts
[19:45] <rtg__> mkrufky: adding new drivers that have no possibility for regression are fairly easy. Why not DKMS, though?
[19:45] <mkrufky> not DKMS, because i need to develop *within* the linuxtv.org devel repositories, so this method allows me to build against l-u-m headers instead of local headers
[19:46] <mkrufky> im sure that there is a WAY to make it work in DKMS, but the solution i have not is working perfectly
[19:46] <mkrufky> if its not broken, dont fix it :-P
[19:46] <mkrufky> ...also, i have a deadline
[19:46] <rtg__> ok, so you want to submit a patch to the kernel team mailing list? Or a pull request?
[19:46] <mkrufky> er,TYPO
[19:46] <mkrufky> sorry... i meant, the solution i have not is working perfectly
[19:46] <mkrufky> oops again .. .noW workingperfectly
[19:47] <mkrufky> if it's simply a matter of patch submission, then that's fine
[19:48] <rtg__> mkrufky: thats OK for Hardy, but we're still trying to decide what to do for Intrepid wrt the myriad of third party modules. DKMS is definitely getting some attention.
[19:48] <mkrufky> however....  im not sure if there are advantages to submit OUTside of l-u-m or not
[19:48] <mkrufky> i fully agree that DKMS is the way of the future
[19:48] <rtg__> mkrufky: if your driver is in LUM, then you are stuck with my release schedule.
[19:48] <mkrufky> this particular project is slated for 8.04.2 (i think) and intrepid is not on the table.  these new modules will already be upstream for intrepid
[19:49] <mkrufky> ah, ok ... so maybe best to build outside of LUM
[19:49] <mdomsch> mkrufky, a) I can help with DKMS if you need
[19:49] <rtg__> mkrufky: it just depends on how frequent you expect updates to be. I'm throttled by the 7 day -proposed delay.
[19:49] <mdomsch> mkrufky, b) why bypass upstream?  upstream first!
[19:50] <mkrufky> chill :-)
[19:50] <mkrufky> i always go to upstream first -- this is for a retail project
[19:50] <infinity> lamont: Is there any reason why config.hppa32 has EXT{2,3} as modules, but config.hppa64 links them statically?
[19:50] <lamont> hppa64 is the config that I was gutting like a trout trying to figure out why it hated life.
[19:51] <mkrufky> just that the device being sold will have 8.04.y pre-installed on it, thats why i have to backport to hardy
[19:51] <lamont> it was left (a) somewhat gutted, and (b) rather hating life still
[19:51] <infinity> lamont: Err, kay.  So, I should perhaps just ignore it and fix hppa32? :/
[19:51] <lamont> infinity: in the end, a working hppa32 just gets told to be hppa64 in the arch-specific section, and there is love.
[19:51] <infinity> lamont: I was going to move the EXT configs back to hppa/config, and remove the arch-specific configs for the filesystems.
[19:52] <lamont> pretty much any driver you can need on hppa64 can be found needful on hppa32, and vice versa
[19:52] <rtg__> mkrufky: so not necessarily a device that can host a DKMS rebuild?
[19:52] <lamont> (well, that's technically a bit wrong, but feh)
[19:52] <mkrufky> rtg__: i understand that question
[19:52] <infinity> lamont: Kay.. Well, I'll just fix hppa32 for now, then.
[19:52] <infinity> lamont: Since that's what we're running anyway.
[19:52] <mkrufky> yikes, typos -- i *dont* understand that question, rtg__
[19:53] <lamont> infinity: for that matter, feel free to throw everything from hppa32->hppa and just breakout the PA1.1 vs PA2.0 diff for hppa{32,64}
[19:53] <rtg__> mkrufky: DKMS requires the ability to rebuild modules when the kernel ABI changes. 
[19:53] <mkrufky> i will submit source code, it will totally be rebuildable
[19:53] <rtg__> mkrufky: that implies a compiler, usually spinning media, etc.
[19:53] <infinity> lamont: That's slightly too big a change for me to be comfy with for hardy. :)
[19:54] <infinity> lamont: For intrepid, sure.
[19:54] <lamont> right
[19:55] <rtg__> mkrufky: I understand it will be open source, but do you want to be rebuilding the module on your commercial target machine?
[19:55] <mkrufky> rtg__: i'll qualify the scenario --  a large OEM will be selling a tiny laptop with ubuntu on it, that oem will be packaging two of my digital tv sticks, canonical agreed to host the additional modules
[19:55] <mkrufky> nah, the consumer must not build the modules
[19:55] <mkrufky> the consumer will simply install the new module package with the driver support
[19:55] <rtg__> mkrufky: ok, then DKMS is probably not the right way to go.
[19:56] <rtg__> mkrufky: how about hosting your driver in your PPA and preseeding the commercial unit to pull from that PPA?
[19:56] <mkrufky> PPA ?
[19:56] <rtg__> mkrufky: personal package archive, it works very similar to the main Ubuntu archive.
[19:57] <mkrufky> it will be hosted on canonicalpartners.com
[19:57] <tseliot> mkrufky: PPA is a personal repository hosted by launchpad
[19:57] <mkrufky> er, i might have that domain wrong, but you know what i am refering to
[19:57] <rtg__> mkrufky: the PPA is hosted somewhere in launchpad.net
[19:57] <pwnguin> when you say "must not rebuild modules"
[19:57] <pwnguin> is that "not be required, or not allowed"
[19:58] <mkrufky> pwnguin: was that question to me?
[19:58] <pwnguin> mkrufky: sorry, yes
[19:58] <tseliot> mkrufky: if you don't use DKMS you will have to make sure that the packages are rebuilt and uploaded every time the kernel ABI is broken
[19:58] <mkrufky> pwnguin: users must not be required to rebuild the modules themselves ...  of course, they are allowed
[19:58] <pwnguin> okies
[19:58] <pwnguin> you'd be surprised ;)
[19:59] <mkrufky> i believe in open source :-)
[19:59] <mkrufky> anybody that doesnt should suffer bitrot :-P
[19:59] <rtg__> mkrufky: DKMS would not require any intervention on the part of the user. The modules gets rebuilt automatically when the ABI changes.
[19:59] <tseliot> mkrufky: with DKMS, if you have the compiler and the kernel headers installed, the kernel module will be automatically rebuilt without user intervention
[20:00] <mkrufky> so....   basically, if i want to be able to sumbit code to you guys once (assuming i dont need to provide updates) then all i need to do is port my system to DKMS and then you'll rebuild whenever needed?
[20:00] <mdomsch> no
[20:00] <mdomsch> the rebuilds happen on the end user's computer
[20:00] <mkrufky> oooh... so with DKMS, users still have to build locally
[20:00] <mdomsch> (whcih may be undesirable)
[20:00] <mkrufky> hmm
[20:00] <tseliot> mkrufky: there's a script which does that automatically. There's no need to reupload anything
[20:01] <mdomsch> they don't have to - one _could_ set up the build system to build it
[20:01] <mkrufky> this particular product does not have disk space to allow such kernel builds
[20:01] <mkrufky> ie:  the OEM does *not* want users to have kernel headers on the machine
[20:02] <mkrufky> ok... in summary, it sounds like i should do LUM and let that be the end of it
[20:02] <rtg__> mkrufky: I think you should first investigate PPA and see if it will work for you.
[20:02] <mkrufky> LUM == i send in a patch or a pull request from my git tree, you guys rebuild on your release schedule
[20:02] <mkrufky> PPA sounds like it will require that I constantly rebuild when the ABI breaks -- is that true?
[20:02] <rtg__> mkrufky: yep, LUM will be less responsive.
[20:03] <rtg__> mkrufky: the ABI won't change more then a few more time, perhaps 4 in the next 2 years.
[20:03] <mkrufky> eek
[20:03] <rtg__> mkrufky: its the network security updates that usually cause it.
[20:04] <mkrufky> i have a deadline to provide code to ubuntu by june20th for imaging, and im under the impression that i'll have two or three update drops after that within the next two months or so
[20:04] <infinity> rtg__: It's been a while since I've done this.  Do I need to do something to tell the kernel package that "Yes, I know this is the same ABI as the previous upload and no, you don't have ABI files yet, shut up," or does it handle that gracefully now?
[20:04] <rtg__> infinity: you on -19? I updated the ABI files but I haven't pushed yet.
[20:05] <infinity> rtg__: I'm just patching -19.33 to suit our needs in the DC for now, yes.
[20:05] <rtg__> infinity: you can touch debian/abi/*/ignore to _not_ fo the ABI check.
[20:07] <rtg__> mkrufky: you really need to get code to me earlier then the 20th. Things are starting to freeze right now for an extended test period.
[20:07] <mkrufky> i can give you code today, but the USB ids are all going to change
[20:08] <mkrufky> is it easier to do that, and give you a tiny patch later?
[20:08] <pwnguin> whos usb ids are you using right now?
[20:08] <rtg__> mkrufky: yeah, that works. I can update LUM easier then the kernel 'cause it won't cause an ABI bump.
[20:08] <mkrufky> pwnguin: they
[20:08] <mkrufky> pwnguin: they're all my companie's IDS
[20:09] <mkrufky> but... this driver is for our CURRENT product
[20:09] <mkrufky> the new ids are for the actual product, which will have branding on it specific to the OEM
[20:09] <pwnguin> mkrufky: ok then. just as long as you dont clobber someone else's :)
[20:09] <mkrufky> nah ... when i give the vid:pid update, i'll be ADDING ids, not changing any
[20:10] <mkrufky> this driver is already in 2.6.26, but i backported it to 2.6.24 for hardy
[20:11] <rtg__> ok gents - lunch is calling me. back in awhile.
[20:13] <pwnguin> I've got a bug filed against wacom-tools that I think is a kernel bug
[20:13] <pwnguin> what do I do to hand it off / get the right people looking at it?
[20:16] <mkrufky> heh, a co-worker just told me he added some power management stuff.....   so i have to test this for a day or two before i submit
[20:16] <mkrufky> rtg__: OK if I send in a patch early next week, instead or today?
[20:16] <mkrufky> ...and ur eating lunch ....  thanks for the help everybody :-)
[20:21] <munckfish> Is the AUTOBUILD variable actually still used?
[20:34] <munckfish> I note that in the hardy kernel sources it's using old/wrong way to get git HEAD id hash (cat .git/HEAD)
[20:37] <infinity> rtg__: Building a test kernel now, BTW.  If this goes smoothly, I'll pass the patch on to you.
[20:38] <infinity> rtg__: Cause I'm sure you prefer tested hppa patches to untested ones that require several uploads, using slow buildds as a test platform. :)
[20:38] <rtg__> infinity: you are so right :)
[20:38] <rtg__> munckfish: AUTOBUILD might be fubared.
[20:39] <munckfish> rtg__: I guessed as much
[20:40] <infinity> rtg__: Given that -19- is only in -proposed, I assume that even if this constitutes an ABI horizon, we can fudge that for hppa?
[20:41] <infinity> rtg__: (And it almost certainly will be an ABI change on hppa64, since I fixed the static/module ext setup there...)
[20:42] <rtg__> infinity: last time I looked hppa hadn't even built yet for -19. For an update I can just create abi/*/hppa/ignore so it bypasses the ABI check.
[20:44] <rtg__> infinity: nope, still needs building. I could ask that it not be NEWED if it does build anytime soon.
[20:45] <infinity> rtg__: Hrm, good point.  I'll queue it way down so it doesn't build at all.
[20:45] <infinity> (Or, not for a very, very long time...
[20:45] <infinity> )
[20:45] <infinity> Or I could queue it up and fail it intentionally.  That might be easier.
[20:45] <infinity> (LP really needs a way for me to just make a build not happen)
[20:46] <rtg__> infinity: thats fine with me. I definitely do not want to roll the ABI again before 8.04.1 is in the can.
[20:46] <Ng> is there a good way to do a custom build of LUM wrt the version number? altering it seems to break the build somewhat (in that it looks for matching headers packages)
[20:46] <rtg__> Ng: mess with debian/changelog  ? The do a clean to regen the control info.
[20:47] <rtg__> *Then do a clean...
[20:47] <Ng> mmkay, I'll give that a shot. so far I've just been twiddling the version number in changelog to try and find a mutation which doesn't break everything else
[20:47] <Ng> I'm probably doing this in completely the wrong way just to get newer alsa modules ;)
[20:48] <rtg__> Ng: oh, good luck. You messing with 1.0.17rc1 ?
[20:48] <Ng> nightly \o/
[20:48] <Ng> I didn't realise there was a .17rc yet, I should try that out and see if it works
[20:49] <rtg__> Ng: ALSA was a major pain in the ass to package.
=== mkrufky is now known as mkrufky-away
[20:50] <Ng> rtg__: I seem to have figured out about 3 steps to replace the one in LUM with a random nightly, but then this package only has to work on one piece of hardware ;)
=== mkrufky-away is now known as mkrufky
[22:30] <lifeless> https://bugs.launchpad.net/bugs/99755 - mario from Dell thinks there is a patch for the suspend problem affecting dell D430 & D630's
[22:31] <lifeless> can anyone comment on whether the patch is good/missing/etc?
[22:34] <rtg__> lifeless: that patch made it into -19 via another bug report (can't remember which one)
[22:35] <lifeless> rtg__: intrepid build right? can I just grab that and lum and drop on hardy?
[22:35] <rtg__> lifeless: hardy 2.6.24-19
[22:35] <lifeless> oh cool
[22:35] <rtg__> in -proposed
[22:35] <lifeless> I will give it a spin in the weekend all going well
[22:35] <lifeless> (unless you warn me off :))
[22:36] <rtg__> lifeless:  it went in because of Bug: #183033
[22:37] <rtg__> which is likely a duplicate of 99755
[22:37] <lifeless> different symptoms but yeah I can see that
[22:38] <rtg__> lifeless: memory corruption can exhibit an infinite number of symptoms.
[22:38] <rtg__> i think its the same root cause in this case.
[22:39] <rtg__> tomorrow is another day. later...