[01:09] <guest-lkajdf_431> Hi. I'm sorry but I ain't gettin no love on #ubuntu; and, frankly, this may be a more technical problem than anyone there can handle right now (dunno). If it's wrong for me to ask here just let me know - I just thought I'd give it a shot.
[01:10] <guest-lkajdf_431> http://www.computercorrect.com/2010/operating-systems/linux/ubuntu/ubuntu-10-04-10-11-touchpad-quitting/
[01:10] <guest-lkajdf_431> ^ That is the closest thing I can find to my situation (sounds just like what I'm going through) - but it is talking about older versions of ubuntu. I need to be sure that the soln is for current ubu 14
[01:11] <guest-lkajdf_431> I have not installed ubu 14 on that lappy yet. I found this out when going into "try ubuntu" to test for just such things
[01:12] <guest-lkajdf_431> sorry, ubu = ubuntu (it's my pet name for it)     ;)
[01:14] <sarnold> guest-lkajdf_431: when I run gconf-edit, I see a /desktop/gnome/peripherals/touchpad/ path but no touchpad_enabled setting...
[01:15] <sarnold> guest-lkajdf_431: no idea if that should exist beforehand or not. that bit seems plausible.
[01:15] <sarnold> guest-lkajdf_431: but I don't see any /apps/gnome_settings_daemon/ paths
[01:16] <sarnold> guest-lkajdf_431: .. and I'm not finding anything in there that looks related. Again, I don't know if they should exist before being modified or not.. but that half of the solution doesn't look promising
[01:17] <tarpman> that stuff has all moved into gsettings long ago...
[01:18] <guest-lkajdf_431> sarnold: tarpman: thx
[01:18] <guest-lkajdf_431> any suggestions for a proper way to fix the issue?
[01:35] <guest-lkajdf_431> sorry I gotta go for now
[08:05] <pitti> infinity: the -cpu thing was a red herring; it was aria2 crashing on $no_proxy
[08:33] <seb128> wgrant, hey, do you know how launchpad translations import work?
[08:34] <seb128> wgrant, more specifically https://launchpadlibrarian.net/186404505/buildlog_ubuntu-utopic-i386.evolution-data-server_3.12.6-0ubuntu3_UPLOADING.txt.gz generated a tarball for translations
[08:34] <seb128> wgrant, but https://translations.launchpad.net/ubuntu/utopic/+source/evolution-data-server/+imports doesn't seem to want to import any out of the template
[08:38] <seb128> wgrant, https://launchpad.net/ubuntu/utopic/+upload/8030046/+files/evolution-data-server_3.12.6-0ubuntu3_i386_translations.tar.gz is the generated tarball from the build, looks fine to me
[08:38] <seb128> not sure why it's not making it up to the import queue
[08:42] <Noskcaj> Laney, Could i have a testimonial for MOTU or gnome-packageset? https://wiki.ubuntu.com/Noskcaj
[08:43] <Noskcaj> seb128, Also, could i have one from you
[08:51] <Laney> Noskcaj: maybe, I'll have to look at your recent work
[08:51] <Laney> I think you should get your old sponsors to refresh their wording
[08:54] <Noskcaj> thanks. I'm not going to be on irc much till the day, so please reply via email if it's later
[08:59] <wgrant> seb128: Packages that share translations with upstream don't accept PO imports, it seems.
[08:59] <wgrant> seb128: I guess because there's no way to merge them; new translations from upstream would be clobbered by an SRU, for example.
[09:02] <seb128> wgrant, urg, why is sharing enabled for those, it shouldn't since they are GNOME projects
[09:02] <seb128> wgrant, thanks for pointing that out
[09:02]  * seb128 drops the sharing
[09:03] <seb128> wgrant, I guess we need another upload to import them after unsetting the sharing?
[09:03] <seb128> Noskcaj, ok
[09:05] <Noskcaj> ty
[09:05] <seb128> Noskcaj, did you get motu yet?
[09:06] <Noskcaj> seb128, no? meeting is monday
[09:07] <Laney> no, you need to give a week
[09:08] <seb128> Noskcaj, that was a question, you should know if you are motu or not?
[09:08] <seb128> that seems like a first step before gnome pkgset upload rights
[09:09] <Noskcaj> Laney, I've been on the wiki agenda for the meeting for a few weeks
[09:09] <Laney> I saw the email today
[09:09] <Noskcaj> seb128, Did not know that, i though they could be went for at the same time
[09:10] <seb128> Noskcaj, they could
[09:10] <seb128> I'm just asking to know if you got ack for motu yet or not
[09:10] <seb128> my impression was still that you were not always responsive for issues you create
[09:11] <seb128> so I'm unsure you are ready to be recommended for a set like gnome
[09:11] <Noskcaj> seb128, With the exception of python-wsme, which is an ungodly mess, i think i am
[09:11] <seb128> it would be nice if you tried to focus on resolving the problem you create before working on syncing more new stuff
[09:11] <Noskcaj> Laney, I forgot to send it, because holidays
[09:12] <seb128> like recently I had to revert your libgtop upload where the soname changed and you didn't rename the package accordingly
[09:12] <Noskcaj> seb128, Excluding that package, i do
[09:12] <Noskcaj> seb128, My only other bad upload, and i've since improved my package testing, as my current laptop can actually test stuff
[09:13] <Noskcaj> *bad upload this cycle AFAIK
[09:13] <seb128> Noskcaj, what about https://bugs.launchpad.net/ubuntu/+source/xchat-gnome/+bug/1272455 ? you screwed it, people had to revert, the bug is assigned to you and you are happily ignoring it since january
[09:13] <Noskcaj> and i've fixed libgtop in debian svn following your changes
[09:14] <Noskcaj> seb128, old laptop, me being lazy and trusting debian, i'm not sure how i'm meant to continue with that
[09:14] <seb128> Noskcaj, well, step one would be to comment on the bug to say that
[09:14] <seb128> rather than ignore it
[09:14] <seb128> Noskcaj, then, it should be easy to build/test again that version and see if you can reproduce the issues described
[09:15] <Noskcaj> brb, need dinner
[09:15] <seb128> enjoy!
[09:28] <wgrant> seb128: Another upload or a copy.
[09:31] <seb128> wgrant, thanks
[09:31] <Noskcaj> seb128, There's a few new git changes to make xchat-gnome a bit more stable, i'll try and get it sorted soon
[09:31] <nrbrtx> Dear all! I can't understand why Ubuntu does not have an init script for saving and restoring display backlight level. I have prepared one (see bug 1270579 ), it works on my laptops as expected. The 14.10 use systemd, which has systemd-backlight@.service for doing this out the box.
[09:31] <seb128> Noskcaj, thanks
[09:31] <seb128> Noskcaj, I don't especially care about xchat-gnome/we downgraded, it's just an example of work you created/where you didn't follow up after creating issues
[09:32] <seb128> Noskcaj, imho you should try to focus a bit more on quality and a bit less on getting new stuff in
[09:32] <Noskcaj> Will do
[09:51] <caribou> arges: patch sponsored
[12:00] <cjwatson> @pilot in
[12:01] <Laney> wow
[12:01] <Laney> how long have I been piloting ...
[12:01] <Laney> @pilot out
[12:18] <cjwatson> pitti: do you have any thoughts on the sanity of https://code.launchpad.net/~xnox/ubuntu-seeds/platform-init/+merge/225850 ?
[12:20] <cjwatson> doko_: could you please look at https://code.launchpad.net/~abone/ubuntu/utopic/bash/fix-1358827/+merge/231417 ?  it looks right to me ...
[13:28] <infinity> pitti: Really?  What an odd error message for that.
[14:28] <arges> caribou: thanks
[14:28] <caribou> arges: np
[14:45] <cjwatson> @pilot out
[14:54] <stokachu> @pilot in
[16:44] <LocutusOfBorg1> have a nice weekend
[16:46] <trifort> stokachu: can I ask a quick question about canonical employment
[17:03] <stokachu> trifort, im not equipped to answer those questions, thats more for our human resources department
[17:04] <trifort> stokachu: okay, thanks for your time. happy coding.
[17:28] <doko> mlankhorst, one last try to switch mesa to 3.5 now?
[17:30] <mlankhorst> erm isn't it on 3.5 now?
[17:35] <infinity> mlankhorst: Did you find your code generation issue?
[17:37] <mlankhorst> infinity: no but I guess it's because llvmpipe was generating sse2 instructions while llvm selected a cpu without sse2 support
[17:38] <infinity> mlankhorst: Sure, that's a reasonable assumption, but also something we need to fix, as Ubuntu i386 definitely supports CPUs without sse2 (or, indeed, without sse at all)
[17:39] <mlankhorst> infinity: yeah but i guess if no sse2 is supported things will work correctly because llvmpipe won't emit code using it
[17:41] <infinity> mlankhorst: Err, what?
[17:41] <infinity> mlankhorst: I'm not sure I followed your logic there. :)
[17:48] <mlankhorst> infinity: well with the autodetect logic in llvm removed, llvm's autodetect logic no longer matches llvmpipe's autodetect logic
[18:27] <tzero> Hello, I'm trying to package a cmake-built application that requires an override_dh_auto_configure. it looks like the original dh_auto_configure creates a build directory, changes to it, and runs the cmake $OPTS .. successfully, but in my overridden one, the pwd is reset after every command. Is there another step, or am I just doing something wrong?
[18:28] <tzero> also, I could work around it using subshells, e.g. (cd builddir;  cmake ..)
[18:28] <tzero> but that seems less-than-optimal
[18:29] <sarnold> tzero: every line of a makefile is executed in a new shell; perhaps add ; \ or similar at the end of each line? or a cd ... ; prefix before each line?
[18:32] <tzero> sarnold: ah, cool. that's expected then
[18:33] <sarnold> tzero: there may yet be a better solution :) might not hurt to hang around a bit
[18:33] <tzero> sarnold: the "default dh_auto_configure makes it look like each command is run in one shell, and my overridden one has "uglier" output
[18:33] <sarnold> hmm
[18:44] <dobey> tzero: what exactly are you trying to accomplish by running extra commands in an override_dh_auto_configure?
[18:44] <dobey> tzero: if additional things need to be done at configure time, why aren't they beng done as a result of cmake being run?
[18:45] <tzero> dobey: there are two; the first being that I have to regenerate some protobuf-c headers, and the second is just a define that I tried unsuccessfully to put in DEB_CMAKE_EXTRA_FLAGS
[18:46] <tzero> I agree, a patch to upstream is probably in order for at least the former
[18:46] <dobey> yes if something needs to be regenerated at configure time, it should be done by a rule in CMakefiles.txt
[18:48] <dobey> https://bazaar.launchpad.net/~ubuntuone-control-tower/unity-scope-click/trunk/view/head:/debian/rules
[18:49] <dobey> that might be helpful for seeing a workaround if DEB_CMAKE_EXTRA_FLAGS doesn't work for you (although depending on how you override dh_auto_configure, it might be appropriate that it doesn't work)
[18:51] <tzero> is the '--buildsystem cmake' the key there?
[18:52] <tzero> right now my override is just a list of shell commands as they would be run in the normal build tree
[18:53] <tzero> that might be sufficient until I can get a patch or two in upstream's next release
[18:54] <dobey> well the --buildsystem cmake might not be necessary; it's there in this file for historical reasons at this point (used to have multiple build systems in the tree)
[18:55] <dobey> the "dh_auto_configure -- -DFOO" is the important part for you
[18:59] <tzero> oh neat. that knocks off 8 lines of debian/rules :)
[19:03] <tzero> so, after a couple small PRs, this should be ready to go. Thanks a bunch!
[20:04] <smoser> slangasek, you able to tell me what i did wrong: https://bugs.launchpad.net/cloud-init/+bug/1377308
[20:05] <smoser> what i'm confused by is that somehow /run gets omunted on lxc container 100% of the time. but on kernel-only boot it seems to fail 100% of the time. and stgraber says that lxc is not mounting /run for me.
[20:26] <doko> pitti, jibel: how much RAM have the amd64 autopkg test machines configured?
[20:39] <stokachu> @pilot out
[20:45] <slangasek> smoser: so if you're booting with an initramfs, /run will always be mounted before the 'mounted' event for / is emitted
[20:45] <smoser> correct.
[20:45] <slangasek> smoser: if you're booting without an initramfs, I would have thought this was still the case, but I'm not sure it's guaranteed
[20:46] <smoser> but that is *not* the case in lxc.
[20:46] <smoser> whihc is what was confusing me.
[20:46] <slangasek> oh?
[20:46] <smoser> i could not reproduce in lxc. and stgraber says that lxc isn't mounting /run for me.
[20:46] <smoser> so /sbin/init is clearly running before /run is mounted
[20:47] <smoser> i ran lxc containers , literally thousands, and never saw failure.
[20:47] <slangasek> right
[20:47] <smoser> i think also related to lack of 'ro' on the command line.
[20:47] <slangasek> ah, yes
[20:47] <slangasek> or more likely, to whether the filesystem is mounted ro when init starts
[20:48] <slangasek> if lxc is giving you rw root at the start, then the mounted MOUNTPOINT=/ may come earlier
[20:48] <slangasek> er, oh; you said this problem was *not* reproducible in lxc, meaning that /run was mounted earlier in lxc?
[20:49] <smoser> in lxc , /run should not be mounted early.
[20:49] <smoser> i would thikn in lxc , its basically guaranteed that / is mounted rw at the start
[20:49] <smoser> but maybe that is wrong. maybe it is rw there.
[20:59] <smoser> well, there went that theory. booted image of amd64 with 'ro' and no 'ro' and neither hangs.
[20:59] <smoser> (with no initramfs)
[21:01] <slangasek> mm?  does that mean the bug is not reproducible?
[21:03] <smoser> not for me on amd64
[21:03] <smoser> it was reported (and i saw it and collected those logs) on arm
[21:04] <smoser> AArch64
[21:05] <smoser> so this is just more odd now.
[23:34] <fomenko_> hello
[23:34] <fomenko_> can anybodey see me?
[23:35] <sarnold> fomenko_: loud and clear :)
[23:35] <sarnold> it's just beyond end of the work day for most people..
[23:36] <fomenko_> i search for ubuntu developer
[23:37] <fomenko_> I have very big problem with ubuntu library architektur and search for projects that can fix this problems, and I found it, and I want that ubuntu have this technologie
[23:38] <fomenko_> on this site are the new technologie http://nixos.org/
[23:39] <fomenko_> I like the idea in this technologie but I want use ubuntu
[23:39] <fomenko_> and not switch to NixOS
[23:39] <infinity> fomenko_: I'm not sure that "I want Ubuntu to be NixOS but still be Ubuntu" will get much traction.
[23:40] <fomenko_> no
[23:40] <fomenko_> I mean the technologie of NixOs
[23:40] <infinity> Yes...
[23:40] <fomenko_> please visit the site and read
[23:40] <infinity> I know all about NixOS.
[23:41] <fomenko_> and why not in Ubuntu this technologie?
[23:41] <infinity> Suggesting that Ubuntu completely change its package and config management isn't something particularly feasible.
[23:42] <fomenko_> but if ubuntu not do it, I do it and make my own ubuntuNixOs, you dont need konkurent and I dont need so much work
[23:42] <infinity> You're planning to repackage literally everything we ship?
[23:42] <fomenko_> no
[23:43] <fomenko_> just use the technologie, but not using the exakt technologie from NixOs
[23:43] <fomenko_> it is just the idea of NixOs
[23:44] <infinity> fomenko_: The basic idea behind Nix (compartmentalised packages, with duplication of private dependencies) sort of goes against everything we do.
[23:45] <fomenko_> but it is very big trobbel behind this libs
[23:45] <fomenko_> you need the newes Ubuntu to use the newest software, because of the dependencys
[23:47] <infinity> fomenko_: Nix "solves" that by having multiple copies of each library in a private directory.  You can do that on Ubuntu just fine too.
[23:47] <infinity> I don't recommend it, but you can do it if you have to.
[23:47] <infinity> Ultimately, you'll suffer from the same issue they do, which is that security updates become a nightmare.
[23:47] <fomenko_> microsoft do it, and all things work fine
[23:47] <sarnold> "work fine" -- objection :)
[23:48] <fomenko_> and if microsoft solve this issju, why ubuntu cand do it?
[23:48] <infinity> Yes, Microsoft does it with winsxs, and it's also a security (and drive space!) nightmare.
[23:48] <fomenko_> jes, but it works
[23:48] <fomenko_> and ubuntu works not
[23:48] <infinity> I had a 120G SSD whose winsxs directory was 80G.  Not sure this is a solution. ;)
[23:48] <sarnold> a great many windows programs ship known-vulnerable shared libraries with their gigantic bloated installers -- you wind up with dozens of versons of libaries on your system, one from each horrible program, and some get fixes (the ones intsalled by microsoft components) and the rest don't get fixes...
[23:49] <sarnold> infinity: ouch :)
[23:49] <infinity> sarnold: Yeah, it's pretty ridiculous.
[23:49] <infinity> sarnold: Bad timing on Microsoft's part, IMO.  They dreamt up the winsxs solution literally a year or so before people started switching from spinning disks to SSDs and all their hard drives shrunk.
[23:50] <infinity> sarnold: So, the "disk is cheap" argument went sailing out the window.
[23:50] <sarnold> infinity: .. and we were all pushed towards ssds because the software was getting so bloated that we desperately needed faster load times :)
[23:50] <fomenko_> and why not develop a special datasystem that make only the changes of the libs binarry insert or overlayed, so we can save a lot of sapce, but all works
[23:50] <sarnold> see also: 80 gig winsxs directories
[23:51] <fomenko_> and why not develop a special datasystem that make only the changes of the libs binarry insert or overlayed, so we can save a lot of sapce, but all works
[23:51] <infinity> fomenko_: Why not just install a newer version of the library you need instead of having 17 copies of it?
[23:51] <infinity> fomenko_: Or build the software you want against the older library you have?
[23:51] <infinity> Neither of these is a problem.
[23:51] <fomenko_> because other programs need the older versions -_-
[23:52] <infinity> Only if the older version is also an older SONAME.
[23:52] <infinity> In which case, you have the old Ubuntu one installed, and the new one you wanted, and they don't clash.
[23:52] <fomenko_> and not all software are up to date and not all software are open sorce -_-
[23:52] <infinity> Because we're not Windows, "dll hell" doesn't exist in Linux, and you can have your cake and eat it too.
[23:53] <fomenko_> in linux are dependency hell
[23:53] <fomenko_> and linus torwald have tell this is a very big problem in linux, but NixOs technologie solve the problem
[23:54] <infinity> nixpkg solves the problem by creating another one.
[23:54] <infinity> It's a question of which problem you want to have.
[23:54] <infinity> We'd rather have the "problem" of having a reliably secure system.
[23:55] <fomenko_> I dont want install every jear a new version of my ubuntu, I just want use it, but I cant use it because if I want a new software I need the new dependencys, but if I install it I just cant use my other software, it is a very no go
[23:56] <infinity> fomenko_: You realise with something nix-like, you wouldn't magically get all the new deps you need, right?  You'd still need to either build or install them, and they'd, in turn, have their own new deps that need building or installing.
[23:56] <infinity> fomenko_: So, you wouldn't technically "install a new OS", but you'd have, effectively, several new OSes installed for every application.
[23:56] <infinity> At the end of the day, I'm at a loss as to what you think you've gained.
[23:57] <infinity> Except and excuse to buy a bigger RAID array.  Which is always nice, I guess.
[23:57] <infinity> s/and/an/
[23:58] <fomenko_> I think it is hopeles, I just try make somethink like a script that use all the dependencies from older ubuntu release and unsable release and I solve the problem I hope