[03:00] <fnerd> Anyone tried ? 16.10?
[03:01] <TJ-> everyone on 16.04
[03:02] <fnerd> Yes, mee too
[03:03] <fnerd> I'm currently downloading 16.10
[03:04] <dax> probably quicker to just change sources and dist-upgrade if you already have 16.04
[03:05] <TJ-> my point was that the 16.10 archive is the same as 16.04 right now, so everyone running 16.04 is also running 16.10 :)
[03:06] <dax> not quite the same
[03:06] <dax> but yeah, not a lot yet
[03:07] <TJ-> the archive hasn't been opened for uploads yet, whilst some xenial SRUs get resolved
[03:14] <dax> random example:
[03:14] <dax> !info dovecot-core
[03:15] <dax> !info dovecot-core xenial
[03:15] <dax> or is that part of the SRU process or something
[03:16]  * dax honestly has no idea
[03:19] <TJ-> Steve was on about it earlier, in response to a question
[03:19] <TJ-> 00:21 <slangasek> mwhudson: I think the current plan is to open once icu lands in xenial, so that the libpng16 library transition doesn't get entangled with further uploads
[03:35] <fnerd> So I'm waisting my time downloading 16.10?
[05:08] <\LSD> am i waisting time downloading 16.10?
[06:50] <ikonia> \LSD: why are you downloading it if you don't even really know why
[07:01] <\LSD> I'm stupid ikonia
[07:03] <\LSD> I'm downloading to build kernel for no reason ,maybe just compilation for latest release
[07:03] <\LSD> Actually not much of real use


[00:03] <ari-tczew> bdrung: Pushed up to revision 4.
[00:03] <bdrung> ari-tczew: what did you push?
[00:03] <ari-tczew> bdrung: me? nothing. that's sponsor-patch
[00:04] <bdrung> ari-tczew: that comes from bzr
[00:06] <ari-tczew> bdrung: did I contribute to u-d-t today?
[00:11] <ari-tczew> yay! it works!
[00:11]  * ari-tczew gives a beer for bdrung and tumbleweed
[00:17] <ari-tczew> bdrung, tumbleweed: sponsor-patch created this branch: https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/cnetworkmanager/natty-201012220015
[00:18] <bdrung> ari-tczew: please file a bug. bzr push needs to be more intelligent
[00:18] <ari-tczew> bdrung: tomorrow. I have to go to bed. bye
[00:18] <bdrung> ari-tczew: you contributed with two (or three) bug reports
[01:53] <pasteeater> siretart: ping
[02:05] <psusi> apw, I have been asking for 6 months now if you are still actively working on bug #380138 that has been assigned to you for 18 months now.  Are you actively working on it or should it no longer be assigned to you?  Upstream has made changes that should finally allow us to drop this problematic patch.
[02:06] <apw> psusi, no it has fallen off my radar
[02:06] <apw> psusi, what upstream changes have been made
[02:07] <psusi> apw, they have implemented a patch that detects whether any partitions would be truncated by the hpa and automatically unlocks the hpa if that is the case, otherwise, does not
[02:07] <apw> psusi, that sounds like it matches what we wanted indeed
[02:08] <apw> psusi, if you can point me to the change i can use that info
[02:08] <psusi> commit d8d9129ea28e2
[02:09] <psusi> looks like it actually went in 2.6.35
[02:09] <apw> psusi, indeed 35-rc2
[02:09] <psusi> yep, it's in the maverick git tree
[02:10] <psusi> man I love git
[02:12] <apw> psusi, thanks for the heads up, sounds like we can drop this patch in natty and see how that pans out
[02:12] <psusi> woohoo, only took a few years ;)
[02:13] <psusi> now if we can just get the ext4 lazy_itable_init issue sorted in time for natty, 20 minute formats with the installer stuck at 5% will be a thing of the past
[02:14] <psusi> I hope ted packages the new e2fsprogs for debian soon so we can merge it
[02:15] <apw> psusi, we are expecting new e2fsprogs in debian shortly
[02:16] <apw> psusi, ok i am now 'active' on that bug ... will get something sorted out tommorrow ... need to get discussion started on it to ensure foundations are happy -- they were not last time we tried to change it
[02:17] <psusi> goody... I've been trying to get that feature turned on by default for a year... will be a boon to people with new tb class drives
[02:18] <apw> psusi, why are tb drives relevant ?
[02:18] <psusi> because they take AGES to format without lazy_itable_init ;)
[02:18] <psusi> and ubiquity just sits there at 5% complete and does not move the whole time.. very bad user experience
[02:18] <apw> ahh
[02:19] <psusi> we also probably want to have ubiquity mount with the option to inhibit the background initialization during installation so it doesn't slow down the install
[02:20] <apw> psusi, thanks for bringing that up
[02:21]  * apw goes back to bed
[02:21] <psusi> o/
[07:05] <ari-tczew> @pilot out
[08:00] <siretart> pasteeater: hi
[08:18] <pitti> cjwatson: python2.6 still is on today's alternate, despite python-apt being fixed; you mentioned that we need to "ask you for alternates", do you manually need to update something there?
[08:19] <pitti> cjwatson: I guess I'll do the 16 rebuilds then, and check if that helps
[09:57] <cjwatson> pitti: I was wrong about having to do something manually - that's only when things are dropped from priority required or important
[09:58] <cjwatson> pitti: python-apt still has the recommends in question, despite a changelog entry saying that it's been dropped
[09:59] <cjwatson> pitti: the rebuilds really should be unimportant for this - just fix python-apt properly :)
[10:00] <cjwatson> (well, they'd let you drop python2.7 from minimal again, yes)
[10:00] <mvo> cjwatson: eh, sounds like I need vacation
[10:01] <mvo> cjwatson: :(
[10:01] <mvo> cjwatson: I have a upload ready to fix a unreleated crash I will drop the recommends in that upload too (for real this time)
[10:04] <mvo> uploaded again
[10:05] <cjwatson> ta
[10:13] <pitti> ah, bummer
[10:13] <pitti> mvo: danke
[10:14] <pitti> mvo: control.in trap?
[10:15] <pitti> bbl
[10:35] <apw> mvo, is there a 'debrelease' command like debcommit for bzr based packages ?
[10:36] <mvo> apw: bzr-buildpackage
[10:36] <apw> mvo, our naming sucks!
[10:36] <apw> (but thanks)
[10:36] <mvo> apw: that is what I use, a lot of package have a .bzr-builddeb/defaults.conf that tell bzr-buildpackage what to do, if not you need to tell it to either "--merge" or "--native"
[10:36] <mvo> apw: otherwise it will not find its data :)
[10:38] <apw> mvo, oh that builds it, i meant is there a command to close the release, RELEASED -> natty, update the name and date on the -- line, commit result, tag result
[10:39] <mvo> apw: I use emacs for that, but others use dch
[10:39] <mvo> so dch -r
[10:44] <apw> mvo, ok so manual commit then ... thanks
[10:52] <mvo> apw: there is debcommit -r that will tag the branch, but iirc it does not change UNRELEASED to $distro
[11:22] <ari-tczew> @pilot in
[11:27] <ari-tczew> could any archive admin look on tor sync? bug 413657
[11:58] <ari-tczew> cdbs: you should know that there is a difference between FTBFS with missing linking and gcc 4.5
[11:59] <ari-tczew> rawstudio/1.2-5ubuntu1 which you uploaded means fix ftbfs with missed links
[11:59] <cdbs> ari-tczew: If you read it clearly, I mentioned: Fixes FTBFS caused due to the new linking behavior in Ubuntu's GCC 4.5
[11:59] <ari-tczew> cdbs: but it's not related to gcc 4.5
[11:59] <cdbs> ari-tczew: it is
[12:00] <ari-tczew> cdbs: for example, it's ftbfs due to gcc 4.5: http://launchpadlibrarian.net/60956184/buildlog_ubuntu-natty-i386.u-boot_2010.12~rc2-1ubuntu1_FAILEDTOBUILD.txt.gz
[12:00] <cdbs> I know what you mean
[12:00] <cdbs> But the linker change is related to GCC 4.5
[12:01] <ari-tczew> odd
[12:01] <cdbs> and I mentioned: FTBFS caused due to the *new* *linking* *behavior* in GCC 4.5 in Ubuntu
[12:01] <ari-tczew> cdbs: I guess that you mean due to new toolchain?
[12:01] <cdbs> of course
[12:02] <ari-tczew> cdbs: so this is not only gcc 4.5
[12:02] <cdbs> new linking behavior -> passing of --no-copy-dt-whatever
[12:02] <ari-tczew> if I'm wrong, show me hard argumentation
[12:02] <cjwatson> it seems entirely unnecessary to nitpick this
[12:02] <cdbs> ari-tczew: Please understand the change before saying. GCC invokes LD
[12:02] <cdbs> and GCC is invoking LD with --no-copy-dt-entries
[12:03] <cdbs> err, its --no-copy-dt-needed-entries
[12:03] <cdbs> so its related to GCC
[12:03] <cjwatson> gcc-4.5 (4.5.0-1) experimental; urgency=low
[12:03] <cjwatson>   * On linux targets always pass --no-add-needed to the linker.
[12:04] <cjwatson> (which is a synonym for --no-copy-dt-needed-entries)
[12:04] <cdbs> and --no-copy-dt-needed-entries is the same as --no-add-needed
[12:04] <cdbs> ari-tczew: I guess I am clear
[12:04] <cdbs> thanks cjwatson for that paste
[12:05] <ari-tczew> cdbs: ok it's also clear for me
[12:09] <Keybuk> cjwatson: sorry I'm late, it was hell getting into work this morning because of the snow
[13:54] <kklimonda> ArneGoetje: wrt to tor - did debian maintainer agreed to take care of it in ubuntu, eventually did we get some motu to get his key into tor project? i can't check the bug but tor has been removed from ubuntu in the past.
[14:06] <Keybuk> 535		event = event_new (NULL, name, (char **)env);
[14:06] <Keybuk> (gdb) p name
[14:06] <Keybuk> $1 = 0x671530 "dbus-activation"
[14:06] <Keybuk> (gdb) p env[0]
[14:06] <Keybuk> $2 = 0x6789e0 "SERVICE=my.test"
[14:07] <Keybuk> \o/
[14:08] <mterry> @pilot in
[14:09]  * dholbach hugs mterry!
[14:09] <mterry> dholbach, :)
[14:10] <Keybuk> ok, silly question time
[14:10] <Keybuk> if there's a debian package using 3.0 quilt
[14:10] <Keybuk> how do I add patches to it?
[14:18] <elmo> Keybuk: quilt new haha.patch ?
[14:18] <Keybuk> elmo: does haha.patch have to be in the working directory or under debian/patches ?
[14:19] <dholbach> edit-patch?
[14:19] <Laney> is that an existing patch?
[14:19] <Keybuk> Laney: they're existing patches, yes
[14:19] <elmo> Keybuk: oh, sorry, right, this mess
[14:19] <Laney> quilt import is what you want then
[14:19] <elmo> Keybuk: you may want to 'export QUILT_PATCHES=debian/patches'
[14:20] <Laney> edit-patch can do this too apparently
[14:20] <elmo> Keybuk: I used http://pkg-perl.alioth.debian.org/howto/quilt.html as a starting point when I was going through the same 'wtf' a while ago, FWIW
[14:31] <Keybuk> File series fully applied, ends at patch debian-changes-1.4.0-0ubuntu2
[14:31] <Keybuk> Patch debian-changes-1.4.0-0ubuntu2 does not remove cleanly (refresh it or enforce with -f)
[14:31] <Keybuk> argh
[14:31] <Keybuk> what does that mean?!
[14:35] <Keybuk> Laney: so, neither of them did the right thing
[14:35] <Keybuk> quilt import didn't apply the patch to the working tree
[14:35] <Keybuk> edit-patch reverted all the debian patches in the working tree
[14:39] <Keybuk> I swear
[14:39] <Keybuk> quilt was invented because some people had got use to the pain of cdbs
[14:39] <Keybuk> and wanted more
[14:41] <ScottK> Keybuk: And like CDBS, eventually you'll get used to it.
[14:41] <ScottK> Eventually you'll criticize people for not enjoying the pain.
[14:42] <ScottK> ;-)
[14:44] <Keybuk> I suspect it's the combination of pain here
[14:44] <Keybuk> the package is actually using CDBS
[14:44] <Keybuk> and quilt
[14:44] <Keybuk> and all imported into bzr using james_w's abandoned stuff
[14:44] <mvo> bdrung: I commited a non-interactive add-patch version of edit-patch, would be nice if you could have a look
[14:44] <janimo> Keybuk: I think that combo is not supported by edit-patch (I fought with thunderbird packaging until I learned that)
[14:45] <bdrung> mvo: i will. thanks in advance
[14:45] <janimo> or actually cdbs tarball.mk + quilt is what caused problems
[14:45] <Keybuk> janimo: this looks like it's relying on dpkg to do the quilting
[14:46] <ScottK> cdbs tarball.mk plus anything is trouble (tarball in tarball using source format 1 is pure pain)
[14:46] <janimo> ScottK: luckily mozilla team say they want to move to quilt 3.0 so that will go away
[14:46] <mvo> bdrung: its only lightly tested and such, feedback welcome
[14:46] <ScottK> janimo: How are they going to support Hardy?
[14:47] <janimo> ScottK: I am not part of the mozilla team, so no idea :)
[14:47] <bdrung> mvo: you are welcome to provide testcases (online/offline). we are currently building a test infrastructure to catch regressions
[14:48] <janimo> Keybuk: I only had a problem with tbird packaging, and remembered I dislike quilt. But on every other package since then edit-patch did the right thing regardless of what the actual patch system
[14:49] <janimo> both quilt 3 and quilt cdbs worked fine
[14:49] <Keybuk> in this case, edit-patch seemed to remove all the patches from the tree
[14:49] <Keybuk> and tried to commit that
[14:50] <Keybuk> when dpkg-source 3 (quilt) in bzr is supposed to have all the patches *applied* at commit time
[14:50] <mvo> bdrung: indeed, that is currently missing
[14:50]  * janimo so far managed to not get into VCS backed patches (or if so edit-patch DTRT)
[14:51] <janimo> Laney: I am trying to build ghc6 locally, and will let you know if I find the issue
[15:19] <bdrung> mvo: add-patch is still interactive
[15:19] <bdrung> mvo: it launches an editor and let's me edit debian/changelog
[15:21] <bdrung> mvo: edit-patch should take bug number to close and should be able to set the target distribution
[15:23] <mvo> bdrung: hm, but it certainly needs some sort of description somewhere for the changelog. or are you happy with a generic "applied patch foo"?
[15:24] <bdrung> mvo: generic would be enough
[15:24] <ScottK> If I saw such a changelog entry in the sponsorship queue I would reject it.
[15:25] <bdrung> ScottK: sponsor-patch allows to edit it afterwards.
[15:26] <ScottK> OK.  Seems odd to me.
[15:26] <ScottK> I've used cdbs-edit-patch and dpatch-edit-patch a lot and never once wanted them to write changelogs for me.
[15:26] <bdrung> one use case would be to grab patches from the reviewers list and test build them or upload to a ppa.
[15:27] <ScottK> Is this non-interactive mode a non-default option then?
[15:27] <cdbs> master?
[15:27] <bdrung> ScottK: should be
[15:27] <cdbs> BTW, I never understood what edit-patch does (I mean the script in u-d-t). Why use it when you can use cdbs-edit-patch and dpatch-edit-patch?
[15:27] <cdbs> sorry for writing that 'master'. Don't know how it came
[15:27] <ScottK> cdbs: What if the pacakge uses quilt?
[15:27] <ScottK> IIRC the point of edit-patch is not having to care what patch system is in use.
[15:28] <cdbs> ScottK: is edit-patch for quilt?
[15:28] <cdbs> okay
[15:28]  * ScottK would hope it includes support for it.
[15:28] <bdrung> cdbs: edit-patch supports all patch systems
[15:28] <cdbs> I guess it writes changelog and stuff? and it has bzr support?
[15:35] <apw> doko_, you suggest conditionalising packaging on the release, is there an approved way to do that?
[15:36] <ScottK> wendar: I'm catching up on the backscroll and have a comment on your last ARB meeting: I would really prefer you don't choose to use ubuntu in the revision number for ARB apps.
[15:38] <doko_> apw: well, I don't know. usually you have to rely on output of lsb_release, and have a rule to regenerate the control file (for the change of b-d's)
[15:38] <apw> doko_, ick, ok thanks
[16:07] <wendar> ScottK: well, the apps are packaged for ubuntu, which is all that line means
[16:07] <ScottK> wendar: Except that extras is not part of Ubuntu.
[16:07] <wendar> ScottK: they'll still say "maverick" on that line too
[16:08] <wendar> ScottK: extras run on Ubuntu
[16:08] <ScottK> Why not just use $RELEASE.
[16:08] <wendar> ScottK: one of the developers did, but it's entirely non-standard
[16:09] <wendar> ScottK: we can certainly change the standard, but it needs to be a decision by a much larger group than the ARB
[16:09] <ScottK> wendar: There's a standard?
[16:09] <wendar> ScottK: so we'll stick with the current standard for now
[16:09]  * ScottK thought the current situtation was no defined standard?
[16:10] <ScottK> wendar: Where is this standard?
[16:10] <wendar> ScottK: in the ubuntu packaging guide
[16:10] <ScottK> wendar: That's the standard for Ubuntu packages.  These aren't Ubuntu packages.
[16:11] <ScottK> (and technically the standard is ubuntu-policy - the packaging guide just describes the policy)
[16:13] <wendar> ScottK: to be precise, they aren't "packages that make the core OS" they're "packages that run on the core OS"
[16:14] <wendar> ScottK: but they aren't Debian/Fedora/SuSE packages
[16:14] <ScottK> They equally aren't Ubuntu packages.
[16:15] <wendar> ScottK: we have main, universe, multiverse, and now extras, that has so far been taken as enough of a measure of how much support the Ubuntu community gives a package
[16:15] <wendar> ScottK: why add an additional linguistic marker?
[16:15] <directhex> precision is important
[16:16] <wendar> ScottK: the 0ubuntu1 means "this package was customized to run on the Ubuntu OS"
[16:16] <ScottK> wendar: Why make a choice the adds confusion?
[16:16] <ScottK> No.  It means it's part of Ubuntu.
[16:16] <ScottK> You are proposing to change what that means.
[16:17] <wendar> ScottK: we have packages with out 0ubuntu1 that are part of Ubuntu
[16:17] <ScottK> That's true, but irrelevant.
[16:17] <ScottK> The fact that all XubuntuY packages are part of Ubuntu doesn't mean that all packages that are part of Ubuntu are XubuntuY
[16:18] <wendar> ScottK: I'm a linguist, and it's very important to me to get at the deep semantic and cultural meaning of a symbol or word
[16:19] <apw> marjo, remind me of the bug number
[16:19] <Chipzz> wendar: pretty ironic a linguist spells without in 2 words ;)
[16:19] <marjo> apw: https://bugs.launchpad.net/bugs/693093
[16:20] <wendar> Chipzz: I'm a linguist on a mission, and spending most of these few minutes scanning through documentation for signs of deeper semantic and cultural meaning of 0ubuntu1
[16:20] <wendar> Chipzz: :)
[16:21] <apw> marjo, well that doesn't make sense as installing -10 doesn't change the older kernels and you are saying they have changed too
[16:21] <apw> marjo, that would imply it is a different component which has changed which is contributing
[16:21] <Chipzz> what deeper meaning do you expect? it's a version number, it has no semantic meaning
[16:21] <Chipzz> a version number purely exists to order packages in a timely fashion
[16:22] <Chipzz> ie to allow upgrades to happen correctly
[16:22] <marjo> apw: i tend to agree, but I don't know what else to try; all i know is that -9 used to work fine (gets to login and supported high resolution)
[16:22] <apw> marjo, and the fact that booting -9 does not implies it is something other than the kernel which is spacked
[16:24] <wendar> ScottK: can't find the page I'm looking for on why that naming convention was originally introduced (it might not exist anymore). I have a strong opinion to hold to existing standards until there's a compelling reason to change, but essentially, the ARB will do whatever the TB decides on it.
[16:25] <ScottK> wendar: I disagree that there is an existing standard for this.
[16:25] <apw> marjo, you may as well try updating to the -11 kernel and re-testing
[16:25] <Chipzz> wendar: to put it bluntly, your mission is bullshit. even if the proposal would have merit (which it doesn't (IMO)), the version number matters because computers order strings in a specific way, and 0ubuntu1 comes after 0, which is important because ubuntu packages should override debian packages
[16:25] <marjo> apw: will do
[16:26] <Chipzz> wendar: I think that alone is enough argument to put an end to this discussion
[16:26] <wendar> wendar: okay, then rephrase that to just "I have a strong opinion", but I do think this is something to be decided by the TB, and not by a small new group
[16:26] <wendar> (hmmm... talking to myself now?)
[16:26] <ScottK> wendar: I'm fine with the TB deciding.  I think the current correct behavior is undefined.
[16:27] <Chipzz> wendar: there IS nothing to decide. your proposal would break ubuntu, period
[16:27] <ScottK> Chipzz: No.  It wouldn't.
[16:27] <wendar> ScottK: we're deciding on a new standard that has the potential to last for 20 years or so
[16:27] <Chipzz> ScottK: as I understand it he wants to do away with ubuntu version numbers
[16:27] <ScottK> Chipzz: No.  She doesn't.
[16:27] <wendar> Chipzz: it wouldn't break anything, I just want to use exactly what we're using now
[16:28] <ScottK> wendar: There is no "What we're using now".  extras is new.
[16:29] <Chipzz> ScottK: then I misunderstood the discussion, my apologies
[16:29] <apw> marjo, we need you in #ubuntu-x
[16:29] <wendar> Chipzz: I want to use 2.0-0ubuntu1 and ScottK wants to use something else, maybe 2.0-0extras1
[16:29] <ScottK> Chipzz: I don't think I'm the one you need to apologize to.
[16:30] <wendar> Chipzz: (we need to figure out what the something else would be, which is one of the reasons to take it to the TB)
[16:30] <ScottK> wendar: I'd even be happy with -0$RELEASE1 since these approvals are tied to a specific release.
[16:31] <Chipzz> wendar: ah ok, I understood the discussion as you wanting to eliminate 0ubuntu1 because it made no semantical sense
[16:31] <wendar> Chipzz: then your frustration is understandable :) I actually think it makes perfect sense, and want to keep using it.
[16:31] <ebroder> ScottK, wendar: Why not something like -0ubuntu0extras1?
[16:32] <wendar> ebroder: that has good potential
[16:32] <wendar> ebroder: or -0ubuntu0~extras1 like with PPAs
[16:32] <Chipzz> looks too complex to me
[16:32] <ebroder> That indicates to me that we would prefer to get these packages into the archive, at which point they'd supercede the packages in extras, which all seems more or less desirable
[16:33] <ebroder> wendar: I would probably use -0ubuntu1~extras1 if you went the tilde route
[16:33] <Chipzz> wendar: ~ has a specific meaning in versions, though I'm not sure if it's only at the start of a version or also anywhere else
[16:34] <ScottK> ebroder: It should not contain the string "ubuntu".
[16:34] <bdrung> ebroder: -0ubuntu0extras1 is more consistent
[16:34] <wendar> ebroder: and, it solves a problem too, if we treat it the same as PPAs, because it means the first universe release after the 'extras' release would always be considered "more recent" than the extras release
[16:34] <ScottK> Chipzz: It's anywhere.
[16:35] <wendar> ScottK: that basically comes down to what that instance of "ubuntu" means, a noun in isolation is tremendously ambiguious
[16:36] <apw> marjo, hey ... lots of dicsussion on #ubuntu-x
[16:36] <marjo> apw: having xchat problems
[16:37]  * apw wonders how you get to #ubuntu-meeting
[16:37] <marjo> apw: auto-connect
[16:37] <apw> add ubuntu-x to that, and restart it perhaps?
[16:38] <marjo> apw: there now
[16:38] <marjo> apw: as marjo_
[16:38] <Chipzz> ebroder: my 2c (FWIW), things like -0ubuntu0extras1 look too complex to me, and would likely cause confusion
[16:39] <bdrung> -0extras1 would be enough (less that -1 and -0ubuntu1)
[16:39] <ScottK> wendar: That's true and the core of my objection.  I don't think it's possible to succesfully encode the distinction between in Ubuntu and on Ubuntu into the revision number, so I'd like for Ubuntu to be avoided entirely.
[16:39] <bdrung> s/that/than/
[16:39] <Chipzz> sth you may want to avoid for MOTU's for example, as those ppl are often beginners, and they may struggle enough as is
[16:40] <wendar> Chipzz: that's good feedback
[16:40] <wendar> ScottK: I'll bundle the discussion up in an email for the TB. Doesn't necessarily need a meeting agenda item or a vote, but at least their thoughts.
[16:41] <Chipzz> wendar: sounds to me like you want input from the debian ppl too
[16:41] <ScottK> OK.
[16:42] <ebroder> wendar: Am I assuming correctly that it's desirable in the long-term for apps to move from extras into the archive?
[16:43] <Chipzz> sth which may be better is 0ubuntuextra1 (or 0ubuntu-extra1)
[16:44] <Chipzz> 0ubuntuextra1 would still be higher than 0ubuntu1
[16:44] <Chipzz> but only 2 numbers instead of 3
[16:45] <ebroder> Chipzz: I'm suggesting -0ubuntu0extras1 because I see it as being analogous to numbering packages -0ubuntu1 that are in Ubuntu but not yet in Debian
[16:46] <Chipzz> ebroder: yes, but then you have 3 numbers in one version string...
[16:46] <bdrung> dholbach: why does ubuntu-dev-tools depends on binutils?
[16:46] <dholbach> bdrung, I have no idea
[16:47] <dholbach> bdrung, ahhh - because of "nm"?
[16:47] <bdrung> dholbach: where is it used?
[16:47] <dholbach> check-symbols
[16:47] <ebroder> Chipzz: Sure, but it's not like you don't run into the same sorts of issues for SRUs, backports, etc.
[16:47] <Chipzz> ebroder: yes, but those happen only on an occasional basis, not on a regular one
[16:48] <Chipzz> ebroder: and I think ppl find those to be too complex in SRU's too
[16:48] <bdrung> dholbach: thanks
[16:50] <ebroder> Chipzz: I don't think that makes them any less useful as indicators of the package's lineage
[17:06] <apw> jhunt, what was the incantation to upstart to get more debug, was it --debug ?
[17:19] <Keybuk> apw: --debug --debug --moar-debug
[17:19] <Keybuk> (note, only the first one required)
[17:49] <apw> jhunt, what does "init: event_net: Pending started event" mean
[17:50] <apw> as the last bit of --debug
[17:50] <Keybuk> event_new you mean
[17:51] <apw> yes _new
[17:51] <apw> sorry going a bit mad
[17:51] <Keybuk> means that a job has started
[17:51] <Keybuk> though helpfully it doesn't say which, you need to look a line or two up for that
[17:51] <apw> Keybuk, so its not in the middle, its complete
[17:51] <Keybuk> right, that means the process has been exec'd and suff
[17:52] <apw> something very screwey goiing on in my worls
[17:52] <apw> world
[17:56] <janimo> cjwatson: hello, can you please add me (jani @ ubuntu.com ) to the list of addresses notified when anything significant happens to arm image builds. thanks.
[17:57] <Keybuk> there are such addresses?
[17:57] <janimo> Keybuk: so I was told in #arm
[17:58] <ScottK> You can get ISO build failure notifications.
[17:58] <janimo> it may not be a mailing list, but apparently ogra & other arm devs are notified
[18:09] <Keybuk> neat
[18:13] <kees> Keybuk, jhunt: so, should I upload the ubuntu1 debdiff for upstart to gain the apparmor helper, or should I wait for it to be included in the next release? (when is the next release?)
[18:14] <zyga> Keybuk, hi, dbus activation support is quite cool
[18:14] <Keybuk> kees: if you upload a debdiff it should be -2
[18:14] <zyga> Keybuk, I posted a comment about the implementation but darn moderation will probably make it past xmas to deliver
[18:14] <kees> Keybuk: what's needed to get the change into the right vcs tree?
[18:15] <zyga> Keybuk, could you by any chance reuse the Exec= from .service file not to have to specify the same thing twice?
[18:15] <Keybuk> kees: uploading should do it
[18:15] <apw> Keybuk, any idea what was in the latest udev upload ?
[18:15] <Keybuk> zyga: I thought about adding it to the environment, but decided it would probably limit things
[18:15] <Keybuk> apw: none, pitti does those
[18:15] <zyga> Keybuk, not adding that to environment, just not having to specify it in a job file
[18:16] <ebroder> Keybuk: Do you still need to specify Exec and User in the .service file? Does D-Bus barf without those?
[18:16] <vanhoof> apw: some changes for new dell chassis support
[18:16] <Keybuk> zyga: then upstart would have to parse dbus service files, and then there's the whole mess of them being out-of-sync with each other, etc.
[18:16] <Keybuk> ebroder: no idea
[18:16] <zyga> Keybuk, yeah but you trade _development_ problem for _administration_ problem. They are going to get out of sync because you require two definitions. I argue to make just one definition in the .service file
[18:17] <Keybuk> zyga: if you want to support that though, go ahead
[18:17] <Keybuk> because it shouldn't be that hard to add an additional config parser to upstart
[18:17] <Keybuk> you could have upstart parse /usr/share/dbus-1/system-services, make Jobs out of them, etc.
[18:17] <Keybuk> I'll happily accept that patch
[18:17] <Keybuk>     ^
[18:17] <Keybuk> more then
[18:17] <zyga> Keybuk, do you have a separate non-copyright-assigned tree now or is that to the canonical treE?
[18:18] <Keybuk> zyga: I work for Canonical, so there is only the Canonical tree
[18:19] <zyga> Keybuk, that's another topic, so what's the point of having upstart file if we can (eventually) parse dbus service files?
[18:19] <Keybuk> zyga: well, there are lots of services that aren't dbus ;-)
[18:20] <zyga> Keybuk, is the upstartjob=y marker used by dbus _not_  to start that on activation and expect upstart to pick it up?
[18:20] <Keybuk> and in theory, dbus-daemon goes away
[18:20] <Keybuk> so the dbus service files will be the short-lived ones
[18:20] <zyga> Keybuk, mmm, interesting, what about handling of routed messages?
[18:20] <Keybuk> zyga: no, UpstartJob=y is used by D-Bus to replace the existing activation code with a D-Bus message to Upstart
[18:20] <Keybuk> zyga: multicast AF_UNIX
[18:21] <zyga> Keybuk, right, that's what I had on my mind, "delegate task to upstart"
[18:21] <zyga> Keybuk, so if we had the parser for .service files could we assume upstartjob=y always?
[18:21] <ebroder> zyga: There was a proof-of-concept a while back for an AF_DBUS :)
[18:21] <Keybuk> if the AF_UNIX multicast stuff gets accepted, then I'd expect to see
[18:21] <kees> Keybuk: FAIL: test_job_process
[18:21] <zyga> ebroder, yeah
[18:21] <kees> ^^ that test fails
[18:21] <Keybuk>  - dbus services bind to AF_UNIX with their well known name
[18:21] <zyga> ebroder, but it did not remove the daemon
[18:21] <Keybuk>  - dbus services listen on the multicast socket too
[18:21] <zyga> ebroder, it just made the actual talk more efficient
[18:21] <cjwatson> janimo: mail me, please, I'm not sitting somewhere where I can make that change right now
[18:21] <Keybuk> for activated services
[18:21] <Keybuk>  - init binds to AF_UNIX with the well known name
[18:22] <Keybuk>  - on message, activates the service and passes the socket
[18:22] <Keybuk> (ie. basically socket activation)
[18:22] <Keybuk> in both cases, you'd only have files in /etc/init
[18:22] <ebroder> zyga: I thought the proof-of-concept only used the dbus-daemon for the org.freedesktop.DBus stuff
[18:22] <zyga> ebroder, and for activation and for non-peer-to-peer messages
[18:23] <zyga> (I could be wrong on the last one)
[18:23] <Keybuk> kees: -v
[18:23] <ebroder> zyga: Oh, really? Well that's pointless :-P
[18:23] <Keybuk> ebroder: the new stuff is multicast AF_UNIX
[18:23] <cjwatson> wendar: here's the semantic of "ubuntu" in version numbers: it means "do not autosync this package from Debian"
[18:23] <cjwatson> wendar: that's its total meaning
[18:23] <zyga> Keybuk, that makes sense except for one thing - transition period - dbus has been around long enough so we have lots of .service files for dbus activation, do you think we should require to transition them to upstart jobs?
[18:24] <kees> Keybuk: I can't build upstart on natty, I get a failed testcase:
[18:24] <kees> test_job_process: tests/test_job_process.c:3740: test_handler: Assertion `(waitid (P_PID, pid, &info, 2 | 0x01000000)) == 0' failed.
[18:24] <kees> /bin/bash: line 5: 11151 Aborted                 (core dumped) ${dir}$tst
[18:24] <kees> FAIL: test_job_process
[18:24] <Keybuk> zyga: right, that's what I thought -- it seemed most sensible to do it as a transition thing
[18:24] <Keybuk> and to cover the overlap for when older kernels need dbus-daemon
[18:24] <Keybuk> while newer kernels don't
[18:24] <Keybuk> which is why I did it entirely as "have special handling in dbus-daemon"
[18:24] <Keybuk> rather than having any patch to upstart
[18:25] <zyga> ebroder, AF_DBUS patch did improve performance and removed the bottleneck that is the daemon for normal communication, I never used it just remember reading about it
[18:25] <Keybuk> kees: you're still not telling me which test case failed here ;-)
[18:25] <wendar> cjwatson: Makes sense. Seems like that would apply to the extras packages as much as any other.
[18:25] <zyga> Keybuk, I think it's still more sensible to keep .service files as is and let upstream be happy about not having to worry about upstart, upstart+1, sysinit or other stuff like systemd,
[18:26] <cjwatson> wendar: extras is never autosynced
[18:26] <zyga> Keybuk, it adds extra cruft but IMHO it's the best political decision
[18:26] <wendar> cjwatson: Though, with the /opt install, we'll always be modifying the packages.
[18:26] <Keybuk> zyga: I would have agreed, except Upstream already committed patches to add systemd support
[18:26] <cjwatson> autosyncing is just for the Ubuntu archive
[18:26] <Keybuk> so I followed the guide of those patches
[18:26] <zyga> Keybuk, we swap the implementation, not the interface for activation
[18:26] <kees> Keybuk: oh, "test_job_process" isn't it?
[18:26] <kees> Testing job_process_handler()
[18:26] <kees> ...
[18:26] <kees> ...with stopped main process but wrong signal
[18:26] <Keybuk> kees: no, test_job_process is about 1,000 test cases ;-)
[18:26] <zyga> Keybuk, upstream dbus?
[18:26] <wendar> cjwatson: Would you be comfortable with no modifier?
[18:26] <Keybuk> zyga: aye
[18:26] <Keybuk> kees: hmm, ok - can you check the core dump to see what assertion failed
[18:26] <wendar> cjwatson: i.e. 2.0-1?
[18:26] <zyga> Keybuk, I was referring to upstream projects shipping .service files, dbus is another topic where I agree with you
[18:26] <cjwatson> wendar: sure, it certainly wouldn't break anything and it seems simpler
[18:26] <Keybuk> kees: you may have found a kernel bug
[18:27] <Keybuk> zyga: well, the reason for doing this patch now
[18:27] <Keybuk> (we've never found it urgent until now)
[18:27] <cjwatson> we do that for some Ubuntu-specific packages, even
[18:27] <Keybuk> was to cover the base of upstream projects adding systemd support
[18:27] <Keybuk> and expecting you to activate it that way
[18:27] <kees> Keybuk: this assertion:
[18:27] <kees> test_job_process: tests/test_job_process.c:3740: test_handler: Assertion `(waitid (P_PID, pid, &info, 2 | 0x01000000)) == 0' failed.
[18:27] <Keybuk> this gives us an upstart answer
[18:27] <wendar> cjwatson: okay, cool, thanks
[18:27] <Keybuk> kees: yeah, looking at the code, you found a kernel bug
[18:27] <zyga> Keybuk, right, that's a sensible first step
[18:27] <apw> something seems to be wrong with something in our initramfs in natty
[18:27] <kees> Keybuk: \o/
[18:27] <zyga> Keybuk, I'm more probing you on the follow-up you'd like to see
[18:28] <apw> i have a bad -11 kernel, i regenerated my -10 initramfs and it is also sick now
[18:28] <Keybuk> kees: because that assertion is asserting that a child paused by SIGTSTP causes wait() to report WSTOPPED
[18:28] <Keybuk> zyga: I don't expect to see a mass conversion of system services from dbus to upstart
[18:28] <Keybuk> in fact, I don't really expect to see any
[18:29] <wendar> cjwatson: will drop a note to the TB for "chance to comment", but will go with the simple option unless anything else come up
[18:29] <zyga> Keybuk, I was asking about the next step for upstart implementation
[18:29] <Keybuk> but next time someone says "we have to use systemd because d-bus uses it for service activation" the answer is "no, upstart can do d-bus service activation too"
[18:29] <zyga> Keybuk, if we can make all dbus services activated by upstart implicitly
[18:29] <Keybuk> zyga: i'm not sure that needs an upstart patch
[18:29] <zyga> hmm
[18:29] <Keybuk> one could patch d-bus so that rather than read in .service files, it just unconditionally emits the dbus-activation event
[18:29] <zyga> btw
[18:29] <Keybuk> I considered that
[18:30] <zyga> why didn't you just patch dbus
[18:30] <Keybuk> I did just patch dbus
[18:30] <zyga> Keybuk, to actually send you job details upon activation
[18:30] <zyga> Keybuk, no parsin needed,
[18:30] <Keybuk> zyga: that's what I said earlier
[18:30] <zyga> Keybuk, you already have an API for that
[18:30] <zyga> Keybuk, hmm? I must have missed that somehow
[18:30] <ebroder> Keybuk: Does the systemd integration basically work the same way as upstart? Setting the flag -> D-Bus doesn't start the service itself?
 zyga: I thought about adding it to the environment, but decided it would probably limit things
[18:30] <Keybuk> ebroder: right
[18:30] <apw> cjwatson, who other than you (ie someone who is arround) would be a good person to help diagnose an early boot failure, likely something in initramfs
[18:30] <ebroder> Ugh. That seems like a terrible design
[18:31] <zyga> Keybuk, but why not activate _all_ jobs like that? No UpstartYob=y no extra upstart file
[18:31] <Keybuk> ebroder: setting the flag means d-bus emits a signal that systemd listens to
[18:31] <zyga> just pure dbus service that always gets activated by patched dbus sending message (as you currently do) to upstart
[18:31] <Keybuk> likewise setting the upstart flag means d-bus makes a method call to upstart
[18:31] <Keybuk> zyga: because it changes the behaviour of d-bus
[18:31] <zyga> Keybuk, in what way?
[18:31] <ebroder> Keybuk: Right. But since there are more init daemons than D-Bus daemons, I can't see why D-Bus needs to buy into the init daemons instead of the other way around
[18:31] <Keybuk> zyga: right now, if you send a method call to an un-named service
[18:31] <Keybuk> for which there isn't a .service
[18:31] <Keybuk> the method call returns an error immediately
[18:32] <zyga> right
[18:32] <Keybuk> to have d-bus unconditionally activate would mean all such methods would timeout instead
[18:32] <Keybuk> (activate via upstart)
[18:32] <tseliot> cjwatson: are you around?
[18:32] <zyga> Keybuk, hmm why?
[18:32] <Keybuk> ebroder: because the init daemons are "higher up" the stack
[18:32] <zyga> Keybuk, dbus would not activate that blindly
[18:32] <cjwatson> wendar: ok, sounds good
[18:32] <zyga> Keybuk, just check if the service exists, (it already does that)
[18:32] <Keybuk> zyga: you just asked why dbus doesn't activate blindly
[18:32] <Keybuk> right
[18:32] <Keybuk> if the service exists, dbus will activate it
[18:32] <zyga> Keybuk, and pass the sole activation step (with all the details) to upstart
[18:33] <Keybuk> because then all existing services would immediately break
[18:33] <Keybuk> because there wouldn't be upstart jobs for them
[18:33] <tseliot> cjwatson: is it ok if a blacklist in /usr/share/grub-gfxpayload-lists/blacklist/ is a symlink to the actual blacklist file?
[18:33] <zyga> Keybuk, no - I asked (earlier) why don't we just forward all activation requests to upstart. Why do we need the upstartjob=y flag?
[18:33] <Keybuk> zyga: right
[18:34] <Keybuk> because then you'd have to write upstart job files for them *quickly*
[18:34] <Keybuk> if d-bus ignored the .service file
[18:34] <Keybuk> and there wasn't an upstart job for it yet
[18:34] <cjwatson> apw: try Surbhi perhaps
[18:34] <Keybuk> it would break
[18:34] <Keybuk> that's what the flag is for
[18:34] <cjwatson> tseliot: not in front of the code right now but IIRC it just cats them together
[18:34] <Keybuk> the flag means "this one has been converted"
[18:34] <Keybuk> the contents of the .service file are there for backwards compatibility
[18:34] <cjwatson> tseliot: check the implementation but it should be ok
[18:34] <zyga> Keybuk, why would you have to write upstart jobs? I don't want to patch dbus to ignore it's own service files. I just want it to send the details about the service to upstart when it decides that given service should be activated
[18:35] <zyga> Keybuk, after parsing the actual service file and getting stuff like Exec out of it
[18:35] <Keybuk> zyga: how would that help?
[18:35] <zyga> Keybuk, less administration
[18:35] <zyga> Keybuk, one file to maintian
[18:35] <Keybuk> then you wouldn't be able to customise any of the jobs
[18:35] <Keybuk> less administration is not necessarily a good thing
[18:35] <zyga> Keybuk, zero files to patch
[18:35] <zyga> Keybuk, yes but that's another step
[18:35] <Keybuk> no, there's no gain to that
[18:35] <Keybuk> just having d-bus get upstart to do the job it's already doing is zero benefit
[18:35] <zyga> Keybuk, getting jobs activated via upstart per se would just be a transparent improvement of the implementation
[18:36] <Keybuk> no, it would be a transparent *movement* of the implementation
[18:36] <zyga> Keybuk, you gain uniformity
[18:36] <Keybuk> no you don't
[18:36] <Keybuk> because the d-bus activation wouldn't be uniform with the rest of the upstart systme
[18:36] <zyga> Keybuk, you already added the implementation, right? there are two ways to activate dbus services now, via upstart and via dbus
[18:36] <Keybuk> all dbus activation would be done by a single .conf file
[18:36] <elif> Hey guys I'm a bit confused since I'm trying to use preseed, I read the ubuntu-installer is ubiquity, but I donwloaded the ubuntu 10.10 server, x6-64 and I don't see the ubiquity there, instead just the debian installer, so automatic-ubiquity kernel parameter does nothing... is this right (no ubiquity as installer) ?
[18:36] <tseliot> cjwatson: yes, it's correct. I've just found what you put on pastebin: http://paste.ubuntu.com/544450/
[18:36] <Keybuk> zyga: three, actually
[18:36] <Keybuk> but yes
[18:36] <Keybuk> the existing implementation had two days
[18:36] <Keybuk> I added a third
[18:37] <Keybuk> two ways
[18:37] <cjwatson> elif: the desktop (graphical) installer is ubiquity.  the text installer is a modified version of debian-installer.
[18:37] <zyga> Keybuk, so why not unify that to one (via upstart) on ubuntu? Am I missing something?
[18:37] <zyga> (apart from the actual extra work required)
[18:37] <Keybuk> on receiving a message for a destination not connected to the bus, the D-Bus Daemon performs an Activation
[18:37] <Keybuk> the process for that, in the upstream code:
[18:37] <Keybuk>  - look-up and parse a .service file
[18:38] <zyga> when/if someone wants to use upstart interface they just stop shipping .service file for dbus and ship an upstart job instead
[18:38] <Keybuk>  - if the service has SystemdService=..., invoke systemd to do it
[18:38] <zyga> uh :-)
[18:38] <zyga> right, third
[18:38] <Keybuk>  - otherwise, do it by hand using Exec
[18:38] <Keybuk> I added an intermediate step
[18:38] <cjwatson> elif: just use file= or url= as appropriate to point to the preseed file - see the installation-guide
[18:38] <Keybuk>  - if the service has UpstartJob=y, invoke upstart to do it
[18:38] <Keybuk> so basically I implemented it uniformly with the existing D-Bus upstream code
[18:38] <Keybuk> now
[18:38] <Keybuk> I could have done it differently
[18:39] <Keybuk> I could have said
[18:39] <Keybuk> - if the bus is being activated via Upstart
[18:39] <Keybuk> - punt ALL activation requests (whether .service or no) to Upstart
[18:39] <zyga> right
[18:39] <Keybuk> this would have had the following effect:
[18:39] <Keybuk>  - broken all existing services
[18:39]  * zyga remembers your post about not replacing dbus years ago ;-)
[18:39] <Keybuk>  - changed the behaviour of d-bus for *NON* activated services
[18:39] <Keybuk>  - made a big patch upstream would have cried about
[18:39] <Keybuk> so that's bad
[18:40] <Keybuk> even though it might be ultimately better
[18:40] <zyga> hmm, this is the part I dont understand
[18:40] <zyga> (I'm not dbus expert so please bear with me if you can)
[18:40] <zyga> how is the method you implemented now (delegation of the activation process to upstart for selected jobs) not breaking them the way you described above?
[18:40] <kees> Keybuk: bug 693510 filed
[18:41] <Keybuk> zyga: because it's done via a flag
[18:41] <zyga> imagine if _each_ job had useupstart=y and an appropriate (generated) upstart job file
[18:41] <elif> cjwatson, I'm writing preseed.cfg and packing it with the initrd, it works, but in mirror selecting part it always keep me asking to choose a mirror, I check what question name it was, I found it was "debian-installer/choose-mirror/title", of type Text, but no matter what I do it keeps asking me this question
[18:41] <Keybuk> so it only changes the behaviour of an ACTIVATED service
[18:41] <zyga> what would change then?
[18:41] <Keybuk> and only an activated service THAT HAS BEEN MODIFIED
[18:41] <zyga> hmm?
[18:41]  * zyga should reread your message perhaps
[18:41] <Keybuk> upstart doesn't autogenerate job files
[18:41] <Keybuk> so
[18:41] <Keybuk> right
[18:41] <Keybuk> there's a third option
[18:41] <Keybuk>  - if no .service is present, fail
[18:41] <cjwatson> elif: that's certainly not the question name being asked
[18:41] <Keybuk>  - if a .service is present, parse it
[18:41] <zyga> (I know it does not - I was putting a theory on what would change in such scenario)
[18:41] <Keybuk>  - send all information over to upstart so upstart can run it
[18:42] <Keybuk> but honestly, that buys us nothing
[18:42] <elif> cjwatson, it display the list with the answer provided in "mirror/http/hostname"
[18:42] <Keybuk> we wouldn't be able to customise each job indepedantly
[18:42] <zyga> Keybuk, what you just described is what I was generally arguing for the whole time
[18:42] <Keybuk> we would still need to create a file in one place to have it run by a system configured in another
[18:42] <Keybuk> right, and that's idioitic
[18:42] <Keybuk> it has zero benefit
[18:42] <Keybuk> and just complicates matters further
[18:42] <zyga> no wait
[18:42] <Keybuk> consider
[18:42] <zyga> there's something not right here: why would you need to create another file?
[18:42] <Keybuk> listen
[18:42] <elif> cjwatson, do you have a sugestion of the question name ?
[18:43] <cjwatson> elif: if you're setting hostname and directory, did you set (iirc) 'd-i mirror/http/country string manual'?
[18:43] <Keybuk> so, we want to create a new service to be system-bus activated
[18:43] <zyga> if you send _all_ the description required by upstart to start the new job why would you need to add a upstart job file (unless I mistake something)
[18:43] <Keybuk> we would *have* to create a file in /usr/share/dbus-1/system-services
[18:43] <zyga> right
[18:43] <Keybuk> to configure Upstart
[18:43] <apw> anyone know if pitti is about?
[18:43] <Keybuk> that's confusing in of itself
[18:43] <Keybuk> that file is parsed by D-Bus
[18:43] <zyga> right
[18:43] <apw> Keybuk, cjwatson, i believe that the current udev in the archive is bad
[18:43] <cjwatson> elif: I'm ircing from a phone right now, I can't check all the facts.  if you're stuck feel free to mail your preseed.cfg and your installer syslog to<EMAIL_ADDRESS>and I'll look when it's more convenient
[18:43] <Keybuk> so it can have *NONE* of the features of Upstart that D-Bus doesn't know about
[18:44] <zyga> right
[18:44] <Keybuk> so you gain zero benefit from Upstart
[18:44] <zyga> right
[18:44] <elif> cjwatson, oh thks.
[18:44] <zyga> I agree with everything you said
[18:44] <Keybuk> so, all you've done there is move the supervising from d-bus to upstart
[18:44] <Keybuk> for a benefit of zero
[18:44] <Keybuk> at a cost of increased complexity
[18:44] <zyga> that depends on the viewpoint but I agree
[18:44] <zyga> what you did not do is also important
[18:45] <zyga> you made the activation uniform, there is no heisenbug that sometimes kicks in when service gets activated by upstart
[18:45] <zyga> you made this process transparent to anyone who now today ships a .service file for upstart
[18:45] <zyga> and provided a clear upgrade path to upstart features
[18:45] <zyga> now
[18:45] <zyga> compare that to current situation
[18:45] <Keybuk> apw: oh, wow, someone uploaded 165 - I took one look at those release notes and backed away
[18:45] <zyga> if you want to use upstart then shipping service file is mostly useless
[18:45] <Keybuk> zyga: correct
[18:45] <zyga> except for the flag that you need to add
[18:46] <Keybuk> zyga: except services are shipped by upstreams
[18:46] <zyga> and the (probably unused) Exec line
[18:46] <Keybuk> so this allows an upstream to ship a service file for sysvinit distros
[18:46] <Keybuk> a systemd unit for systemd distros
[18:46] <ari-tczew> cjwatson: are you not afraid to write full mail address here? (spam case)
[18:46] <zyga> and on top of that you need to create an upstart job file for the actual gory details of what you want to do
[18:46] <Keybuk> and an upstart job for upstart distros
[18:46] <cjwatson> ari-tczew: no
[18:46] <zyga> Keybuk, yeah and IMHO upstreams will hate that
[18:46] <apw> ari-tczew, his email is so well known he cannot make it any more on spam  lists than it already is
[18:46] <zyga> Keybuk, they were happy with .service for dbus
[18:46] <Keybuk> zyga: of course they will
[18:47] <Keybuk> like I said, I expect no services to be migrated ;-)
[18:47] <zyga> Keybuk, few will want to get the extra features that upstart and systemd offer
[18:47] <Keybuk> not until dbus-daemon goes away, anyway
[18:47] <zyga> Keybuk, actually having _not_to_ do this for upstart would be an improvement over systemd
[18:47] <zyga> Keybuk, you essentially invent a new interface for no gain
[18:47] <Keybuk> zyga: *except* these patches have to be accepted by D-Bus upstream
[18:47] <Keybuk> we can't go around cowboying the universe
[18:47] <zyga> Keybuk, hmm
[18:47] <Keybuk> (yeehaw!)
[18:48] <Keybuk> so look at this instead from a "next year" POV
[18:48] <Keybuk> let's say Collabora's patches to add multicast AF_UNIX are accepted into the kernel
[18:48] <Keybuk> D-Bus communication can now be implemented entirely without an intermediary daemon
[18:48] <Keybuk> except for Activation
[18:48] <Keybuk> but this is only true for newer kernels
[18:49] <Keybuk> so you need to have a dbus-daemon around for older kernels
[18:49] <zyga> Keybuk, so next year everyone will stop shipping .service files for older distros? Either upstart job or system unit?
[18:49] <ebroder> Keybuk: Isn't there a problem that Upstart supports doing more things in its conf file than D-Bus does? Same with systemd? So either an application only writes in its Upstart conf file what it can do in pure D-Bus (in which case why not just get the configuration from the normal D-Bus location), or it drops support for pure D-Bus without systemd or Upstart (which would be lame on the app's part)
[18:49] <Keybuk> zyga: you got it ;-)
[18:49] <zyga> Keybuk, that's what I don't like
[18:49] <Keybuk> ebroder: initially, but only for an LTS cycle or so
[18:49] <zyga> Keybuk, I like the old interface, there's nothing wrong with it
[18:49] <Keybuk> zyga: it's not very flexible
[18:49] <zyga> Keybuk, I second ebroder's comment on this
[18:49] <zyga> Keybuk, true
[18:50] <zyga> Keybuk, so you have two upgrade paths: systemd and upstart
[18:50] <Keybuk> yes
[18:50] <zyga> Keybuk, but if it's okay for you you don't have to worry about the next ubuntu breaking the world for no good reason
[18:50] <kees> Keybuk: hrm, this should be the minimal test case, right? run alone, it works fine. http://paste.ubuntu.com/546681/
[18:50] <Keybuk> zyga: what's it got to do with breaking the world?
[18:50] <Keybuk> kees: no idea
[18:50] <zyga> Keybuk, if you don't change your code (to support upstart/systemd) how will your dbus .service get activated without the deaemon?
[18:51] <Keybuk> zyga: it won't
[18:51] <zyga> broken!
[18:51] <zyga> :-)
[18:51] <zyga> see what I mean?
[18:51] <Keybuk> that's just the day-to-day business of linux
[18:51] <zyga> why cannot we just keep that support
[18:51] <Keybuk> if you still have an agent in /etc/hotplug - it won't work now :p
[18:51] <ebroder> Keybuk: I think my issue is mostly that D-Bus is currently init-daemon agnostic, and it seems lame to switch to a model that is no longer agnostic of the init daeomn, especially when there's more than one popular daemon right now
[18:51] <zyga> Keybuk, I hope you don't believe that ;-)
[18:51] <Keybuk> zyga: I didn't say we couldn't - in fact, I believe I asked you to write it ;-)
[18:51] <zyga> Keybuk, there is _nothing_ wrong with those files
[18:51] <zyga> Keybuk, great :-)
[18:51] <Keybuk> ebroder: but that switch has already happened
[18:51] <Keybuk> ebroder: we're just catching up
[18:51] <zyga> Keybuk, so at least we agree that it's not an issue to support that
[18:52] <ebroder> That doesn't make it any less of a terrible design decision
[18:52] <Keybuk> zyga: I have zero problem with upstart parsing the existing dbus service files
[18:52] <Keybuk> and generating jobs from it
[18:52] <zyga> Keybuk, so that the world has a common denominator to target if they are fine with the subset of features they might otherwise get
[18:52] <zyga> Keybuk, what about dbus parsing them and just sending the details over the wire? this way there is almost no patch for upstart and rather smallish patch for dbus (I might try to do that over xmas)
[18:53] <Keybuk> zyga: that's a lot of effort to add to d-bus
[18:53] <Keybuk> which is going away
[18:53] <zyga> Keybuk, hmm
[18:53] <Keybuk> and then, when the daemon vanishes, you'd need to do it all again
[18:53] <Keybuk> if upstart were patched to parse them in the first place
[18:53] <zyga> Keybuk, do you think that everyone will actually drop the daemon?
[18:53] <Keybuk> then the effort is only done once
[18:53] <Keybuk> and lasts forever
[18:53] <Keybuk> zyga: that's certainly what everyone wants to do
[18:53] <Keybuk> it's Slooooowwww
[18:53] <zyga> Keybuk, if that's really going to happen then you are right, parsing the stuff in upstart is better
[18:54]  * janimo wonders what is the difference between armel and other builds servers, as debian/rules only fails on armel due to an error in mv
[18:54] <zyga> janimo, armel is never virtual
[18:54] <zyga> janimo, and has some security around that so that random build should not take over the system
[18:55] <zyga> janimo, what was the move that failed?
[18:55] <cjwatson> zyga: distro buildds in general aren't virtual
[18:55] <janimo> zyga: in the ghc6 build, moving some doc files as the install step of the build
[18:55] <zyga> (except for qemu of course but I don't know if we have that in our builds)
[18:55] <zyga> cjwatson, are x86 packages not build by virtual machnies?
[18:55] <cjwatson> zyga: only ppas
[18:55] <janimo> zyga: I was expecitng all makesfiles to fail when a mv fails but only armel did
[18:55] <zyga> cjwatson, hmm
[18:56] <zyga> cjwatson, ah, so we trust our packages more to let them run on hardware, right?
[18:56] <cjwatson> janimo: look up in the log to see if something failed earlier (e.g. it failed to build the docs) and buggily failed to notice
[18:56] <janimo> and I see quite a few mv: cannot stat file .... causing FTB in debian and ubuntu during the years
[18:56] <cjwatson> zyga: yes
[18:56] <zyga> Keybuk, thanks for the clarifications
[18:56] <zyga> Keybuk, I'll have a look at this over xmas
[18:56] <janimo> cjwatson: will check. The same thing built locally on armel
[18:57] <cjwatson> I certainly very much doubt that mv is fundamentally different on armel!
[18:57] <Keybuk> zyga: the patch isn't so much an "ideal world" more of a "here's our reaction to the systemd patch"
[18:57] <zyga> Keybuk, yeah, it shows
[18:57] <janimo> cjwatson: one file that it expects to mv is missing but that is the case for x86 as well
[19:06] <Laney> janimo: thanks, I hope to get some time soon
[19:06] <janimo> Laney: strangely it buildt locally
[19:06] <Laney> I will upload 6.12.3 soon though, so we can see if it's fixed by that
[19:07] <janimo> Laney: ok. the only packaging change I can think of is to ignore mv errors in the haddock section
[19:07] <janimo> just to rule out that this trips over armel
[19:07] <Laney> yes
[19:08] <Laney> but it's a concerning failure nonetheless
[19:08] <apw> Keybuk, do you know if there is any debug in udev at all ?
[19:08] <janimo> Laney: are the arm and pthread fixes in 6.12.3 upstream or you will carry them in packaging
[19:08] <Laney> I got it from a nug
[19:09] <Laney> a bug*
[19:09] <janimo> Laney: only one package (base 3 ) does not provide *.haddock files and that is the error. Not sure if it is supposed to have those files though
[19:09] <Laney> it never failed like that before
[19:10] <ion> keybuk: Looking at http://launchpadlibrarian.net/61083245/dbus_1.4.1-0ubuntu1_1.4.1-0ubuntu2.diff.gz it seems an extraneous whitespace change has sneaked into a patch, search for process_config_every_time.
[19:12] <Keybuk> *gasp*
[19:12] <Keybuk> not extraneous whitespace!
[19:12] <mterry> @pilot out
[19:12] <Keybuk> I think I was probably un-tabbing things
[19:12] <Keybuk> and turning them back into spaces
[19:12] <Keybuk> apw: only if you recompile it
[19:13] <apw> Keybuk, and i'd be right in thinking there is no sensible way to go back a version in the archive
[19:24] <cjwatson> apw: correct, particularly not back an upstream version.  better to fix it ...
[19:25] <bdmurray> mdz: I seem to recall you modifying apport or dpkg to not report short read in buffer copy bugs is that right? Oh, it was only for english ones yes?
[19:25] <apw> cjwatson, /me has no idea as to the cause the symptoms for me are an unbootable kernel, i think sarvatt is affected too, he may be able to login to his after
[20:15] <mdz> bdmurray, yes
[20:15] <mdz> bdmurray, apt actually
[20:21] <bdmurray> mdz: and it was english only?
[20:22] <bdmurray> mdz: found it - thanks
[21:12] <jdstrand> hallyn, apw: I am seeing some weird, but major kvm regressions with the last two natty kernels
[21:13] <jdstrand> hallyn, apw: my hunch is something with ksm, but I don't know. the symptoms are if I run 2 or more vms at once, the vms are extremely flaky, with random segfaults all over
[21:14] <jdstrand> hallyn, apw: hold on. I'll report back later
[21:37] <jdstrand> hallyn, apw: there is a bug, but I'm still investigating. it might be with the hardware. nm for now
[21:48] <hallyn> jdstrand: kthx
[23:16] <ebroder> RAOF: We talked a month or two ago about stopping the X server from changing video modes when it starts to give gnome-settings-daemon a chance to pick the best mode. Have you had a chance to look into that yet?
[23:17] <ebroder> (And is there anything I, as someone who knows very very little about the X server, can do to help?)
[23:18] <RAOF> ebroder: I haven't yet, no.  I got pulled into a whirlpool of dri2.
[23:21] <RAOF> There's probably not much to do outside of adding a driver hook to startup to say “hey, there's a nice mode already set, just let me use that”.


[23:51] <christopher> hello georgia users
[23:54] <christopher> Fellow users i have a question
[23:54] <christopher> ?


[12:03] <jrib> do that nvidia config command
[12:04] <PuRu> sudo nvidia-glx-config enable ?
[12:04] <jrib> yep
[12:05] <PuRu_> sudo nvidia-glx-config enable
[12:05] <PuRu_> oops wrong paste
[12:05] <PuRu_> ward@ward-laptop:~$ sudo nvidia-glx-config enable
[12:05] <PuRu_> Error: unable to load nvidia kernel driver! Be sure to have installed
[12:05] <PuRu_> the nvidia driver for your running kernel.
[12:06] <jrib> sudo rmmod nvidia && sudo modprobe nvidia
[12:06] <PuRu_> ward@ward-laptop:~$ sudo rmmod nvidia && sudo modprobe nvidia
[12:06] <PuRu_> ERROR: Module nvidia does not exist in /proc/modules
[12:06] <jrib> ok
[12:06] <jrib> sudo modprobe nvidia
[12:07] <PuRu_> ward@ward-laptop:~$ sudo modprobe nvidia
[12:07] <PuRu_> Not loading nvidia module; not used in /etc/X11/xorg.conf
[12:07] <PuRu_> jrib:
[12:07] <jrib> ok now does   sudo nvidia-glx-config enable  ?
[12:08] <PuRu_> Error: unable to load nvidia kernel driver! Be sure to have installed
[12:08] <PuRu_> the nvidia driver for your running kernel.
[12:08] <PuRu_> lol
[12:08] <PuRu> told u my system is pissing me off
[12:09] <PuRu> reboot is not gonna change anything lol
[12:09] <jrib> humor me please
[12:09] <PuRu> is rebooting
[12:10] <jrib> I'm pretty sure the problem was that package with a different version
[12:10] <jrib> I just don't know enough about modules to load that up the right way...
[12:11] <PuRu> rebooted
[12:11] <PuRu> anyone else here who knows this?
[12:11] <jrib> ok  sudo nvidia-glx-config enable
[12:11] <PuRu> just a sec
[12:11] <PuRu> let me open xchat
[12:12] <PuRu_> back
[12:13] <PuRu_> what i still dont understand is how can i install a wrong version if i follow the tutorial
[12:13] <PuRu_> ?
[12:13] <PuRu_> Error: unable to load nvidia kernel driver! Be sure to have installed
[12:13] <PuRu_> the nvidia driver for your running kernel.
[12:13] <jrib> it's not that you installed the wrong version, it's taht the package didn't get upgraded for some reason
[12:13] <jrib> apt-cache policy linux-restricted-modules-common
[12:13] <jrib> what version is installed?
[12:13] <PuRu> 6.10
[12:13] <PuRu> edgy
[12:14] <jrib> I mean that the commands returns for linux-restricted-modules-common
[12:14] <PuRu_> he cant find the packet "linux-respricted-modules-commo"
[12:14] <jrib> put an 'n' at the end
[12:14] <PuRu_> literally commo
[12:15] <PuRu_> linux-restricted-modules-common:
[12:15] <PuRu_>   Genstalleerd: <IP_ADDRESS>-1
[12:15] <PuRu_>   Kandidaat: <IP_ADDRESS>-1
[12:15] <PuRu_>   Versietabel:
[12:15] <PuRu_>  *** <IP_ADDRESS>-1 0
[12:15] <PuRu_>         500 http://security.ubuntu.com edgy-security/restricted Packages
[12:15] <PuRu_>         100 /var/lib/dpkg/status
[12:15] <PuRu_>      <IP_ADDRESS>-11 0
[12:15] <PuRu_>         500 http://be.archive.ubuntu.com edgy/restricted Packages
[12:15] <PuRu> sorry for the long paste, wanted to spare some time
[12:15] <PuRu> pastebins seem slow
[12:15] <jrib> ok, sudo apt-get remove nvidia-glx && sudo apt-get install nvidia-glx
[12:15] <PuRu> genstalleerd = installed
[12:15] <PuRu> kandidaat = candidate
[12:16] <PuRu> versietabel = veriontable
[12:16] <PuRu> versiontable
[12:16] <PuRu_> is working
[12:17] <jrib> PuRu_: are you using the generic kernel?
[12:17] <PuRu> 386 i believe
[12:17] <PuRu> i dunno the difference
[12:18] <PuRu> shall i reboot to make sure i choose for 386?
[12:18] <jrib> no, generic should be it
[12:18] <jrib> Some people on the forums had this same problem and they needed to use generic
[12:18] <PuRu> i'll reboot and make sure i choose generic then
[12:18] <jrib> k
[12:20] <jrib> I assumed I was using generic, but apparently I'm not... strange
[12:21] <PuRu> rebooted :-)
[12:22] <jrib> uname -a   says generic now?
[12:23] <PuRu_> back
[12:24] <PuRu_> yes it says generic
[12:24] <PuRu> sorry my dad came in
[12:24] <PuRu> spliff is ready
[12:24] <jrib> ok hopefully that command works now
[12:24] <PuRu> time for a ganjabreak
[12:25] <PuRu> wich command?
[12:25] <jrib> sudo nvidia-glx-config enable
[12:26] <PuRu_> nope doesnt work lol
[12:26] <PuRu> brb
[12:26] <jrib> :/
[12:26] <PuRu> reinstall?
[12:26] <PuRu> if so i set it up to reinstall while i'm smoking
[12:26] <jrib> apt-cache policy linux-restricted-modules-$(uname -r)
[12:27] <PuRu> or shall i uninstall the nvidia-glx?
[12:27] <PuRu> since its the wrong version :s
[12:27] <PuRu> lol anyway brb
[12:27] <PuRu> cant wait any longer
[12:27] <jrib> heh ok
[12:29] <jrib> hmm maybe it's nvidia-xconfig
[12:41] <PuRu_> jrib: back
[12:44] <PuRu> you mean as a command? "nvidia-xconfig"
[12:46] <jrib> PuRu: yeah
[12:46] <jrib> I just read that that's the new way to do it in edgy
[12:46] <jrib> (in the wiki)
[12:47] <PuRu> i just did it
[12:47] <jrib> but make sure linux-restricted-modules-$(uname -r) is installed
[12:47] <PuRu> sudo nvidia-xconfig
[12:47] <PuRu> lol then i did ctrl-alt-backspace
[12:47] <jrib> ok did it work?
[12:47] <PuRu> now i get a black screen after getting a cursus on the left top
[12:48] <jrib> alright hit ctrl-alt-f1 and   apt-cache policy linux-restricted-modules-$(uname -r)
[12:48] <PuRu> so no it didnt work :p
[12:48] <PuRu> ctrl-alt-f1 didnt work
[12:48] <PuRu> it was really a crash lol
[12:48] <PuRu> i'm rebooting
[12:48] <PuRu> i thought linux didnt crash fast :p
[12:48] <jrib> maye the kernel
[12:49] <jrib> X is easy to crash
[12:49] <PuRu> damn lol
[12:49] <PuRu> reboot does nothing
[12:49] <PuRu> ctrl-alt-delete either
[12:49] <PuRu> start with a fresh install maybe?
[12:49] <PuRu> i think ubuntu is quite fucked up by now :p
[12:49] <jrib> heh go for it
[12:50] <PuRu> its done pretty fast anyway
[12:50] <PuRu> and then we're 100% sure i got a standard ubuntu edgy
[12:51] <PuRu> i work at a helpdesk (for windoze pc's, general home users) and we often start from scratch becasue thats the only way to be sure when something keeps going wrong
[12:54] <PuRu> *installing*
[12:56] <PuRu> jrib: any idea why it didnt work the first time when i used the tutorial?
[12:56] <jrib> maybe because you didn't have the generic kernel loaded
[12:56] <jrib> or maybe not
[12:56] <jrib> no I'm not really sure why it didn't work
[12:56] <PuRu> that can be
[12:57] <PuRu> that i didnt load the generic kernel
[12:57] <PuRu> well now i got time for a new spliff while it installs :-)
[12:58] <PuRu> got a car accident today, kinda have a bad day lol
[12:58] <PuRu> and then ubuntu that keeps refusing to work with the nvidia driver on my system
[12:58] <jrib> oh, you alright?
[12:59] <PuRu> yeah, but the car = f*cked up
[12:59] <PuRu> radiator = dead, airco radiator = also dead
[12:59] <PuRu> front bumper = dead, front lights are dead, the hood = bend, ...
[12:59] <jrib> well they happen, good thing is you are alright
[01:00] <PuRu> yeah but still
[01:01] <PuRu> i was gonna buy my own car
[01:01] <PuRu> now i'm not gonna have moeny to by my own
[01:01] <PuRu> because some idiot is parked in the middle of the street
[01:01] <PuRu> i start to hate idiotic people more and more each day
[01:01] <PuRu> every day at work nothing but idiots that call me...
[01:02] <PuRu> on the road nothing but idiots that do stupid manouvres
[01:02] <PuRu> this world is completely filled with idiots...
[01:06] <PuRu> jrib: files are copying :-)
[01:08] <jrib> cool
[01:08] <PuRu> my guess is he's ready in 20minutes at most
[01:08] <cntb> o/
[01:09] <unix_infidel> what's this weeks session on?
[01:09] <unix_infidel> the wik is sort of out of date.
[01:10] <jrib> unix_infidel: atm I'm not sure we have an instructor
[01:10] <PuRu> omg lol
[01:10] <PuRu> the installer seems crashed!
[01:10] <unix_infidel> what's the topic even :P
[01:10] <unix_infidel> ?
[01:10] <PuRu> just when i thought i had seen it all
[01:11] <jrib> unix_infidel: The Linux Kernel
[01:12] <PuRu> lol its my drive
[01:12] <PuRu> the contact is bad lately
[01:12] <PuRu> just glad its not my HD :-)
[01:15] <PuRu> voila, working again
[01:16] <jrib> unix_infidel: ok update, we do have an instructor
[01:17] <PuRu> are there actually lessons given here or is this just the channel for n00bs?
[01:19] <cntb> \o
[01:19] <cntb> so room is not ghost town any more?
[01:19] <tonyyarusso> Varies widely cntb .
[01:20] <tonyyarusso> People are becoming more aware, which is fantastic.
[01:24] <cntb> well
[01:24] <jrib> PuRu: there are actual lessons, see the schedule in the topic
[01:25] <jrib> this weekend!
[01:25] <tonyyarusso> sweet
[01:25] <jrib> tonyyarusso: what do you think sysadmin 101 entails?
[01:26] <tonyyarusso> jrib: No idea...probably not too hard though if it's 101
[01:26] <LjL> jrib: chown/chmod? :P
[01:26] <LjL> perhaps adduser
[01:27] <tonyyarusso> jrib: You volunteering?
[01:28] <jrib> tonyyarusso: well I don't know what exactly I would teach.  But I wouldn't mind learning something new over the next couple of weeks so I could teach it
[01:29] <LjL> you can teach that, trust me :P
[01:29] <tonyyarusso> jrib: Awesome.  I'll bet we could get some folks to guide you along too.  There's a mailing list - could ask there.
[01:29] <tonyyarusso> jrib<EMAIL_ADDRESS>[01:30] <jrib> I'm a member :)
[01:30] <tonyyarusso> I don't personally consider myself "advanced", but I do run a server for kicks, so depending what they mean I might be able to handle that.
[01:31] <jrib> I don't think i ever get any mail from that list though
[01:31] <jrib> PuRu_: working?
[01:31] <PuRu_> is reinstalling
[01:32] <PuRu_> yeah the contact of the drive is a bit bad
[01:32] <PuRu_> sometimes it doesnt work
[01:32] <PuRu_> the cd drive
[01:46] <PuRu_> jrib: installed / rebooting :-)
[01:46] <jrib> gl
[01:46] <PuRu_> ubuntu = installed lol
[01:46] <PuRu_> not the driver
[01:47] <PuRu_> booting generic mode
[01:47] <PuRu_> (this was the only mode right now is that normal?)
[01:54] <jrib> the generic kernel, yeah
[01:55] <PuRu_> allright, i'm booted :-)
[02:07] <PuRu_> now what to do lol?
[02:08] <PuRu_> jirib:
[02:28] <jrib> PuRu_: ?
[02:30] <tonyyarusso> !nickspam | Limulf
[02:30] <ubotu> Limulf: You should avoid changing your nick in a busy channel like #ubuntu - it causes unrequired scrolling which is unfair on new users. The same goes for using noisy away messages (see !Away for more details): use the command "/away <reason>" to set your client away silently
[02:31] <tonyyarusso> (Not a very busy channel, but still, pick one ;)  )
[02:31] <Limulf> Sorry a lot, i'll keep that in mind :-)
[02:32] <PuRu_> jrib: what can i try to make ubuntu install teh correct version?
[02:32] <PuRu_> or anyone else
[02:32] <jrib> PuRu_: the wiki instructions should work, just install nvidia-glx and the restricted modules for your kernel
[02:33] <PuRu_> last time i did that exactly
[02:33] <PuRu_> so i assume this time it wont work
[02:33] <PuRu_> but it did it wit synaptic
[02:33] <PuRu_> can that matther?
[02:33] <jrib> last time you had the other kernel remember?  I found some people on the forums with the same issue
[02:34] <jrib> so first, install linux-restricted-modules for your kernel
[02:35] <PuRu_> wich command please?
[02:36] <PuRu_> (or tutorial if its more then one command)
[02:36] <jrib> https://help.ubuntu.com/community/BinaryDriverHowto/Nvidia
[02:36] <jrib> sudo aptitude install linux-restricted-modules-generic
[02:37] <PuRu_> lol i allready did that last time
[02:37] <PuRu_> but not the command
[02:38] <PuRu_> "In the Software Preferences dialog that comes up, click the Add button."
[02:39] <PuRu_> no add button in the screen that pops up
[02:40] <jrib> PuRu_: you should have a checkbox for restricted
[02:41] <PuRu_> its just to enable all the packets?
[02:41] <PuRu_> if so then i know what u mean and did it
[02:41] <jrib> k
[02:41] <PuRu_> yeah its the one i mean
[02:41] <PuRu_> i did that last time too
[02:41] <PuRu_> sould i do the command too?
[02:41] <jrib> that should let you install linux-restricted-modules-generic
[02:42] <PuRu_> the install went fine
[02:42] <PuRu_> last time
[02:42] <PuRu_> no errors or anything
[02:42] <jrib> k
[02:42] <PuRu_> it was after the install
[02:42] <jrib> what card is this by the way?
[02:43] <PuRu_> 420 go with 32mb
[02:44] <PuRu_> (toshiba sattelite pro m10)
[02:44] <jrib> ok should work, I have a similar card
[02:44] <PuRu_> its not legacy, i checked
[02:44] <jrib> 440 go
[02:44] <PuRu_> what do u have?
[02:44] <PuRu_> i do this command right: sudo aptitude install linux-restricted-modules-generic
[02:44] <PuRu_> ?
[02:44] <jrib> yeah, assuming 'uname -a' says you are running generic
[02:47] <PuRu_> ok did "sudo aptitude install linux-restricted-modules-generic"
[02:47] <PuRu_> and its finished
[02:47] <PuRu_> now just install nvidia-glx trough synaptic?
[02:47] <PuRu_> or something else first?
[02:48] <jrib> just nvidia-glx
[02:48] <jrib> you can use aptitude for that too if you want
[02:49] <PuRu_> too late lol
[02:49] <jrib> same thing
[02:50] <PuRu_> i just did sudo synaptic and then marked nvidia-glx
[02:50] <jrib> k
[02:50] <PuRu_> and then installed offcourse
[02:50] <jrib> after it finishes, sudo nvidia-xconfig
[02:52] <PuRu_> it takes longer then last time i think
[02:52] <PuRu_> sudo nvidia-xconfig = done
[02:52] <PuRu_> what's next?
[02:53] <jrib> ctrl-alt-backspace
[02:53] <PuRu_> *prays*
[02:53] <PuRu_> bang "failed to start x-server"
[02:54] <jrib> seriously?
[02:54] <PuRu_> lol yeah
[02:54] <PuRu_> i'm looking at the ugly blue screen right now
[02:55] <PuRu_> wtf can be the problem lol
[02:55] <PuRu_> i don't get it
[02:55] <jrib> cp /var/log/Xorg.0.log ~/Desktop   , restore your backup xorg.conf and pastebin that
[02:55] <PuRu_> cp /var/log/Xorg.0.log ~/Desktop what does this command do?
[02:56] <jrib> copies the Xorg.0.log to your desktop
[02:57] <PuRu_> what are the commands to restore please?
[02:57] <PuRu_> allways do this kind of stuff with x lol
[02:58] <jrib> ls /etc/X11/xorg.conf*    should list some files, what are they?
[02:58] <PuRu_> ls is one of the few commands i do know :-)
[02:59] <PuRu_> conf and conf.backup
[02:59] <PuRu_> i copy the xorg.conf to desktop and then rename the other one i assume
[02:59] <jrib> PuRu_: sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.broken && sudo cp /etc/X11/xorg.conf.backup /etc/X11/xorg.conf
[03:00] <jrib> you could do that as well if you prefer
[03:02] <PuRu_> did it all
[03:02] <PuRu_> x = command to start x right?
[03:02] <tonyyarusso> PuRu_: startx
[03:02] <jrib> sudo invoke-rc.d gdm restart
[03:02] <tonyyarusso> or that
[03:02] <PuRu_> oh yeah :-)
[03:02] <tonyyarusso> Actually, I'd go with the gdm method unless you have a reason not to
[03:02] <jrib> tonyyarusso: does he need to reboot after install nvidia-glx?
[03:03] <tonyyarusso> jrib: Not a clue.  Try restarting X, if that doesn't work, then assume yes and see what happens ;0
[03:03] <tonyyarusso> ;) even
[03:03] <PuRu_> ok gui working
[03:03] <jrib> ok well at least nv still works for you this time
[03:03] <PuRu_> but with the old xorg.conf lol
[03:03] <PuRu_> lol
[03:04] <jrib> ok pastebin xorg.conf and Xorg.0.log on your desktop
[03:04] <PuRu_> how can this be possible?
[03:04] <PuRu_> ok
[03:04] <PuRu_> just a sec i'll install xchat
[03:08] <PuRu> voila
[03:09] <PuRu> http://paste.uni.cc/12144
[03:09] <PuRu> thats the log
[03:10] <PuRu> xorg.conf : http://paste.uni.cc/12145
[03:11] <PuRu_> thats the xorg.conf that made x crash
[03:11] <PuRu_> and the log was also copyed to desktop before i restored the backup
[03:11] <PuRu_> anything unusual?
[03:14] <jrib> ok lets check the usual first,    apt-cache policy linux-restricted-modules-common linux-restricted-modules-$(uname -r) nvidia-glx
[03:14] <jrib> make sure the version number match up
[03:16] <PuRu> results: http://paste.uni.cc/12146
[03:17] <PuRu> jrib: (just because i forgot your name lol)
[03:17] <jrib> agh they are different
[03:17] <PuRu_> thats good news then thats the problem :-)
[03:17] <jrib> sudo apt-get update && sudo apt-get upgrade
[03:17] <PuRu_> is it fixable?
[03:18] <PuRu> is running
[03:18] <jrib> reboot afterwards to make sure they get loaded
[03:18] <PuRu> ok
[03:18] <PuRu_> lol its funny to see the same irc text on 2 screens
[03:19] <jrib> what is 'apt-cache policy nvidia-kernel-common' too while that is installing?
[03:19] <PuRu_> just run that in another terminal?
[03:19] <jrib> yeah
[03:20] <PuRu> nvidia-kernel-common:
[03:20] <PuRu>   Genstalleerd: 20051028+1ubuntu7
[03:20] <PuRu>   Kandidaat: 20051028+1ubuntu7
[03:20] <PuRu>   Versietabel:
[03:20] <PuRu>  *** 20051028+1ubuntu7 0
[03:20] <PuRu>         500 http://be.archive.ubuntu.com edgy/restricted Packages
[03:20] <PuRu>         100 /var/lib/dpkg/status
[03:20] <jrib> ok
[03:25] <PuRu_> rebooting :-)
[03:25] <PuRu_> i boot into generic?
[03:25] <jrib> 2yep
[03:27] <jrib> y/n?
[03:27] <PuRu> back
[03:27] <PuRu_> y/n what?
[03:27] <jrib> are you using nvidia?
[03:28] <PuRu_> i dunno, don't think so
[03:28] <PuRu_> i do ctrl-alt-backspace to test?
[03:28] <jrib> oh we didn't do nvidia-xconfig
[03:28] <jrib> heh
[03:28] <PuRu_> so i do that one?
[03:28] <jrib> yep
[03:28] <PuRu_> and then ctrl-alt-backspace?
[03:29] <jrib> yes
[03:30] <PuRu_> black screen...
[03:30] <PuRu_> ctrl-alt-F1 doesnt work
[03:31] <PuRu_> i'm assuming linux crashed yet again?
[03:31] <PuRu_> (at this point it crashes more then any windows i ever used)
[03:32] <jrib> http://www.ubuntuforums.org/showthread.php?t=293014
[03:32] <PuRu_> the capslock doesnt evne work anymore so its crashed for sure
[03:32] <jrib> http://www.ubuntuforums.org/showthread.php?p=1700610#post1700610
[03:32] <jrib> we can try that
[03:33] <PuRu_> downgrading?
[03:33] <PuRu_> i can't really find what u mean
[03:33] <jrib> well we could try that as well
[03:34] <PuRu_> what did u mean?
[03:34] <PuRu_> i only read something about downgrading
[03:34] <jrib> just reading through everything, those people seem to be having similar problems
[03:36] <PuRu_> lol i give up
[03:37] <PuRu_> i'll use windows to VJ
[03:37] <jrib> D:
[03:37] <jrib> lets try the two suggestions
[03:37] <PuRu_> i cant even boot into linux no more...
[03:38] <jrib> choose "recovery mode" from the grub menu and restore the backup
[03:38] <PuRu_> can't try anything
[03:39] <PuRu_> its 3:40 in teh morning here lol
[03:41] <jrib> this is some kind of bug with the update
[03:41] <jrib> there are many threads on the forums now that I am looking
[03:42] <PuRu_> update from 6.06 to 6.10?
[03:43] <jrib> oh I thought you were in 6.10
[03:43] <PuRu_> i am in 6.10
[03:43] <PuRu_> so i can't use the nvidia driiver with ubuntu?
[03:43] <PuRu_> of not with any linux?
[03:43] <jrib> you can, this is almost certainly a bug with this package
[03:44] <jrib> lets downgrade to the earlier versions
[03:44] <PuRu_> if u know how
[03:44] <PuRu_> and if it doesnt take too long
[03:44] <jrib> apt-cache policy linux-restricted-modules-common linux-restricted-modules-$(uname -r) nvidia-glx   again please
[03:44] <PuRu_> because its getting late lol
[03:44] <PuRu_> erm
[03:44] <PuRu_> i cant even start x yet
[03:44] <jrib> ok, let me find it in the scrollback
[03:44] <PuRu_> replacing didnt work
[03:45] <PuRu_> but i can't start x yet
[03:45] <PuRu_> fucking xorg.conf is dead again
[03:45] <PuRu_> why does the fuicking backup not work :s
[03:45] <LjL> !language
[03:45] <ubotu> Please watch your language and keep this channel family friendly.
[03:45] <PuRu_> its impossible
[03:45] <jrib> LjL: you know anything about this nvidia-glx problem?  There are a few threads on the forums but I don't remember it
[03:47] <jrib> PuRu_: can you get to the recovery mode prompt ok?
[03:47] <PuRu_> i can get to the normal prompt ok now
[03:47] <LjL> jrib: summarize?
[03:47] <PuRu_> but still no x
[03:47] <jrib> LjL: he installs nvidia-glx and has linux-restricted-* but X refuses to start
[03:48] <jrib> http://paste.uni.cc/12145 xorg.conf and http://paste.uni.cc/12144 log
[03:49] <jrib> and I get a page full of search results on the forums, but I'm not really sure of a solution.  Most recommend installing the beta driver... was going to try downgrading now
[03:49] <LjL> jrib: shouldn't that use nvidia-glx-legacy?
[03:49] <PuRu_> nope
[03:49] <jrib> not according to the nvidia site, and I have a similar card
[03:49] <PuRu_> i checked that, at first i followed the tutorial
[03:50] <PuRu_> but that didnt work so i came to ask here
[03:50] <PuRu_> and i'm 100% sure its a 420 go :-)
[03:53] <LjL> haven't got a clue
[03:54] <jrib> http://doc.gwos.org/index.php/Latest_Nvidia_Edgy#PROBLEMS_SECTION mentions our cards PuRu_ though I never did that and mine worked
[03:54] <jrib> number 7 of the problems
[04:02] <PuRu_> what card do u have?
[04:02] <PuRu_> i'm gonna try this tomorrow
[04:03] <PuRu_> i'm too tired and need to work tomorrow
[04:03] <PuRu_> its 4 in the morning here
[04:03] <jrib> I have the 440
[04:03] <jrib> GeForce4 440 Go
[04:04] <jrib> easy way to downgrade would be to disable the security repository, remove nvidia-glx and the restricted packages and then install them again
[04:04] <jrib> in case you want to try that too
[04:05] <PuRu_> lol i'm even too tired to comprehend what you just typed
[04:06] <PuRu_> well i'm off to bed
[04:06] <jrib> night, hope you figure it out
[04:06] <PuRu_> i'll stay online, should u read something about it, please tell it here if i'm not disconnected yet
[04:07] <PuRu_> night night people
[06:41] <jrib> joeshmo: hello
[06:41] <joeshmo> hello
[06:41] <joeshmo> i think my fstab is real messed up
[06:41] <jrib> hmm, why?
[06:41] <joeshmo> it still has old ntfs lines in it
[06:41] <joeshmo> i got rid of those partitions and made them ext3
[06:41] <jrib> pastebin please
[06:42] <joeshmo> pastebin?
[06:42] <jrib> !pastebin
[06:42] <ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (be sure to give the URL of your paste - see also the #ubuntu channel topic)
[06:42] <monoxide> is it true linux can write on a fat 32 partition
[06:42] <jrib> monoxide: yes
[06:42] <monoxide> kool ill have to convert my NTSF then
[06:42] <joeshmo> http://paste.ubuntu-nl.org/36584/
[06:43] <jrib> monoxide: windows can read and write to ext3 if you install the fs-driver
[06:43] <monoxide> fat32 seem easier
[06:43] <monoxide> i just have existing data from my old windows install
[06:43] <jrib> fat32 doesn't support linux permissions however
[06:44] <monoxide> I am going to just be using linux for now but I might soon go back to windows
[06:44] <jrib> joeshmo: "interesting"
[06:44] <jrib> monoxide: nope, you'll never go back
[06:44] <joeshmo> see
[06:44] <joeshmo> its because i used pysdm
[06:44] <joeshmo> it made all new lines
[06:44] <joeshmo> i want to start over
[06:45] <jrib> did it/you make a backup?
[06:46] <joeshmo> theres 2 backups here
[06:46] <joeshmo> idk if i made them
[06:46] <joeshmo> or it
[06:46] <joeshmo> but they are the same
[06:46] <joeshmo> should i just reinstall
[06:46] <jrib> nah that's overkill
[06:46] <jrib> pastebin the two backups
[06:47] <joeshmo> http://paste.ubuntu-nl.org/36585/
[06:47] <joeshmo> http://paste.ubuntu-nl.org/36586/
[06:47] <joeshmo> before pydsm there was just the top part
[06:48] <jrib> how about swap?
[06:48] <joeshmo> swap is on /dev/hda5
[06:48] <joeshmo> i have no NTFS now either
[06:48] <jrib> ah i see it now
[06:48] <joeshmo> but theres still lines for NTFS there
[06:49] <jrib> ok, well just delete the ntfs lines does that resolve the problem?
[06:49] <jrib> 18. /dev/hdd5                                  /media/hdd5     swap         sw                                  0  0
[06:49] <jrib> 21. /dev/hda2                                  /media/hda2     swap         sw                                  0  0
[06:49] <jrib> how about those?
[06:50] <joeshmo> wait
[06:50] <joeshmo> i deleted the hdd5 one
[06:50] <joeshmo> its only hda2 now
[06:51] <jrib> ok then maybe it's easier for you to delete all the ntfs, then go one by one with the ones below swap and keep what you have
[06:51] <joeshmo> so what does this fstab do anywyas
[06:51] <jrib> erm, below floppy
[06:51] <joeshmo> i read if its not in fstab then only root can use it?
[06:51] <jrib> joeshmo: it's the partitions that get mounted
[06:51] <jrib> no, it just doesn't get mounted when you boot
[06:52] <jrib> but yeah, only root can mount stuff not in fstab
[06:52] <joeshmo> ok
[06:52] <joeshmo> im just gonna delete it all and try doing it over with pydsm
[06:52] <jrib> ok
[06:52] <joeshmo> but what option would i have to put to make it read write
[06:52] <joeshmo> rw?
[06:53] <jrib> for ext3, just use permissions, don't use any fstab options
[06:53] <joeshmo> ok
[06:54] <joeshmo> permissions stay after reboot right
[06:54] <jrib> yes
[06:55] <joeshmo> ok im gonna try this pysdm with a new fstab
[06:55] <joeshmo> backed up the old one
[06:57] <joeshmo> how do i chmod or chown them tho
[06:57] <joeshmo> i dont understand it
[06:57] <joeshmo> how u use a number
[06:58] <jrib> take care of mounting them first, then I'll give you a quick intro
[06:58] <jrib> that way we can actually try it on what you've mounted
[06:58] <joeshmo> ok ill be back
[06:58] <joeshmo> hopefully
[07:02] <jrib> joepits: ok, your / is still in fstab?
[07:03] <joepits> nooo
[07:03] <joepits> no /
[07:04] <jrib> make sure you have proc, /, swap, cdrom, floppy like your old one did
[07:06] <jrib> joepits: why did you leave by the way?
[07:07] <joepits> rebooted
[07:07] <joepits> didnt have to right
[07:07] <jrib> nope
[07:08] <joepits> ok
[07:08] <joepits> the old one had all 0 1
[07:08] <joepits> the new one is all 0 0
[07:08] <joepits> i should make it 0 1?
[07:08] <jrib> no
[07:08] <jrib> only / should be 0 1
[07:09] <joepits> ok
[07:09] <jrib> others should have a 2 instead of a 1 if you want them checked
[07:09] <joepits> proc       /proc        proc  defaults  0  0
[07:09] <joepits> /dev/hda1  /            ext3  defaults,errors=remount-ro   0  1
[07:09] <joepits> /dev/hda2  /media/hda2  swap  defaults  0  0
[07:09] <joepits> /dev/hdb1  /media/hdb1  ext3  defaults  0  0
[07:09] <joepits> /dev/hdd1  /media/hdd1  ext3  defaults  0  0
[07:09] <joepits> /dev/sda2  /media/sda2  vfat  defaults  0  0
[07:10] <joepits> welll
[07:10] <joepits> ill do that stuff later
[07:10] <joepits> how do i chmod to make it so all users can touch them
[07:10] <joepits> i got my terminal open
[07:10] <jrib> swap and cdrom and floppy you are missing
[07:10] <jrib> oh not swap...
[07:11] <joepits> oh
[07:11] <jrib> your swap looks different than your original, just copy what that one had
[07:13] <joepits> http://paste.ubuntu-nl.org/36589/
[07:13] <joepits> its pretty much the same as the old one but it doesnt have the UUID stuff idk what that is
[07:14] <jrib> hda5 used to be your swap
[07:15] <jrib> is that gone or something?
[07:15] <joepits> ya i got rid of that a while ago
[07:15] <joepits> do i just chmod 777
[07:16] <jrib> ok so lets do that, but don't forget you are missing floppy and cdrom
[07:16] <jrib> so if you have a permission like that with 3 numbers lets say 777
[07:16] <jrib> then the first number applies to the owner
[07:16] <jrib> the second number applies to the group
[07:16] <jrib> the last number is for everyone else, "other"
[07:17] <joepits> do i need a cdrom in there...
[07:17] <joepits> if i put a cd in it works
[07:17] <jrib> idk, it may mount it if you boot your computer wiht a cdrom in
[07:17] <joepits> oh
[07:17] <joepits> as for floppy, i cant find my cable
[07:17] <jrib> k
[07:18] <joepits> i dont really care about secuirty
[07:18] <jrib> I would just put it in commented
[07:18] <jrib> ok, so each number represents read, write, and execute permissions
[07:18] <joepits> ok
[07:18] <jrib> are you familiar with binary?
[07:18] <joepits> a little
[07:19] <jrib> ok, 100 do you know what that is in binary?
[07:19] <joepits> no
[07:19] <jrib> 1*2^2 + 0*2^1 + 0*2^0 = 4
[07:19] <joepits> oh right
[07:19] <jrib> 010 then is 0*2^2 + 1*2^1 + 0*2^0 = 2
[07:19] <jrib> and 001 is 1
[07:20] <jrib> now 7 is 4 + 2 + 1 = 111 in binary
[07:20] <jrib> so you can think about it this way, the first spot in binary is read, the second is write, the last is execute
[07:20] <jrib> or 4 is for read, 2 is for write, 1 is for execute
[07:21] <joepits> wow
[07:21] <jrib> if you want to give read and write, you add the numbers.  4+2=6
[07:21] <jrib> notice in binary this is 110
[07:21] <TheGilmanator> (Sorry to butt in, but it all makes sense now. It's taken me several years to get that. Thanks, jrib!)
[07:21] <joepits> now whyd they do it that way
[07:21] <joepits> just to be nerdy?
[07:22] <jrib> well it's a concise way to represent it, idk why they did it that way
[07:22] <joepits> so i want all users to read write and execute
[07:22] <jrib> ok, what do you think it should be then?
[07:22] <jrib> TheGilmanator: np :)
[07:22] <joepits> 777
[07:22] <TheGilmanator> jrib: I'll never have to look up a table again!
[07:23] <jrib> right, 7 gives read write and execute.  And you have 7 for users, for group, and for others
[07:23] <joepits> so i do that for the /dev/hdb1 etcetera
[07:23] <joepits> or for the /media/hdb1
[07:23] <jrib> just for the mount point
[07:23] <jrib> sudo chmod 777 /media/hdb1
[07:24] <jrib> chmod lets use easier ways to represent a permission as well
[07:25] <jrib> like   a+rwx   means give users, groups, and others read write and execute permissions
[07:25] <joepits> ok
[07:25] <joepits> lost and found
[07:26] <joepits> i cant get in there still but thas because its a root only thing?
[07:27] <jrib> hmm I'm not sure if permissions amtter or not, but you shouldn't use it.  It's for the filesystem
[07:27] <joepits> ok
[07:27] <joepits> well as long as i can put my files there which i can
[07:28] <jrib> joepits: did you try one of the paritions to test it out?
[07:28] <joepits> yeah i dragged af ile onto it
[07:28] <joepits> and it worked
[07:29] <joepits> idk why they cant give u a tool for that in ubuntu
[07:30] <joepits> but anywyas thanks for ur help
[07:30] <jrib> joepits: you can right click
[07:30] <joepits> ive been fretting over it all night
[07:30] <jrib> then permissions
[07:30] <joepits> yeah
[07:30] <joepits> but it says i cant ch ange them because im not root
[07:30] <jrib> but you'd need to run nautilus with 'gksudo nautilus'
[07:30] <joepits> ohh
[07:31] <joepits> just do that from console?
[07:31] <joepits> and it will start gdm and stuff
[07:31] <joepits> i know the other way to start gdm
[07:31] <jrib> joepits: start gdm?
[07:31] <joepits> idk
[07:31] <joepits> the window manager
[07:31] <joepits> or something
[07:31] <jrib> you are in gnome at the moment?
[07:31] <joepits> ya
[07:31] <jrib> just type 'gksudo nautilus' in a terminal
[07:33] <joepits> ok it didnt work
[07:33] <joepits> joe@joe-desktop:~$ gksudo nautilus
[07:33] <joepits> (nautilus:6173): GnomeUI-WARNING **: While connecting to session manager:
[07:33] <joepits> Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed.
[07:33] <joepits> (nautilus:6173): libgnomevfs-WARNING **: Failed to open session DBUS connection: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[07:33] <joepits> Volume monitoring will not work.
[07:33] <joepits> joe@joe-desktop:~$ gksu
[07:33] <joepits> joe@joe-desktop:~$
[07:33] <jrib> did nautilus still start?
[07:34] <joepits> oh well it opened up a new window yes
[07:34] <joepits> i have to use that one?
[07:34] <joepits> oh ya now i can do it through the permissions thing
[07:35] <jrib> yes, use it for what you need and then close it.  You can really mess stuff up if you get used to using it, so I'd recommend avoiding it
[07:35] <joepits> yeah they say taht
[07:35] <joepits> hehehehe
[07:35] <joepits> now im gonna go try and get wine to run CS
[07:35] <joepits> TYTYTY again
[07:36] <joepits> ty and goodnight
[07:36] <jrib> night
[07:37] <TheGilmanator> Dude, seriously.  When bitten by this bug ops in #ubuntu remove users so they are no longer targets. To fix it have a look here: https://help.ubuntu.com/community/FixDCCExploit
[06:59] <cntb> tonyyarusso, look pls
[06:59] <cntb> * Received 'DCC SCHAT "lol_jews_did_wtc" 0 0 0' from mrtanooki
[06:59] <tonyyarusso> cntb: Yep, we all saw that one.
[07:00] <cntb> so what happened to mrtanooki ?
[07:01] <cntb> tonyyarusso, must I fix all my installations of ubuntu ?
[07:01] <tonyyarusso> cntb: By putting that in #ubuntu people who are affected and haven't followed the instructions ubotu linked to get kicked offline, spamming the channel with quit messages.
[07:01] <tonyyarusso> cntb: If you didn't get kicked off by it, you can ignore it, and/or shout explitives at people who need a better hobby.
[07:02] <LjL> cntb: can you tell me when you received that? does your client timestamp?
[07:13] <cntb> yes LjL
[07:14] <cntb> 17:49:LjL,  timestamp  * Received 'DCC SCHAT "lol_jews_did_wtc" 0 0 0' from mrtanooki
[07:14] <LjL> tonyyarusso: actually i'd advice not speaking to them at all
[07:14] <LjL> i'm convinced that would be a positive feedback to them
[07:14] <tonyyarusso> LjL: Shoot, poor choice of words.
[07:14] <tonyyarusso> cntb: I meant "shout at" as in at the computer, not actually interacting with the people.  :P
[07:14] <tonyyarusso> LjL: Better?
[07:14] <LjL> cntb: (that was just to check your timezone, don't worry ;)
[07:15] <LjL> tonyyarusso: ah, yeah =) the computer probably deserves the expletives anyway
[07:15] <cntb> I am not allowed to do such CTCp time LjL  right ?
[07:15] <LjL> cntb: you aren't an identified user, so i guess not
[07:15] <LjL> !register
[07:15] <ubotu> Information about registering your Freenode nick is at http://freenode.net/faq.shtml#contents-userregistration
[07:16] <cntb> now I am identified
[07:16] <cntb> forgot to nickserv id
[07:17] <cntb> ;-)
[07:18] <cntb> btw any class hou any time soon ?
[07:18] <LjL> don't think
[07:19] <cntb> pls do ;-)
[07:20] <tonyyarusso> There's one on the calendar for this weekend; not sure of its status though.
[07:20] <LjL> well i could improvise a class myself about, uh... dunno. if i have to think "is there anything i know particularly well?", i can't come up with anything :PO
[07:21] <cntb> haha LjL  modest. good
[07:22] <LjL> well, there are people who know a lot about one topic
[07:22] <LjL> then there are people who know a few things about a few topics
[07:23] <LjL> then there's me - there's a LOAD of things i know a whole nothing about
[07:26] <cntb> ok still  you are helpful for quite some time to newcomers
[07:28] <tonyyarusso> LjL: We should have a class on cowspamming!
[07:30] <cntb> ok what is cowspamming ?
[07:33] <tonyyarusso> cntb: ASCII art pasting into the channel - normally a bad thing, but in special channels where nobody's trying to be productive, silly and fun ;)
[07:36] <cntb> ah seen that ty


  You can reacn outside with, say, `ping <IP_ADDRESS>`?
[00:41] <NinjaKirby> Aye, that's what I did, punched in the Google DNS and it was fine.
[00:43] <NinjaKirby> Wait wat, I've gone to use internet stuff and it's broken again.
[00:44] <NinjaKirby> I had to disable/enable the network adapter. Fortunately I don't have alot going on with this Lubuntu, so I will upgrade to the latest LTS.
[00:46] <NinjaKirby> Thanks for the help folks :)
[10:46] <johnhmalu> hello why .go files does not have a icon?
[16:18] <NinjaKirby> Greetings, I just upgraded to v18.10, in v16 it was possible to hold Win-Key and use arrows to position windows on the screen. Has this functionality switched to another key?
[16:19] <NinjaKirby> I suppose it's possible I'm using an incorrect keyboard layout
[18:09] <NinjaKirby> For the record, I ended up using a Life Hack known as effort, I click and dragged the window and resized it. Hooray for human creativity.
[18:20] <mike_papa> Hello. thanks. Again this is that strange moment, when trying to ask a question is giving you answer for a problem you're struggling with for last 2 hours. Isn't it something like "duck typing" in coding? ;)
[18:23] <mike_papa> where do I find docs on polkit files, etc.?
[18:24] <apt-ghetto> https://freedesktop.org/wiki/Software/polkit/
[18:25] <mike_papa> tnx a lot
[20:50] <hylian> hello
[21:04] <mchasard> hi
[21:04] <mchasard>  i can't upgrade any more i have this message
[21:05] <mchasard> Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
[21:05] <wxl> sounds like you have some other package manager running
[21:06] <mchasard> yes but its not the case
[21:06] <wxl> if you're absolutely, 100%, unquestionably sure you don't, you can always delete the file and try again. but you should make sure first.
[21:06] <wxl> like you should search your entire process list
[21:06] <mchasard> the lock-frontedn file ?
[21:06] <wxl> just because you don't "see" something doesn't mean something isn't running
[21:06] <wxl> correct
[21:06] <wxl> you might actually want to use `lsof` to see what is using it, if anything
[21:08] <wxl> e.g. `sudo lsof | grep /var/lib/dpkg/lock` (you don't have to add the -frontend)
[21:10] <mchasard> i have the /var/lib/dpkg/lock-frontend who is in red
[21:10] <mchasard> gmain gbus and dpkg
[21:10] <wxl> so you have dpkg running somewhere
[21:11] <mchasard> i should see under this line ?
[21:11] <wxl> gbus also makes me think something graphical is grabbing it
[21:11] <wxl> `lsof` basically tells you what resources are being used by which processes
[21:11] <mchasard> i have the last lxqt lubuntu distro
[21:11] <wxl> that error told you that some process is using the file
[21:11] <wxl> your results confirm that
[21:12] <wxl> you DO have some process running that is using the lock
[21:12] <mchasard> but which one ?
[21:12] <wxl> maybe you have unattended-upgrades on?
[21:12] <wxl> the ones that showed
[21:15] <mchasard> but which one ?
[21:15] <mchasard> i don't know really
[21:16] <wxl> you just told me them
[21:17] <mchasard> i don't know why i just relaunch the upgrade and now it done
[21:17] <wxl> probably because the process was running in the background and it stopped
[21:17] <wxl> it could be you had some sort of automated upgrades running
[21:17] <mchasard> ok
[21:18] <wxl> or it was some other thing that you didn't realize was actually installing packages
[21:18] <mchasard> guiverc
[21:18] <mchasard> ok thanks
[21:18] <wxl> np
[21:18] <mchasard> another thing it about bluetooth
[21:19] <mchasard> at the begining my jbl go was recognized but now its not the case
[21:19] <wxl> our bluetooth support is a little incomplete grpahically
[21:19] <wxl> i'm sure you could do it on the command line
[21:19] <mchasard> bluetooth device wizard
[21:20] <mchasard> ok but what are the command line please ?
[21:21] <wxl> you can read between the lines here https://help.ubuntu.com/community/BluetoothSetup
[21:21] <mchasard> ok
[21:25] <mchasard> ok i can see it when i tape hcitool scan
[21:29] <mchasard> hidd command not found ?
[21:38] <mchasard> to appear my device i try to launch this
[21:38] <mchasard> sudo hidd --connect 40:EF:4C:7E:A8:AF
[21:38] <mchasard> but hidd is not recognized
[21:42] <wxl> looks like it was deprecated.. bluetoothd-service-input may be the alternative if i read correctly https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477838
[22:31] <NinjaKirby> Hmm, it seems strange to me that "let $derp+=1" doesn't work; you have to remove the Dollar sign...
[22:32] <NinjaKirby> Unless the dollar sign determines a non-mathematical purpose.
[22:36] <NinjaKirby> Oh bollocks, sorry, I typed in the wrong channel. Oh well, to quote Anna Coppola, "Mystery is a mystery".
[23:53] <saptech> greetings all
[23:54] <saptech> fairly new to lubuntu and like it alot, great job devs
[23:56] <saptech> when I boot into lubuntu, at the login screen, I see that virtual keyboard. Why do I need it on a desktop pc and How can I turn it off?
[23:59] <wxl> i have never seen a virtual keyboard when booting
[23:59] <wxl> could be that fcitx/ibus (depending on t version) is configured in some way to always show it)