[00:57] <soreau> Guys, I have no idea what happened but all of the sudden, evince fails with "evince: error while loading shared libraries: libX11.so.6: failed to map segment from shared object: Permission denied"
[00:57] <soreau> Can someone give me a hint as to what might be wrong?
[00:58] <soreau> Also I can't seem to start 'gksu software-properties-gtk'. It just gives a busy cursor for a few seconds, returns and gives no additional output
=== dendro-afk is now known as dendrobates
[04:53] <ScottK> pitti: I'd appreciate it if you could arrange for qt4-x11 to get out of binary New.  AIUI didrocks needs this for work at the sprint this week and it's my upload, so I shouldn't do it.
=== Guest47276 is now known as Adri2000
=== SolidLiq is now known as solid_liq
=== Ursinha-afk is now known as Ursinha
[08:52] <pitti> ScottK: oh, sure
[08:53] <pitti> doing now
[09:00] <tkamppeter> pitti, hi
[09:00] <pitti> hey tkamppeter
[09:00] <tkamppeter> pitti, are you in Dublin now?
[09:00] <pitti> yes
[09:01] <tkamppeter> pitti, it is about AirPrint. we could ask the people on the Sprint to test.
[09:02] <tkamppeter> pitti, first you should pass the SRU of bug 801306 to -updates (it is already verified) and upload CUPS for Oneiric, so that everyone gets the fixed AirPrint support by a simple update.
[09:02] <ubottu> Launchpad bug 801306 in cups (Ubuntu Natty) "AirPrint only works with "ServerAlias *" in /etc/cups/cupsd.conf" [Undecided,Fix committed] https://launchpad.net/bugs/801306
[09:03] <tkamppeter> pitti, then make a call for testing on the Sprint, for example during today's plenaries.
[09:03] <pitti> tkamppeter: with cups I was going to wait until the current unstable version goes to testing, but if it's helpful, I can upload the current bzr head to oneiric, yes
[09:03] <tkamppeter> pitti, would be great.
[09:03] <pitti> tkamppeter: or do it on Friday, when most people want to print their your boarding passes anyway :)
[09:04] <tkamppeter> pitti, I by myself will be on the Sprint on Thu and Fri, but doing the testing through the whole Sprint would be much better.
[09:05] <tkamppeter> pitti, is there a printer on the Sprint, or does the testing only work as I described on the list, with a file printer?
[09:05] <pitti> I haven't seen a printer yet, need to ask around
[09:09] <tkamppeter> pitti, can you have a look at bug 799064?
[09:09] <ubottu> Launchpad bug 799064 in foo2zjs (Ubuntu) "package foo2zjs 20110210dfsg-1ubuntu2.1 failed to install/upgrade: Fehler beim Schreiben von »<Standardausgabe>«: Datei oder Verzeichnis nicht gefunden" [Undecided,New] https://launchpad.net/bugs/799064
[09:10] <tkamppeter> pitti, what is going wrong there?
[09:12] <pitti> tkamppeter: (in plenaries, looking later)
[09:39] <evfool> tkamppeter, pitti : that's an interesting bug, I saw quite a few bur reports related to that, aka unable to find standard output to write to
[09:40] <SpamapS> jhunt: hey lets get together some time before lunch to chat about some stuff to collaborate on this week
[09:41] <tkamppeter> evfool, so it is not specific to this package?
[09:41] <tkamppeter> evfool, if this is a general problem, it most probably needs to get reassigned to another package. Which one?
[09:42] <evfool> tkamppeter: i saw problems similar in docbook-xml, libcap2, gthumb, compiz-plugins-main, aso...
[09:43] <evfool> tkamppeter: i'm not sure, as it happens while installing/upgrading either it's a problem in dpkg, or the package install scripts do something ugly for many packages
[09:43] <evfool> tkamppeter: but that's just a guess
[09:44] <evfool> tkamppeter: found that, its dpkg, bug 545790
[09:44] <ubottu> Launchpad bug 545790 in dpkg (Ubuntu) "package PACKAGE failed to install/upgrade: error writing to '<standard output>': Success" [High,Confirmed] https://launchpad.net/bugs/545790
[09:45] <tkamppeter> evfool, will mark my bug as duplicate of this one. Thanks.
=== Eren is now known as TA1AET
[09:47] <jhunt> SpamapS: sure. do you want to get together in 5?
[09:48] <SpamapS> we won't be able to break out of here for a bit.. mor elike 90
=== TA1AET is now known as Eren
=== Eren is now known as ta1aet
[09:49] <tkamppeter> evfool, never seen such a long duplicate list.
[09:49] <evfool> tkamppeter: yep, it's interesting, and I see many which are not yet marked as dupes
=== ta1aet is now known as TA1AET
[10:11] <kirkland> slangasek: could you fairly urguently look at https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/802197 ?
[10:11] <ubottu> Ubuntu bug 802197 in util-linux (Ubuntu) "no sysfs entry in /etc/mtab breaks encrypted-home" [Critical,Triaged]
[10:11] <kirkland> slangasek: the recent util-linux update is locking oneiric users out of their encrypted-home directories because util-linux is not writing an /etc/mtab entry for sysfs
[10:13] <slangasek> kirkland: we should ask lamont the question of whether this behavior change is intended
[10:13] <slangasek> lamont: ^^
[10:14] <kirkland> slangasek: sure... lamont?
[10:14] <kirkland> slangasek: is lamont here in Dublin?
[10:15] <slangasek> kirkland: I don't think so
[10:16] <slangasek> I haven't heard loud and dry from IS so far, only loud and cackling
[10:16] <kirkland> slangasek: :-D
[10:16] <kirkland> slangasek: i'll subscribe him to that bug and ask for a comment
[10:16] <slangasek> ok
[10:25] <evfool> mvo:ping
[10:28] <mvo> hey evfool
[10:31] <evfool> mvo: how bad is an aptdaemon api change? to fix bug 771678, had to change the space and download transaction props from int32 to int64
[10:31] <ubottu> Launchpad bug 771678 in aptdaemon (Ubuntu) "<type 'exceptions.OverflowError'>: Value -1608156160 out of range for Int32 while installing" [Medium,In progress] https://launchpad.net/bugs/771678
[10:31] <evfool> mvo: could you please check the branch attached, as that bug's starting to have lots of dupes
[10:33] <em> hey what is to prevent ubuntu devs/security team from stealing people's bitcoins?
[10:33] <glatzor_> evfool, since there are currently only python clients the change should not do any harm
[10:33] <directhex> em, nothing. muahahahaha, etc.
[10:34] <em> hehe
[10:34] <evfool> thanks glatzor, thats good
[10:34] <em> I better keep my bitcoin wallet.dat on a usb flash drive separate from my computer.
[10:36] <Laney> how would that help?
[10:37] <cjwatson> if you don't trust your operating system, you shouldn't run it
[10:37] <mvo> evfool: thanks, I will do that
[10:37] <evfool> thanks mvo, glatzor
[10:37] <cjwatson> there's really not much way around that
[10:37] <em> well i believe the only way that someone can get my coins is if they have the keys that are in wallet.dat
[10:37] <mvo> hey glatzor_!
[10:38] <cjwatson> it's hardly new to bitcoins; an evil browser maintainer could snoop on all traditional e-commerce transactions conducted through a web browser, too
[10:39] <em> cjwatson: true but somehow i think if a person successfully steals bitcoins it is very likely and much easier for them to get away scott free.
[10:39] <slangasek> this is merely evidence of why bitcoins are a naive system
[10:39] <Laney> luckily you're running a Free OS, so can inspect the code running on your computer
[10:39] <cjwatson> it's a fundamental trust issue either way
[10:39] <Laney> but... how far can you trust that? http://cm.bell-labs.com/who/ken/trust.html
[10:39] <ion> em: To which operating systems would you attach the drive?
[10:40] <directhex> em, have you ever audited the *upstream* bitcoin code?
[10:40] <em> im not too paranoid about the code in Ubuntu/Linux. I surely trust that more than the propreitary ones. But I am a little nervous about the Ubuntu Security team and what they (can) see with updates or bug fixes to certain aps.
[10:41] <cjwatson> if you are nervous about the Ubuntu security team, I don't think you can safely run Ubuntu at all
[10:41] <em> Also I don't know who the Ubuntu Security team is on a personal level so don't feel insulted.
[10:41] <cjwatson> I think it's more likely that the Ubuntu security team has zero interest in stealing people's bitcoins
[10:41] <directhex> mostly former kgb agents, why does that have any bearing?
[10:42] <ion> Simply don’t run Ubuntu at all, run the operating system whose security team you do trust instead. Problem solved.
[10:42] <glatzor_> hey mvo!
[10:42] <em> I think everyone would agree that they are probably basically very upstanding people but wouldn't everyone also agree that the finest of people could break if they had a chance to get away with 400 thousand dollars without a trace?
[10:42] <jdstrand> what is the specific problem here? that dpkg runs maintainer scripts as root?
[10:43] <cjwatson> I can only repeat that if this is a genuine concern then you shouldn't run Ubuntu (or shouldn't use bitcoins in conjunction with it)
[10:43] <em> Well then I think that it's just an interesting thing to consider how bitcoins make security even more interesting and important than it ever was before. Now that many people have really valuable stuff on their computers.
[10:43] <cjwatson> there is no way to reassure you
[10:43] <StevenK> em: I disagree.
[10:43] <em> how come?
[10:43] <cjwatson> bitcoins are hardly more "really valuable" than all the credit card transactions people have been doing on their computers for over a decade
[10:43] <jdstrand> ah, bitcoins
[10:43] <StevenK> em: People have been storing usernames and passwords for things that give access to *real money* for years.
[10:44] <StevenK> Pretty much what cjwatson said.
[10:44] <em> cjwatson: Well the reason I disagree with that is that if you have my credit card number, sure enough you could steal from me, but (1) It's much more difficult for you to get away with it, and (2) It's pretty easy for me to undo the damage to myself.  Neither of those are true with bitcoins.
[10:45] <cjwatson> if you log into my online banking facility and make a non-CC transfer of some kind, it would be difficult for me to undo the damage
[10:45] <barry> if you steal enough bitcoins can you buy a cache of stolen credit card numbers?
[10:45] <cjwatson> it would certainly cause me a good deal of work
[10:45] <directhex> em, you seem to be under the mistaken belief that the security team is anonymous. let's follow your supposition, that someone in the security team uploads a bitcoind which sends keys someplace, or sends coins to some address, or somesuch.
[10:45] <StevenK> em: Then the flaw is with bitcoins, not the OS you run?
[10:45] <ion> em: Given your assertion that any person is likely to choose to steal the 400k dollars given a chance i don’t see how the issue affects Ubuntu any differently than the alternatives.
[10:45] <directhex> em, now, what happens when the first guy notices a missing balance? then the next guy? the issue is isolated to ubuntu, the rogue update is found, the person who uploaded it is named and sued
[10:46] <cjwatson> directhex: (and fired, in all probability)
[10:46] <jdstrand> and arrested
[10:46] <em> StevenK: no I don't think that's fair to say. I'm not here to cast dispersions on anyone or say there is any flaw in any OS. It's just the nature of bitcoins. And I think bitcoins create a new level of interest in security.
[10:46] <directhex> cjwatson, i think that's implicit?
[10:46] <cjwatson> yeah, but just to make it explicit.  anyone trying this has a lot to lose.
[10:46] <directhex> jdstrand, afaik you can't be arrested in the uk for stealing bitcoins. they're considered a virtual good, so have no value until traded for something material
[10:47] <em> ion: yeah this is not about Ubuntu really.
[10:47] <jdstrand> I would be surprised if I couldn't get arrested in the US for it. but I don't know. let's just say it sounds incredibly risky :)
[10:48] <kees> SECURITY UPDATE: your bitcoins were not part of my balance. This has been fixed.
[10:48] <directhex> kees++
[10:48] <StevenK> Hahaha
[10:48] <cjwatson> directhex: I expect you could be arrested; whether it would be wrongful is a different matter ;-)
[10:48] <jdstrand> CVE-2011-$$$$
[10:48] <em> ion: I dont know that I'm asserting "any" person is likely to steal 400K.  That 400K was a made up number and Im sure that many (most?) people would resist the temptation. But I think it is human nature that given the chance to commit a 'perfect crime' most people have some price.
[10:48] <cjwatson> em: the notion that such a thing would be untraceable is not accurate, I think
[10:48] <cjwatson> all changes to the Ubuntu archive are traceable
[10:48] <directhex> em, your belief that it's a perfect crime is based upon several veriufiably false premises
[10:49] <em> directhex: could be you are right about your senario but bitcoins make a certain sort of anonymity pretty easy for someone who knows what they are doing. No one could say for sure who actually has the bitcoins once they are gone.
[10:49] <cjwatson> sure, it would likely take time to trace, but *shrug*
[10:50] <Laney> you can say for sure who pushed out the malicious piece of software though
[10:50] <Laney> unless they manipulated the archive ...
[10:50] <cjwatson> a security update that turned out on inspection to include 'mail evildoer@ubuntu.com </home/em/wallet.dat' would be a bit of a smoking gun
[10:50] <em> do you guys know a lot about bitcoins? Im not claiming to be an expert but, as a cursory understanding, I think that if you manage to send my bitcoins to an address of your chosing, we will never catch you if you are clever enough.
[10:51] <directhex> em, now you're deliberately ignoring what people are telling you.
[10:51] <cjwatson> em: there would have to be some software that mailed it to an address of one's choosing
[10:51] <cjwatson> em: that software and that address could be traced
[10:51] <em> directhex: no no there's just a lot of people telling me things. Let me try to catch up.
[10:51] <cjwatson> unless it was a security update that gave a particular security team member a shell on your system, and then *that* would be traceable and probably even more easily prosecuted
[10:52] <cjwatson> (since there are plenty of established computer misuse laws in most jurisdictions)
[10:52] <em> Oh yeah you are saying that it will be possible to figure out who put the trojan/backdoor/malicious code in.
[10:52] <Laney> Launchpad is a better place to do this really
[10:52] <directhex> em, not possible: trivial.
[10:53] <em> I guess the attack could either be that you somehow get a copy of my wallet.dat or else that you actually hijack my bitcoin client and use it to send yourself my coins.
[10:53] <cjwatson> this is no more fundamentally interesting than any of many other possible attacks that people with upload privileges to the Ubuntu archive might perform (and similarly be traced for)
[10:54] <em> anyway i didn't mean to disrupt things here and i'm not trolling you guys. I am just not usually awake right now :)
[10:54] <cjwatson> don't get distracted by the anonymity provided by bitcoins; that's only one level
[10:54] <jpds> http://www.economist.com/node/18836780
[10:55] <em> I think the advent and growth of bitcoins increases the incentives for people to attack ordinary people's computers, and the incentive for ordinary users to be paranoid VERY significantly.
[10:55] <em> But this last comment I made here has nothing to do with ubuntu or ubuntu security in particular.
[10:56] <directhex> yet people trust their wallets to mtgox. look how that turned out
[10:56] <em> people do not trust their wallets to mtgox.
[10:56] <em> they do trust however many bitcoins they have there though and USD.
[10:57] <em> mtgox is a weird case because, like most things in the 'bitcoin economy' it's an ad hoc project slapped together by some ambitious kids and now it's making thousands of dollars a day.
[10:57] <em> but it's true, i dont think anyone that runs mtgox is any kind of professional or really knows what they are doing.
[11:05] <barry> cr3: hey man, are you around and if so, what room?  can we chat about checkbox?
[11:05] <cr3> barry: hey dude, I'm around but kinda busy right now. lets plan to merge chad's branch this week
[11:07] <barry> cr3: cool.  any chance we can do that earlier in the week?  i'd love to close out the conversion task as early as possible.  i'm happy to help in any way
[11:07] <barry> cr3: thanks!
[11:10] <cr3> barry: sure, I'm all for it
[11:10] <barry> cr3: awesome, thanks man
=== smb` is now known as smb
[11:26] <slangasek> doko: the avahi pointer-from-integer failure is due to changed gtk headers, actually :)
[11:29] <cjwatson> pitti: do you know why http://people.canonical.com/~ubuntu-archive/pending-sru.html doesn't list bug 56679 for netcfg?
[11:29] <ubottu> Launchpad bug 56679 in checkbox-satellite "provide a method to use a specified MAC-address as the installation device" [Undecided,New] https://launchpad.net/bugs/56679
[11:30] <slangasek> maybe it doesn't know what to do with 5-digit bugs ;P
[11:45] <pitti> cjwatson: hmm, looking
[11:47] <pitti> slangasek, cjwatson: the bug number is in http://launchpadlibrarian.net/73636370/netcfg_1.51ubuntu3_source.changes, so until there it worked
[11:47] <pitti> (it parses Launchpad-Bugs-Fixed:)
[11:47] <cjwatson> right
[11:50] <pitti> ah, drat
[11:50] <pitti> slangasek: you were right after all :)
[11:50] <slangasek> hahaha
[11:50] <pitti> re.compile('lp:?\s*#(\d{6,7})', re.I)
[11:50] <slangasek> :-)
[11:50] <pitti> I think I added that after getting too many false positives by other garbled changelogs
[11:51] <pitti> {'56679': [u'patch', u'verification-done']}
[11:51] <pitti> there we go
[11:51] <pitti> cjwatson: fixed; and congrats for fixing a five-digit bug :)
[11:52]  * pitti will fix it more properly now, though
[11:52] <cjwatson> that doesn't merit congratulations, all I did was ignore it for some years ;-)
[12:02] <pitti> tkamppeter: I asked on the bug for debugging; no immediate idea either, there's not much information there
[12:03] <pitti> tkamppeter: oh, someone duped it in the meantime
[12:03] <pitti> tkamppeter: seems it's quite an old dpkg bug inded
[12:03] <pitti> indeed
=== dendrobates is now known as dendro-afk
[12:08] <pitti> ScottK, any KDE expert: is pkgkde-debs2symbols and/or pkgkde-gensymbols a magic solution to the per-architecture .symbols files somehow?
[12:08] <pitti> IOW, when I want to add symbols files for a C++ library, can I get them any other way than just upload, grab the diffs from the buildd logs, and upload again?
[12:12] <cjwatson> pitti: having to use per-architecture symbols files normally means that you're failing to use dpkg-gensymbols' facilities for C++ symbols properly
[12:12] <cjwatson> for example, using mangled names
[12:13] <cjwatson> see the "Using symbol patterns" section in dpkg-gensymbols(1)
[12:16] <slangasek> cjwatson: except for functions which use a different int type on 32- vs. 64-bit systems, where counterintuitively things wind up using 'int' on 32-bit and 'long' on 64-bit
[12:17] <pitti> cjwatson: I'll read that then; but manually creating patterns for 537 symbols sounds painful
[12:18] <cjwatson> slangasek: yes; you could use (c++|regex) though
[12:18]  * slangasek nods
[12:18] <doko> gcc -v -E - < /dev/null 2>&1 | awk '/^#include/,/^End of search/ {i=1} i==1 && /^ / {print}'
[12:33] <stgraber> barry: http://paste.ubuntu.com/633583/
[12:37] <tkamppeter> pitti, I was the one who duped the bug, after evfool helped me with it.
[12:38] <ScottK> pitti: Thanks (on qt4-x11) and AIUI yes on pkgkde-gensymbols.  http://pkg-kde.alioth.debian.org/symbolfiles.html has additional information on it.
[12:38] <tkamppeter> pitti, any news about possibilities of AirPrint testing on the sprint?
[12:38] <mvo> evfool: your branch looks fine, did glatzor give you any feedback ? if he is fine as well, I'm happy to merge it right away
[12:40] <evfool> mvo: glatzor only wrote that as aptdaemon has only python clients, changing from int32 to int64 shouldn't affect them
[12:42] <mvo> evfool: sounds like agreement to me ;)
[14:22] <sconklin> pitti: Do you think you'll be able to publish our kernels today?
=== kklimonda^ is now known as kklimonda
=== kklimonda is now known as Guest43465
=== Guest43465 is now known as kklimonda^
=== kklimonda^ is now known as kklimonda
=== hallyn is now known as hallyn_afk
[14:50] <slangasek> stgraber: the umount manpage (even in natty) says that umount takes a '-d' option to handle loop device removal... were you using that option?
[15:20] <cjwatson> slangasek: I must say I don't ever recall having to do so; and I don't see why umount couldn't detect that
[15:20] <cjwatson> the man page says "The umount command will free the loop device (if any) associated with the mount, in case it finds the option `loop=...' in /etc/mtab, or when the -d option was given."
[15:21] <cjwatson> hm, a test loop mount/umount here does free the loop device though
[15:23] <slangasek> ah, so maybe it's a bug in the mtab writing, rather
=== kentb_ is now known as kentb_dell
[15:36] <pitti> does that depend on uevents in any way?
[15:36] <slangasek> shouldn't
[15:36] <pitti> because I noticed that umount doesn't remove the loop devices in a way that udev picks up
[15:37] <pitti> i. e. umount() fails to generate a remove event for them (which losetup -d does)
[15:37] <pitti> ok
[15:40] <slangasek> odd
[15:41] <psusi> pitti: did the device actually get removed?
[15:41] <pitti> psusi: yes, but silently
[15:41] <psusi> whoa... that shouldn't be possible
[15:42] <pitti> which causes bugs like bug 548546
[15:42] <ubottu> Launchpad bug 548546 in linux (Ubuntu) "Nautilus does not remove usb drive made with USB-Creator after unmounting it" [Undecided,Triaged] https://launchpad.net/bugs/548546
[15:42] <pitti> psusi: well, mount as in the program doesn't do this; it's the mount() syscall which is cleaning up the loop mount, and the kernel just forgets to send the uevent
[15:43] <psusi> pitti: what?  no... it's the umount program that does it when it sees the loop option in mtab
[15:44] <pitti> last time I looked, umount() didn't actually have any code for the loop cleanup
[15:44] <pitti> kees: released linux linux-meta linux-ports-meta linux-backports-modules-2.6.35 to maverick-security
[15:46] <apw> cjwatson: am i right in thinking that if i replace caspers initrd.lz with an initrd.gz it will just work without change?
[15:49] <kees> pitti: thanks!
[15:51] <cjwatson> apw: should do, yes, as long as you adjust the boot loader configuration too
[16:04] <psusi> pitti: wait a second... loop devices don't actually get deleted... they are precreated when the module is loaded...
[16:09] <psusi> pitti: ohh boy... I think I just found it... it seems there's a flag you can set to have the kernel auto clear the loop when the last reference to it is dropped, so I guess that is what mount uses instead of having umount clear it.
[16:09] <pitti> psusi: right, but they shold still generate a change event, like losetup -d does
[16:09] <pitti> psusi: right
[16:09] <psusi> pitti: when it auto clears in loop.c:1525, it passes NULL for the bdev to loop_clr_fd, which causes it to not emit the uevent
[16:10] <pitti> I think I even reported that to bz.k.o, checking
[16:10] <pitti> https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/548546/comments/44
[16:10] <ubottu> Ubuntu bug 548546 in linux (Ubuntu) "Nautilus does not remove usb drive made with USB-Creator after unmounting it" [Undecided,Triaged]
[16:11] <pitti> had my findings back then
[16:11] <pitti> hmm; seems I meant to report it, but didn't
[16:33] <pitti> bdmurray: filed as bug 802589, FYI
[16:33] <ubottu> Launchpad bug 802589 in xkeyboard-config (Ubuntu) "KEY_CYCLEWINDOWS invalidly mapped to XF86RotateWindows" [Undecided,New] https://launchpad.net/bugs/802589
[16:41] <bdmurray> pitti: thanks
=== hallyn_afk is now known as hallyn
[17:21] <debfx> superm1: could you please have a look at my dkms patches on bug #802617 and bug #766150
[17:21] <ubottu> Launchpad bug 802617 in dkms (Ubuntu) "module build error fails package installations" [Medium,New] https://launchpad.net/bugs/802617
[17:21] <ubottu> Launchpad bug 766150 in dkms (Ubuntu) "apport hook should only generate reports about supported kernel versions" [High,Triaged] https://launchpad.net/bugs/766150
[17:22] <debfx> tjaalton: ^ you might be interested in them as well
[17:24] <tjaalton> debfx: thanks, looking
[17:27] <tjaalton> debfx: thanks, they make a great deal of sense :)
=== korn_ is now known as c_korn
[17:37] <loganaden> hi
[18:27] <NewbieToKernel> where can i find ubuntu source code including the kernel?
[18:31] <holstein> NewbieToKernel: https://help.ubuntu.com/community/Kernel/Compile#Get the kernel source
[18:32] <holstein> http://ubuntuforums.org/archive/index.php/t-14756.html might be helpful as well
[18:40] <NewbieToKernel> the linux kernel is same accross all distributions rite?
=== ximion1 is now known as ximion
[18:41] <hallyn> NewbieToKernel: no
[18:41] <hallyn> NewbieToKernel: different distros use (a) different versions with (b) different patches and (c) different configs
[18:41] <NewbieToKernel> so there is a seperate ubuntu kernel?
[18:41] <hallyn> but the heart of it is the same
[18:41] <NewbieToKernel> oic
[18:42] <NewbieToKernel> so what are the other packages that constitute the ubuntu distro?
[18:42] <hallyn> you can look at http://kernel.ubuntu.com/git/ for the source used in ubuntu
[18:43] <hallyn> i'm not sure i understand the question, but if you have an ubuntu system running you can do 'dpkg -l' to look at all the packages installed
[18:43] <hallyn> then 'apt-get source <packagesourcename>' to download the source
[18:44] <hallyn> (where packagesourcename is what you get from 'apt-cache show <package> | grep Source')
[18:44] <hallyn> that should get you going enough to look around
[18:44] <hallyn> btw, the current development kernel is at http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=summary
[18:44] <NewbieToKernel> so that is just the kernel or the other packages that come along with ubuntu as well?
[18:45] <hallyn> dpkg -l shows them all
[18:45] <hallyn> all that are installed that is
[18:46] <NewbieToKernel> so i has all the packages along with the ubuntu specific kernel?
[18:50] <NewbieToKernel> hallyn?
[18:50] <hallyn> hm?
[18:51] <hallyn> i don't understand your question.  do you have a running system?
[18:51] <hallyn> a running ubuntu system?
[18:51] <NewbieToKernel> no
[18:51] <NewbieToKernel> i want to build the ubuntu kernel
[18:52] <NewbieToKernel> for x86 although it has already been built
[18:52] <NewbieToKernel> the i want to include the packages one by one that constitute ubuntu
[18:52] <NewbieToKernel> and build them from sources
[18:53] <NewbieToKernel> the link that you gave me has a lot of git repos
[18:53] <hallyn> the next link i gave you has exactly one
[18:53] <hallyn> you can get clone that and build it as any other kernel
[18:53] <NewbieToKernel> ok. cool
[18:54] <hallyn> 'make defconfig; make -j16 > log 2>&1'
[18:54] <NewbieToKernel> so after that how do i know what other packages are included as part of the standard uuntu distro?
[18:54] <hallyn> now, if you want to build the kernel exactly as it would be built for ubuntu,
[18:54] <hallyn> i.e., same configs,
[18:54] <hallyn> there's more to it.  jump to #ubuntu-kernel for such info
[18:55] <NewbieToKernel> ok...cool
[18:55] <NewbieToKernel> so after the kernel is built ... how do i build packages?
[18:56] <NewbieToKernel> and how do i know what packages are part of ubuntu distro?
[18:57] <hallyn> not sure what the easiest way would be to do that.  TO build, just apt-get source like i said before, then do 'fakeroot debian/rules build'
[18:57] <hallyn> biaw
[18:59] <NewbieToKernel> thx!!
=== ximion1 is now known as ximion
=== beuno is now known as bueno
=== bueno is now known as beuno
=== lborda is now known as lborda_afk
[19:56] <superm1> debfx, yeah i'll look.  do they apply to trunk?
[20:01] <debfx> superm1: I'm not sure
[20:01] <superm1> debfx, well trunk is significantly different
[20:01] <superm1> hopefully it will be pulled into debian and merged for ubuntu
[20:02] <debfx> trunk as in master or 2.2.0.0?
[20:03] <superm1> 2.2.0.0 was just released so it's same as master, but the version in ubuntu is about a year old
[20:03] <superm1> so if the patches are relative to the version in ubuntu they might need rework
[20:06] <debfx> superm1: looks like master hasn't been updated. 2.2.0.0 is more recent than master
[20:06] <superm1> hm, i wonder if forgot to push the tag
[20:10] <superm1> debfx, no the tag is out on master
[20:10] <superm1> http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=dkms.git;a=summary
=== JasonOO is now known as JasonO
=== yofel_ is now known as yofel
[21:15] <psusi> pitti: it looks like since kernel 2.6.37, mount sets the autoclear flag instead of recording the loop device in mtab.  The previous behavior was to just record the device name in mtab and umount will properly clear it.  A simple fix should be to simply cut that line of code and force the old behavior
[21:17] <psusi> pitti: mount.c:1270 in util-linux checks the kernel rev and enables SETLOOP_AUTOCLEAR... one snip there should take care of it
=== dendro-afk is now known as dendrobates
[22:02] <hallyn> bug 802538
[22:02] <ubottu> Launchpad bug 802538 in udev (Ubuntu) "/etc/udev/rules.d/70-persistent-net.rules not automatically generated" [Medium,Confirmed] https://launchpad.net/bugs/802538
[22:03] <hallyn> does anyone here know whether/why it was assumed that not creating persistent /etc/udev/rules.d/ net entry for vmware net devices would not impact guests?
[22:03] <hallyn> (re bug 802538)
[22:03] <ubottu> Launchpad bug 802538 in udev (Ubuntu) "/etc/udev/rules.d/70-persistent-net.rules not automatically generated" [Medium,Confirmed] https://launchpad.net/bugs/802538
=== ximion is now known as ximion1
[22:17] <broder> hallyn: presumably it was an attempt to avoid situations where the mac address of the guest changed each time the guest was started
[22:18] <broder> xen used to do that in its default configuration
[22:19] <broder> and so you'd end up with eth0, then you'd reboot and get eth1, then eth2, etc
[22:19] <hallyn> hm, does vmware do that?  if so that makes sense
[22:25] <hallyn> lunaphyte_: is there something you need that file for?  or was this curiosity?
[22:25] <hallyn> ie do you actually have two NICs (not in the logs) you want to keep straight?
[22:27] <lunaphyte_> i have a vmware guest, running ubuntu - that i use as a template.  when i deploy a new guest from that template, the mac address changes.  i have a little deployment utility i wrote to address this item [along with a few other items], which deletes that file.  then, when a new guest is deployed, a new file is created, with the new mac address.
[22:28] <lunaphyte_> just one nic
[22:28] <hallyn> but not having the file created doesn't actually cuase trouble right?
[22:29] <lunaphyte_> i have not seen vmware change the mac address of a guest between reboots.  that would potentially break things quite heavily.
[22:29] <lunaphyte_> i haven't tried with the file, so i'm not certain what would happen.
[22:29] <lunaphyte_> err - *without the file, rather.
[22:30] <lunaphyte_> i can test that, if it would help.
[22:31] <hallyn> well i'm just wondering how much we should care and what lengths to go to to document this.  like i say, i think vm's with multiple nics are the ones who might be negatively impacted.
[22:31] <hallyn> do you know if, evne if you restart vmware (and maybe reboot the host), does the vm still maintain the same MAC?
[22:31] <hallyn> biab
[22:32] <lunaphyte_> well, i can't restart vmware or reboot the host - there are many other guests on it, but i can just about guarantee you that it will not change.
[22:32] <lunaphyte_> bbiab myself :)
[22:37] <hallyn> mdeslaur: was able to create an oneiric vm with the new vm-new.  It doesn't boot, but I *assume* that's unrleated :)
[22:37] <mdeslaur> desktop or server?
[22:38] <mdeslaur> hallyn: ^
[22:38] <hallyn> server
[22:38] <mdeslaur> ah, I did test oneiric desktop, but I just added server support, and may not have tested oneiric
[22:38] <hallyn> ok i'll try out desktop tomorrow.  Just need to find the right iso :)
[22:39] <hallyn> do you plan to add support for vm-new automatically rsync'ing?
[22:39] <mdeslaur> last oneiric desktop daily iso I tried was 20110622
[22:39] <mdeslaur> and it worked
[22:39] <mdeslaur> rsyncing the isos?
[22:39] <hallyn> yeah
[22:39] <mdeslaur> I hadn't thought about it, but it seems like a good idea
[22:41] <hallyn> just bc i had downloaded the -alternate cd before realizing i couldn't use that :)
[22:41] <mdeslaur> oh, yeah, sorry :)
[22:41] <mdeslaur> I should add support for that as well
[22:51] <mdeslaur> hallyn: confirmed, I tested with hardy-natty server, but had not tested with oneiric...I'll look at it tomorrow if I have a minute
[23:18] <lunaphyte> hallyn: my particular environment is vmware esx, with 10 hosts, housing ~120 guests - this is just one of the guests.  guests are always being rebooted, shut down, moved from host to host [automatically sometimes even], and in the years we've been using this, i've never seen the mac address of a guest change - aside from as intended/desired when a template is deployed.
[23:24] <hallyn> lunaphyte_: can you comment that on the bug?  I don't know if that change came from udev upstream, from debian, or from us...  we should find out who filed the bug that was being addressed
[23:32] <lunaphyte> yeah, i'll do that.
[23:46] <bdrung> kirkland: does anything speak against upstreaming the changes from lintian 2.4.3ubuntu3?