[02:23] anyone has been used debootstrap? when i Use debootstrap to build the ubuntu core system, the system is not stable and often crash === micahg_ is now known as micahg [03:24] darkxst /etc/init.d/gdm seems to have some additional bugs in vivid (not trusty) than just the syntax error. Found this trying to test on vivid: http://paste.ubuntu.com/10496518/ [03:24] aeoril, that is expected [03:25] use restart (or stop gdm first) [03:25] darkxst really? just because the path used is different to the script? That seems kind of odd ... [03:26] aeoril, what are you talking about paths for? [03:26] you ran gdm start, and it said gdm already running [03:27] darkxst look at the paste - when I was testing, I tried to test using "./gdm" because I was in the /etc/init.d directory - it did not fail becasue of the syntax error. But typing "../init.d/gdm" from the same directory hit the syntax error - then, from the same directory, "/etc/init.d/gdm" gave the proper error message, but never hit the syntax error [03:27] aeoril, just fix the syntax error [03:28] darkxst that is fine, but shouldn't we be concerned about the odd behavior? [03:28] darkxst it doesn't act like that in trusty [03:28] aeoril, I don't recommend you step into that world [03:28] darkxst ok, I'll "keep it simple" then ... - just had anomalies during test, so figured I'd mention it to you ... [03:28] there a ton of wrappers that hook all the various init systems command together [03:29] darkxst yes, I went through some of them, loops, etc. [03:29] pretty complex [03:30] darkxst so don't even file a bug report? [03:30] aeoril, you could file a bug [03:30] darkxst I was definitely not thinking of fixing it myself ... [03:31] aeoril, no one cares about sysv (in Linux anyway) anymore [03:32] aeoril, I've been giving you trivial bugs so you can just concentrate on the packaging side [03:32] darkxst ok, just trying to be helpful [03:33] if you want a fun bug, thats more than just that, then bug 1385572 [03:33] bug 1385572 in upstart (Ubuntu) "gnome-session not shutting down cleanly" [Low,Confirmed] https://launchpad.net/bugs/1385572 [03:33] darkxst ok, I'll take a look at it, but I will finish this bug to learn the packaging side of things better [03:35] aeoril, btw invoke-rc.d is usually used for sysv scripts I think [03:35] and that should have a wrapper that would re-direct to upstart or systemd init (or whatever you boot with) [03:36] darkxst I will just do the syntax error fix then look at the next bug. I really appreciate all the help [03:37] darkxst I need to learn how to get a vivid fix back into 14.10 and 14.04 anyway [03:41] aeoril, https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB4QFjAA&url=https%3A%2F%2Fwiki.ubuntu.com%2FStableReleaseUpdates&ei=xtvzVKjEE8LbmAXZ2oHQDw&usg=AFQjCNFl9CrvGudijLLJ0UQ8dxx7Lj3WRQ&sig2=ht7tqyA-Zn9MmwlOf-demw&bvm=bv.87269000,d.dGY [03:41] silly google links: https://wiki.ubuntu.com/StableReleaseUpdates [03:42] darkxst good gosh! But it worked! Thanks ... :) [03:42] aeoril, I can upload gdm, so all you need worry [03:42] about is a debdiff and the SRU paperwork [03:42] ok - thanks [03:43] darkxst getting tired, work further tomorrow - that glitch took all my time hunting down the odd behavior [03:44] (it was not immediately apparent what was going on, so I was doing all kinds of crazy stuff devling into the scripts) [03:44] aeoril, those things come with experience [03:45] and wasting an enitre night chasing down a phantom bug, would be considered experience [03:46] I've certainly done that before [03:50] aeoril, our first realease was 12.10 and I spent the entire cycle fixing about 10 hard bugs [03:55] darkxst 12.10 was the first release of Ubuntu GNOME? [03:59] darkxst does Fedora still use GNOME as its default GUI? [04:22] aeoril, yes and yes [04:23] darkxst yes, I looked both answers up - the first release on releases.ubuntu.com is 13.04, though - I wasn't sure what you meant by "our first" - now I understand that what you meant a while back when you said "you should work on gnome" - you meant "Ubuntu GNOME" I guess [04:25] darkxst why not? You are the most helpful person for me, and I like it ok. I think it will be exciting to fix things in the desktop I have on my own pc. I could never get that with Windows or Mac [04:26] darkxst the whole FOSS thing is just amazing. When I was starting out way back, that kind of thing did not happen as much - some, but not a lot [04:28] aeoril, 12.10 was the first release [04:28] 13.04 was the first as an official flavour [04:29] darkxst yes, I figured it was something like that [04:29] darkxst thanks for the clarification, though [04:29] darkxst it is nice that it became an official flavour [04:29] aeoril, we founded ubuntu GNOME to get contributors working upstream [04:30] so work on GNOME fixing ubuntu bugs upstream kinda thing [04:30] darkxst I am sorry, I do not sure what you mean - do you mean fixing upstream GNOME bugs that cause problems specifically with Ubuntu? [04:31] aeoril, yes [04:31] darkxst yes, that makes sense. I really like the GNOME website - very professional. Seems like a well run project [04:32] darkxst well, I guess a whole "web" of interrelated projects really - it is very important to Linux, I think [04:32] aeoril, although it wasnt really that specific it was more just have people contributing upstream from GNOME on ubuntu [04:34] only problem is it has affected my time to work on upstream bugs [04:34] darkxst oh, I see - where do you work? [04:34] do you actually work for GNOME? [04:35] (for pay?) [04:35] aeoril, no, everyone on the ubuntu GNOME team is volunteers [04:35] oh, sorry - I thought you said "at work" not "to work" - my mistake [04:35] darkxst ^ [04:36] darkxst I thought "at work on upstream bugs" implied you actually worked for pay on the GNOME project or something [04:36] (but you said "to" not "at") [04:37] aeoril, no, distro patching every little annoyance is rubbish [04:37] darkxst lol ok, so pay to work means crappy work? You can't pick and choose? [04:37] some packages have close to 100 patches [04:37] wow [04:38] darkxst oh, I see what you mean - "distro patching" meaning fixing all the nit-noid things that need to be done for each distro [04:38] aeoril, nautilus has 20odd ubuntu patches which will be broken in 3.16 [04:39] aeoril, yes, mainly ubuntu though, they are the only distro visionary enough to produce their own product [04:40] darkxst what do you mean by "produce their own product?" Don't most distros have unique stuff in them? [04:40] (I just don't know) [04:40] aeoril, Unity? [04:41] darkxst yes, I thought you meant that ... [04:41] I don't know any other distro that ships their own DE [04:41] What does DE stand for? I cannot figure it out [04:42] Distro Environment? [04:42] aeoril, desktop-environment [04:42] darkxst oh, ok - duh! [04:42] gnome, kde, unity, etc [04:42] yes, I understand [04:42] I remember when Unity came out - it was GNOME or KDE before that ... [04:43] aeoril, it was GNOME2 [04:43] up until about 11.10 (at a wild guess) [04:43] right, the default was Gnome, IIRC - I did not like Unity when if first came out [04:44] darkxst yes, that rings a bell [04:44] Kubuntu, would have been around back then anyway (for kde) [04:44] darkxst I think you may have nailed it - 11.04 -> Gnome2, 11.10 -> Unity, IIRC [04:45] Back around 2011 I think [04:48] aeoril, yes gnome-shell has really evolved since those early GNOME3 days [04:48] darkxst yah, 2011 - I think it was when I was doing this (https://answers.launchpad.net/launchpad/+question/172028) - I think that was on "natty" [04:48] darkxst or maybe "precise" [04:49] darkxst yes, I was surprised at how much it had changed - I like the improvements [04:49] aeoril, what do recipes have to do with anything? [04:50] always seemed like a broken way to try things to me [04:50] darkxst lol - just what I was into ... learning all about packaging and recipes and stuff - I don't remember why I was all into recipes [04:50] darkxst I may have been directed that way, or I may have thought it was some kind of "correct" way of doing things or something [04:51] look at how broken UDD branches are and then they automatically building random git branches [04:51] UDD? [04:51] lp:ubuntu/ branches [04:52] aeoril, you already found that out right? [04:52] darkxst that project was a "learning" project to figure out packaging [04:52] darkxst yes, quite ... :P [04:52] recipes don't help with packaging [04:53] darkxst well, I was making a "super clean" package, and somehow making it work on the recipe led to some insights - I really don't remember all about what I was doing [04:53] in fact they only even make sense on stable (bug fix only) branches [04:54] darkxst unfortunately, I nuked that PPA (randconverse) - it was actually pretty funny - you had a "conversation" with the computer, and it said abusive, funny things to you randomly based on your inputs [04:55] darkxst it was in C++ [04:58] darkxst I got all into the debian policy guides, extensively into building a package from scratch using only autotools, manually configuring all the .am files myself, learning all about the debian directory and everything - I was really trying to learn packaging from the "ground up". However, I pretty much forgot all of it [04:59] darkxst well, building a "build" from scratch using autotools would be more correct, then adding in the packaging stuff for debian/Ubuntu myself [04:59] (its kind of coming back to me a little) [05:01] ok, but I don't see the connection between autotools and recipes! [05:02] darkxst I just don't remember ... maybe they were just separate things I thought I should learn about? [05:03] aeoril, ok keep learning and then maybe you can make the distinction! [05:04] darkxst Maybe I thought the "best" build environment was on launchpad using a recipe? [05:04] aeoril, and now you know that is sbuild ;) [05:04] darkxst that is what everyone says now! [05:05] was probably pbuilder back then though [05:05] darkxst yes, I was holding off using pbuilder until I learned the underlying stuff that pbuilder "hides" and makes easier ... trying to learn what was below pbuilder [05:06] pbuilder doesnt hide anything [05:06] darkxst well, I guess I just don't know what I thought I was doing then :( [05:07] yes you said that already ;) [05:07] darkxst maybe pbuilder automated things that I was trying to learn how to do automatically? [05:07] s/automatically/manually/ [05:07] aeoril, nope [05:08] pbuilder is very much like sbuild [05:08] i.e take a clean chroot, install builddeps, build packes [05:08] packages [05:08] hmmmm ... then I just probably didn't even know back then what the heck I was doing, I guess [05:09] darkxst yes, that makes sense [05:10] darkxst I seem to remember feeling I was making great progress, though, and "experts" were helping me a lot [05:12] aeoril, so make this your goal, find and a fix a bug that the "experts" can't fix ;) [05:14] darkxst I just want to learn, have fun and contribute to something worthwhile. And keep my skills up. [05:15] darkxst It would certainly be wonderful to become an "expert" though - really know this stuff well [05:16] darkxst with your help, I feel I have already come a long way, even just using Linux and understanding how it is put together [05:16] sarnold and others have helped me too [05:16] aeoril, but an expert in packaging or an expert in coding? [05:16] the first is largely generic and there are a bu [05:17] bunch of very expert packagers around this part that don't know any coding [05:17] darkxst I am much more interested at becoming an expert at coding Linux [05:18] aeoril, in which case you need to pick a project [05:18] darkxst but, I have to be a competent and preferably accomplished packager, I would think, to work with the community best? [05:18] darkxst I was thinking kernel/driver [05:19] aeoril, maybe not [05:19] darkxst but, you are the person who is helping me the most, so maybe I should go with GNOME because I need the help ... [05:19] darkxst why not? [05:20] aeoril, kernel code would be pretty scary for someone with no evidence of proper coding experience [05:20] darkxst I have no evidence of proper coding experience? [05:22] aeoril, I gues that is a little irrelevant, but open a random driver in the kernel and see if you can understand? [05:23] darkxst well, I am just wondering - in working with me, have you gotten the impression I have no coding experience? [05:24] aeoril, nope, because you haven't asked a single question about code I guess [05:25] aeoril, and really I won't judge that until I see a patch ;) [05:26] darkxst I have not been having a hard time following code, just using the tools (like git/bzr) and packaging. Of course, the code changes have been trivial so far [05:27] darkxst I made that one stupid mistake following the wrong code in the super-easy fix I am doing now, but oh well - it happens [05:27] (not seeing the syntax error in the vivid /etc/init.d/gdm script) [05:27] I was embarrassed about that one [05:28] aeoril, vala? [05:28] darkxst what about vala? [05:28] have you used it? [05:29] programmed even [05:29] darkxst no, never - there was vala in my first bug I tried to fix though, so I saw some of it [05:29] (the vim/gnome-terminal racey thing) [05:29] vte3 [05:29] gnome-contacts need a titlebar fix [05:30] probably similar to https://bugzilla.gnome.org/show_bug.cgi?id=745346 [05:30] I could try - bug? [05:30] Gnome bug 745346 in general "Use traditional title bars on Unity" [Normal,New] [05:32] darkxst my background is embedded and real time design, mostly, C, C++, FORTRAN, assembler, Ada, JOVIAL, etc. I think I was a reasonably competent programmer for all those years [05:32] bug 1339355 [05:32] bug 1339355 in gnome-contacts (Ubuntu) "Update to 3.14" [Wishlist,Triaged] https://launchpad.net/bugs/1339355 [05:33] Most recently, since 2011, I took a hiatus from learning about Linux development to learn about JavaScript/HTML5/CSS3 - that was fun, but I think I like this better [05:33] aeoril, you reliase gnome-shell/gtk is a funny combination of javascript and css? [05:34] darkxst nope [05:35] aeoril, there you go, gnome-shell UI is nearly entirely JS, and most all GTK theming is CSS (although generated from SASS now) [05:35] darkxst I really learned an incredible amount in a short time doing JavaScript/HTML/CSS - it opened up whole new ways of thinking for me. A wonderful experience [05:36] darkxst I did some GTK/GDK coding on my last job, maybe 10 years ago? [05:37] but just a littl [05:37] e [05:38] darkxst I have learned over time I am not a "great" coder, but I am good enough to make a solid effort and tend to be thorough and careful [05:40] darkxst I will never be a "star" but I believe I bring value and can contribute well [06:06] darkxst I was thinking about kernel/driver development because I have the most experience in C and have done quite a bit with low-level stuff interacting with hardware and firmware, or even writing firmware. Since that is where most of my experience lies, I thought that was the best choice for me [06:08] darkxst also, there seem to be some very good avenues to learn that stuff (kernelnewbies, osdev) so it might not be too bad [06:47] aeoril: yes, after checking out trunk you need to select a packaging backend; you can just ./setup.py build, that'll install the dpkg one [06:47] aeoril: I usually run PYTHONPATH=. gtk/apport-gtk [args] [06:49] aeoril: thanks for your MP! will look at it today, looks fine at first glance === kickinz1|afk is now known as kickinz1 [08:07] good morning [08:11] hey dholbach [08:12] hey hey seb128 [08:12] :-) === kickinz1 is now known as kickinz1|afk === kickinz1|afk is now known as kickinz1 [08:25] is there an automated way to change Maintainer: to XSBC-Original-Maintainer: and add Maintainer: Ubuntu Developers ? [08:26] it'd be easy to automate of course, but I wonder if it's something that's already in some tool [08:26] Mirv: it's called "update-maintainer" :) [08:26] ooh! :) [08:26] Mirv: in ubuntu-dev-tools [08:26] Mirv: it also DTRT for debian/control.in [08:27] thanks a lot! [08:49] Mirv: qtscript -2 from Debian will ftbfs on ppc64el, I have just uploaded a potential fix for that [08:50] (and also uploaded an untested fix for qtwebkit) === dbarth is now known as dbarth-afk === doko_ is now known as doko [08:55] pitti: are you looking at the autopkg test failures triggered python3-defaults? [08:55] doko: yes, some 10 mins ago [08:55] cool, thanks [08:56] infinity: speaking of which, it's not clear to me whether the upstart regression is induced by the new glibc, or if something else broke it [08:56] so I don't override that one for now [08:57] (although it probably isn't related to the new glibc) [08:57] mitya57: thanks, I noticed you were working on those right at the moment. [08:57] pitti: Given nothing changed in that libc (other than the compiler/binutils used to build it), the odds of a regression are pretty low. [08:57] pitti: But not nil. [08:59] not ok 54 - with single line command writing lots of data fast and exiting [08:59] wrong value for bytes, expected 3145728 got 3018031 [08:59] at tests/test_job_process.c:3886 (test_start). [08:59] jodh: ^ does that tell you anything? [09:00] that happened 4 times during the last 6 runs [09:00] pitti: But not 6 times? [09:00] infinity: right [09:00] but the history on http://d-jenkins.ubuntu-ci:8080/job/vivid-adt-upstart/ looks like that's something recent [09:00] pitti: Smells like an intentionally racy test meant to test accidentally racy code. :P [09:01] Even the name of the test sounds racy. [09:01] so, http://launchpadlibrarian.net/198971296/glibc_2.19-15ubuntu1_2.19-15ubuntu2.diff.gz indeed looks unrelated [09:02] * pitti waves through [09:02] pitti: Right, the diff is *obviously* unrelated, but that doesn't rule out the toolchain having produced a broken libc. Seems pretty unlikely that it would have produced whatever breakage we're seeing here, though. [09:04] * pitti leans on the retry button [09:14] pitti: Another example of why a static foo triggers bar mapping would be nice: linux uploads should trigger ubuntu-drivers-common tests. [09:15] infinity: yeah, I'm well aware of why this would be useful; new linux broke nvidia-304 [09:15] pitti: I wonder if a new header in debian/tests would be a good place to document such magic. [09:16] infinity: no, it's not; if we had an index of all debian/tests/control, we would do reverse test dependency checking [09:16] and as we don't, adding new fields there doesn't help either [09:16] pitti: So, that specific case is meant to be covered by some automated testing we're going to be doing to make dkms in general block the kernel. But still, it would have been awesome if u-d-c could have blocked it, which we could get with that sort of mapping. [09:16] we either need an additional external mapping in britney, or a Tests.gz index [09:17] pitti: Well, sure, a Tests.gz makes sense. But we still need a header to define "should be triggered by: foo" when it's not actually a direct dep of the test or package. [09:18] how is that not a Depends: ? [09:18] pitti: Well, I assume autopkgtest follows the same "don't need to depend on Essential", for instance. [09:19] s/, for/rule, for/ [09:19] right, you don't have to, but there's nothing stopping you from doing that once it becomes useful [09:19] But I guess you could just add explicit deps if you want the trigger, sure. [09:19] also, for this particular example, linux-headers isn't essential [09:19] No, true. linux-headers isn't. [09:20] So, fair enough. [09:20] Are you looking to have a Tests.gz produced by apt-ftparchive and published in the archive next to Packages.gz, or externally produced? [09:21] the former would be nice, but I'm not going to do that myself; I could envision a cronjob on people and put it into http://people.canonical.com/~ubuntu-archive/ somewhere? [09:21] And does debian/tests/control end up in control.tar.gz or data.tar.gz? Cause if it's the latter, that will be expensive. [09:21] no, debian/tests/control is per-source, it doesn't make sense in binary packages anyway [09:21] I'm guessing it's the latter, cause I doubt autopkgtest has ended up specced/supported in dpkg in any way yet. [09:21] Err, oh. Right. Derp. [09:21] Sorry, not away. [09:22] Nor awake. [09:22] so at most it could live next to Sources.gz [09:22] Check. That would be VERY expensive to generate, then. :/ [09:22] Since Sources.gz never unpacks source, it's just a concatenation of .dsc files, essentially. [09:22] but I think we should prototype it first on people.u.c., see what we need and how far we get with it, and then perhaps send lots of beer and flowers to cjwatson to put it into LP :) [09:23] It's not about beer and flowers, it's that there's no way I'd let the publisher be slowed down that much. [09:23] infinity: well, it's grepping Sources.gz for "Testsuite: autopkgtest", and unpacking a 1000 debian.tar.gz tarballs for debian/tests/control [09:23] Unpacking source is slow. Very slow. [09:23] right, you definitively don't want to do that 3 times an hour [09:23] maybe once a week or so [09:23] it's more like Contents.gz than Sources.gz [09:23] pitti: Not a guarantee that it's debian.tar.gz, not the whole world is v3(quilt). [09:24] infinity: yeah, for those cases you need to dpkg-source -x the whole thing [09:24] buit we can optimize for v3-quilt [09:24] pitti: infinity: that one tries to catch a race. I ponder if it should declare "skip" when it didn't manage to race. [09:24] pitti: Doesn't it become a bit useless if it's doesn't match the archive, since we care about testing the ever-changing -proposed pocket? [09:24] we could even optimize for a debian.diff.gz, but that'd be a bit hackish [09:25] xnox: Well, I assume it *did* race, and hence failed. [09:25] xnox: If it's testing (and finding) a bug in the code could we, I dunno, fix the bug? [09:25] infinity: obviously, the more current the better; that was just an initial idea for a prototype [09:25] a more "rolling" db would obviously be better [09:25] pitti: apt-ftparchive doesn't pull dirty tricks like that, generally, it's more about trusting dpkg to know how to deal with its own formats. This is usually saner. [09:25] whenever a source is uploaded, its debian/tests/control goes into that db [09:26] infinity: yeah, but really expensive [09:26] Quite. [09:27] pitti: But, since non-a-f archive probably need to know how to do this too, I guess we could attack it from a different angle and store tests/control on upload. We already waste a ton of cycles there unpacking and validating. [09:27] that sounds ideal indeed, as we wouldn't have to download and unpack anything in additon [09:28] pitti: Not sure how I'd spec that in a DAK world, though. And I do prefer universal solutions. [09:29] pitti: But in Soyuz, it would just become another source artefact, like .changes [09:31] pitti: And, derp. There's perhaps the real solution. [09:31] pitti: Add a dh helper to take all deps from debian/tests/control and concat them to XS-AutoPkgTest-Depends, so they end up in .dsc [09:32] pitti: And then if and when this gets specced in dpkg, dpkg-source can do it on its own without said helper. [09:32] pitti: Done, clean, and it lands in Sources.gz [09:32] Morning. I need some help please. [09:32] There are some critical glib 2.43.x compatibility issues in MATE. [09:33] The MATE Debian maintainers (of which I am a memeber) requested an unblock in Debian to provide the patches we've prepared. [09:33] infinity: dpkg-source already adds the Testsuite: header, so it could just as well add the new one [09:33] That request was denied. [09:33] infinity: I thought about that, it'd just inflate Sources.gz even more [09:33] So I need to add the required patches directly to Ubuntu. [09:33] I have the patches, have built and tested in a PPA. [09:34] How do I proceed? [09:34] pitti: Oh, does it? Wasn't sure if that was specced in dpkg or not. Sweet. That will make it much easier to get guillem to accept a patch for the Testsuite-Deps too. [09:34] pitti: A tiny inflation in Sources.gz is MUCH better than parsing source packages to generate yet another file. [09:34] infinity: https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=3e6253 and https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=db3c4ab FYI [09:34] pitti: Even if every source in the archive had a test-deps line, it wouldn't be that much more data. About the same as adding a new hash. [09:36] let's say 5000 packages, 100 bytes dep line == 500 kB uncompressed, perhaps 100 kB compresssed [09:36] not that bad indeed, but measurable [09:36] pitti: Yeah, not really a big deal, the archive grows faster than that for other reasons. [09:36] pitti: And "Sources.gz is getting large because everyone keeps adding testsuites to their packages" is a problem I kinda would like to have. [09:37] pitti: Normal users (despite RMS arguing viciously to the contrary) shouldn't have deb-src lines enabled anyway, IMO. [09:37] +1 on that [09:37] pitti: And certainly not users who care about how long updates take; they turn it off. [09:37] it's a pretty big waste of download bandwidth [09:37] 100 bytes? [09:37] dholbach, Have you the time to help point me in the right direction regarding glib2.43 patches? [09:38] Would most packages really have that many? [09:38] flexiondotorg, I would suggest asking in #ubuntu-desktop [09:38] wgrant: a wild guesstimated pessimistic average between a lot of packages just doing "Depends: @" and some needing a lot [09:38] flexiondotorg, I'm in the middle of 3 things right now [09:38] wgrant: Header plus lots of deps, might average out to more like 50 or 75, but whatever. [09:38] plus, the guys in #u-desktop are far more knowledgeable when it comes to glib than I am [09:38] wgrant: we also only have ~ 1300 tests, but the number has doubled every release for 4 releases neow [09:38] now [09:38] Either way, I don't think it's a big deal. [09:39] yeah, agreed [09:39] Sources.gz/.dsc feels like the right place for it. [09:39] It does. [09:39] And the code to do that is simple and clear. [09:39] dholbach, Thanks. [09:40] It does mean we don't get the benefit until those old source packages are rebuilt with a new dpkg-source, but I suspect 95% of tests are in the 5% of packages that are uploaded quite frequently. === Malsasa_ is now known as Malsasa [09:41] right; and in particular, we could upload ubuntu-drivers-common and glibc (i. e. the use cases which were particular important) [09:44] pitti: Right, I'm crazy tired, but can you file a bug on dpkg on assign it to me (or to yourself, if you're comfy with the perl in dpkg-source), and we'll discuss it with guillem too? [09:44] infinity: sure [09:44] pitti: Just copy-pasta some of the IRC log. :P [09:45] infinity: I'll file it to Debian BTS and CC: you? [09:45] pitti: Or that, I figured an LP bug to start with and we can work on the implementation in Ubuntu while talking guillem into taking it. [09:46] pitti: But we could just work directly in Debian, up to you. [09:47] pitti: I think there'd be value in us doing it ahead of Debian anyway, but obviously the biggest benifit is if it happens in Debian too, so we get the header in syncs. [09:47] infinity: right, so I thought we discuss it in a Debian bug, then implement it in Ubuntu, and send the patch [09:47] pitti: WFM. [09:47] but let's rather get agreement (or some input) from Debian first? [09:48] * infinity nods. [10:00] slangasek: thanks a lot for this post https://lists.debian.org/debian-devel/2007/02/msg00398.html [10:24] infinity: debian bug 779559, I CC:ed you [10:24] Debian bug 779559 in dpkg "dpkg-source: Add test dependencies to .dsc" [Normal,Open] http://bugs.debian.org/779559 [10:24] pitti: Ta. [10:24] bah, forgot wishlist, /me "bts"es [10:25] pitti: That should be Testsuite-Depends, I think, to match the existing Testuite: header. But I imagine guillem will make the same argument. [10:29] infinity: yeah, I don't care that much about the precise name === Malsasa is now known as Guest26491 === Malsasa_ is now known as Malsasa === kickinz1 is now known as kickinz1|afk === jamesh__ is now known as jamesh === MacSlow is now known as MacSlow|lunch === _salem is now known as salem_ [12:25] pitti ok, cool - I tried 'setup.py', and figured there was some command line argument to pass into it i was missing, but did not know what - I guess I should have looked at it better. That was a challenging one to test for me, since I did not know the way to do it directly with the source code I downloaded, but I made due ... [12:26] pitti you can see how I tested it in the MP comments [12:38] mvo, hey, is there any known issue with click/schroot/ecryptfs user directories? [12:42] "E: 10mount: umount: /var/lib/schroot/mount/click-ubuntu-sdk-14.10-armhf-ec6aaf62-31e0-47e9-b2f8-73f0b038fb4d/home/ubuntu: target is busy E: 10mount: (In some cases useful info about processes that E: 10mount: use the device is found by lsof(8) or fuser(1).) " [12:42] it's consistent here, it tries to unmount my real userdir for some reason, which of course doesn't work since I'm logged in with that user [12:52] Trevinho, Can you take a peek at this little merge proposal please? https://code.launchpad.net/~ubuntu-mate-dev/compiz/improved-compiz-mate-profile/+merge/251438 [12:52] * Trevinho on it [12:53] hi, anyone from ubuntu-archive around? I need someone to remove pycuda i386 binaries (LP: #1426722) please, they are blocking nvidia-cuda-toolkit. [12:53] Launchpad bug 1426722 in pycuda (Ubuntu) "Please remove i386 binaries" [Undecided,New] https://launchpad.net/bugs/1426722 [12:56] ginggs: done [12:57] cjwatson: thanks! [13:04] seb128: not know to me at least, no. [13:05] mvo, hey :-) [13:05] mvo, wie gehts? [13:05] seb128: good, thanks! and you? [13:05] mvo, I'm good, thanks :-) [13:05] seb128: if you could file a bug I will have a look [13:06] mvo, I can try to debug as well, http://people.canonical.com/~seb128/clickfail.log is my qtcreator framework adding log [13:07] mvo, but I also have an issue that the click schroot can't be unmounted, which leads to spam, since it restores previous sessions on reboot and adds a new one [13:08] seb128: oh, so this might be releated I wonder - i wonder if that also happens in a fresh install / clena chroot [13:09] mvo, clean chroot? I don't have any of those, I had purged schroot because of those issues and cleaned the dirs, just tried again, it fails to create any because it tries to unmount the real homedir for some reason [13:09] seb128: ok [13:10] mvo, tried to create one from another user on the same machine, which isn't using ecryptfs [13:10] seb128: and same result with that? [13:11] mvo, sorry, "trying", it's running [13:11] aha, ok [13:11] I can let you know in a bit :-) [13:11] ta [13:11] yw! [13:11] yeah, I'm debugging some different problem right now, but I'm >< close :) [13:11] (hopefully) [13:13] mvo, k, I'm going to try to debug the click issue myself, but help might be welcome if you are available for that later on [13:15] seb128: please tell me once you finished the test with the other user :) [13:19] Trevinho, Thanks. [13:33] cjwatson, Can you take a quick peek at this please? https://bugs.launchpad.net/ubuntu-mate/+bug/1426436 [13:33] Launchpad bug 1426436 in ubuntu-mate "15.04-Beta-1: Package 'grub-pc' has no installation candidate" [Undecided,Incomplete] [13:33] cjwatson, I can't reproduce this. Does this look familiar to you? [13:34] cjwatson, Am I missing something in my seeds? Could it be EFI related? I have no EFI hardware. [13:40] flexiondotorg: After lunch. [13:40] cjwatson, Thanks. [13:41] hmm, someone contacted me as xubuntu project lead and asked whether there is an easy way to download/get the full source of xubuntu14.10 (in order to run the code through fossology for license checking). frankly i have no clue, any of you got a pointer here? [13:47] didrocks: FYI, I updated bug 1312976 with some noninteractive commands how to set up a VM for nfs server+client [13:47] bug 1312976 in nfs-utils (Ubuntu) "nfs-utils needs systemd unit or init.d script" [High,In progress] https://launchpad.net/bugs/1312976 [13:47] didrocks: after that works, we can test server and client separately, but that should be good enough for initial testing [13:50] pitti: oh nice! I want to finish fsck+systemd autopkgtests first (the turnaround to get more complex issues dealt with the testbed installing lightdm is really slow), but then (I guess tomorrow), will jump on that! [14:02] flexiondotorg: It's broken because you turned off Recommends, and it works in Ubuntu because ubiquity Recommends: grub-pc. [14:02] (This is arguably a bit fragile ...) [14:03] flexiondotorg: I'd suggest http://paste.ubuntu.com/10501858/ [14:13] Mirv, Qt & GCC 5 ping [14:13] cjwatson, Thanks. [14:14] doko: the destructor related symbol changes coming via Debian for the 5.4.1 in landing in ~two weeks [14:15] flexiondotorg: I think you should put this on your list of reasons to get back to being able to enable Recommends [14:15] cjwatson, I am contributing patches to indicator-* to add MATE support so I can eventually disable the no-install-recommends feature. [14:16] cjwatson, Thanks for looking. [14:16] Mirv, cool, that's what I wanted to know [14:17] flexiondotorg: Cool. === MacSlow|lunch is now known as MacSlow === kickinz1|afk is now known as kickinz1 [15:10] xnox: heh, that was a while ago [15:12] slangasek: but i did answer "wtf nis is loaded" and the other statement about BenC is still true I guess =) [15:12] heh [15:12] ?? [15:26] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney [15:30] BenC: The context was https://lists.debian.org/debian-devel/2007/02/msg00398.html [15:31] Hehe [15:31]