[10:16] <AfC> jelmer: ping; I just hit http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644193 ; you suggest it is a bug in dpkg-source but I'm not clear on what to do about it. I'm just building packages as I always did, only now on Precise builddeb is failing
[10:20] <AfC> jelmer: is it now obligatory to commit your work-in-progress changes before calling builddeb?
[10:22] <AfC> Ok, so it works when invoked:
[10:22] <AfC> $ bzr builddeb --quick
[10:22] <AfC> but not when
[10:22] <AfC> $ bzr builddeb
[10:22] <AfC> (wtf)
[10:22] <AfC> weird
[13:04] <jelmer> AfC: hi
[13:05] <jelmer> AfC: you can no longer have changes in your working tree against upstream, all changes have to be in debian/patches
[13:05] <jelmer> AfC: you don't have to commit, as previously
[13:05] <jelmer> AfC: note that this is enforced by dpkg-source, not really related to bzr-builddeb
[13:42] <AfC> jelmer: that kinda really breaks the model we were using bzr builddeb under until now.
[13:42] <AfC> jelmer: we have a lot of code in our bzr branches :(
[13:44] <AfC> I wonder what the point of this change was. To force people to stop storing code in bzr?
[13:44] <jelmer> AfC: this has nothing to do with bzr
[13:45] <jelmer> AfC: it's a change in dpkg
[13:45] <AfC> jelmer: I realize it's dpkg-source that changed, but
[13:45] <AfC> jelmer: since it *completely screws* people using bzr-builddeb, it's perhaps a
[13:45] <AfC> jelmer: slight touch disingenuous for us to wash our hands of it.
[13:45] <jelmer> AfC: I think "completely screws" is an exaggeration
[13:46] <jelmer> AfC: you can either set an option in debian/source/local-options to force dpkg-source to not complain
[13:46] <AfC> jelmer: why? None of my packaging branches are building now. That counts as "blocker" in most bug trackers I've used.
[13:46] <jelmer> or manually put your patches in debian/patches (which you should be doing anyway)
[13:46] <AfC> [ok, good to know]
[13:47] <AfC> but why would we want to force people to put the changesets in debian/patches?
[13:47] <jelmer> AfC: I agree this isn't ideal, but anybody using dpkg-source in one way or another is hitting this
[13:47] <AfC> I mean, .debian.tar.gz contains the diff against upstream when packaged
[13:47] <AfC> so what's the harm [against enormous demonstrable benefit of using bzr{,-builddeb} to track code]
[13:48] <jelmer> AfC: ideally the changes against upstream should be split out in multiple quilt patches in "3.0 (quilt)"
[13:48] <AfC> [[I realize it wasn't you who changed dpkg-source]]
[13:48] <AfC> hm
[13:49] <AfC> (as far as I can tell, this has totally borked the importer on launchpad, too)
[13:49] <jelmer> AfC: which importer?
[13:49] <AfC> jelmer: http://package-import.ubuntu.com/status/ that importer
[13:49] <jelmer> AfC: previously dpkg-source would implicitly add a patch in debian/patches with the changes against the upstream source that were included in your working tree
[13:49] <AfC> (I could be wrong, of course, but virtually every package I care about is miles behind there, now)
[13:50] <AfC> jelmer: oh, didn't know that
[13:50] <AfC> jelmer: still, pretty annoying. I use bzr to manage changes to the code tree; the last thing I want to do is mess with quilt patches. If I was doing that, I might as well not be using ... bzr
[13:50] <jelmer> AfC: it was a conscious decision by the dpkg maintainers to stop doing that and to error out if there were changes in the working dir that weren't in upstream.
[13:50] <AfC> jelmer: fair enough;
[13:51] <jelmer> AfC: ideally we'd use bzr-loom and convert loom threads to quilt patches; that's still yet to emerge though
[13:51] <AfC> jelmer: but given that bzr-builddeb is a different (and novel, and [c.f. lifeless ← sabdfl] the whole point of "branches are the fundamental object")
[13:51] <AfC> jelmer: I'm a bit unclear why builddeb can't just do whatever it needs to do to trick out dpkg-whatever to get on with building the package.
[13:52] <jelmer> AfC: creating an implicit patch with the changes between upstream and your working tree, you mean?
[13:52] <AfC> jelmer: sure, why not
[13:53] <AfC> jelmer: implementation detail as far as I [the bzr-builddeb user who is happily managing deltas in bzr packaging branches] can see
[13:53] <AfC> jelmer: would have expected builddeb to take care of such minor details. After all, it takes care of about 15 other similar issues
[13:53] <AfC> jelmer: but instead, a *major* behaviour change has been imposed on the user base.
[13:54] <AfC> jelmer: I'm not saying its wrong
[13:54] <AfC> (after all, Debian policy decides such things)
[13:54] <AfC> but for your users
[13:54] <AfC> [ok, me]
[13:54] <AfC> you have just committed a *massive* API break
[13:54] <AfC> {shrug}
[13:54] <jelmer> AfC: right, but I really think you should take that up with the dpkg maintainers
[13:54] <AfC> in my world, if we did that to our clients we'd be fired
[13:55] <AfC> jelmer: but *bzr-builddeb* is the build chain we use. What goes on under the hood has (delightfully until now) been an implementation detail.
[13:55] <AfC> [and it's builddeb that just "broke" on us]
[13:55] <AfC> anyway, I appreciate you filling me in.
[13:55] <jelmer> AfC: so if you disagree with something in debian policy you would take it up with us too? That seems odd
[13:56] <AfC> is there a document somewhere that explains how we're supposed to migrate off using bzr-builddeb?
[13:56] <AfC> to be honest, I hadn't realized it was deprecated.
[13:56] <jelmer> AfC: huh, in what way is it deprecated?
[13:56] <AfC> jelmer: uh
[13:56] <AfC> jelmer: it doesn't work anymore
[13:56] <AfC> jelmer: in the way that we were taught to use it
[13:56] <jelmer> AfC: migrating away shouldn't require any special action - you can either convert the repository to a different format (such as git) or just remove the .bzr directory
[13:57] <AfC> jelmer: when a tool stops working
[13:57] <AfC> jelmer: we generally try to help people get through the migration
[13:57] <AfC> jelmer: [and we were taught to record changes to source trees in bzr]
[13:57] <AfC> jelmer: I have in turn taught numerous clients this practice. They're all screaming at me now.
[13:57] <jelmer> AfC: that makes sense for the 1.0 format perhaps, but certainly not for 3.0(quilt)
[13:58] <AfC> jelmer: I realize it's my problem for having convinced them to work in bzr, but still
[13:58] <jelmer> AfC: either way, you're doing Debian packaging and you're not just using bzr-builddeb but the entire set of debian packaging tools
[13:58] <AfC> a behaviour break like this was unexpected
[13:58] <jelmer> AfC: this has nothing to do with bzr
[13:58] <AfC> hence my asking if there's a document about how to migrate to new practices. I didn't see anything in bzr-builddeb's documentation
[13:59] <jelmer> AfC: the bzr-builddeb documentation documents bzr-builddeb itself, not debian packaging in general
[13:59] <AfC> jelmer: I get that; I've been packaging for Debian since 1997
[14:00] <AfC> jelmer: what I'm saying is that until now, bzr-builddeb allowed you to use bzr as the mechanism for tracking changes to upstream code trees.
[14:00] <AfC> jelmer: as far as I can tell, a fair number of people thought we were supposed to be using it that way. Apparently we were wrong. Fine.
[14:00] <jelmer> AfC: that still works for the "1.0" format I believe
[14:01] <AfC> jelmer: though, at this point, I'm now vague on how you are supposed to use it. You um... dpkg-source --commit first, then bzr commit, then, um ?
[14:01] <jelmer> AfC: there's no need to bzr commit
[14:01] <AfC> jelmer: so you're not allowed to make *any* changes in bzr?
[14:01] <AfC> jelmer: they all have to be done outside Bazaar?
[14:02] <jelmer> AfC: you're not allowed to make any changes in the working copy, dpkg-source barfs if there are changes not in debian/patches
[14:02] <AfC> Does it work like bzr or git? ie, does it have status and diff and commit?
[14:03] <jelmer> AfC: I don't think it does
[14:03] <jelmer> AfC: some of the git packaging tools have ways of converting these quilt patches to and fro branches
[14:03] <jelmer> which can make them a bit more convenient to work with
[14:05] <AfC> jelmer: so, what is bzr-builddeb used for now that you can't manage source changes with it? Just migrating existing packages between distro/releases?
[14:06] <AfC> jelmer: [I'd hate to be giving out wrong information anymore]
[14:06] <jelmer> AfC: FWIW I've personally never had local changes in the working tree with bzr-builddeb
[14:06] <AfC> jelmer: ah. That explains it
[14:06] <jelmer> AfC: that isn't to say that's not a valid way of working with it
[14:07] <AfC> jelmer: there's nothing like NOT using the tool like its authors do to really set you up for a total goat-screw.
[14:07] <jelmer> AfC: Sorry, but how have we set you up for that?
[14:08] <AfC> jelmer: because those current and former #bzr employees who taught me how to use builddeb included that practice in what they showed me.
[14:08] <AfC> jelmer: anyway, I'm willing to accept that I've been completely in the wrong
[14:08] <jelmer> AfC: And I've not said you're using it wrong, just that I'm not using it that way.
[14:08] <AfC> jelmer: and clearly need to mend my ways.
[14:09] <jelmer> AfC: I have no idea how lifeless, james_w, etc use it.
[14:09] <AfC> jelmer: certainly worth a very bitter blog post, though.
[14:10] <jelmer> AfC: if you were doing the same thing in git you would be hitting the same issue
[14:10] <jelmer> AfC: I still don't quite see how this is on bzr-builddeb rather than dpkg
[14:10] <AfC> Oh, wow. Now it's failing with "no such file or directory" on the patch I just committed with dpkg-source. Fun.
[14:11] <jelmer> AfC: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643037
[14:11] <AfC> jelmer: {shrug} I said already. Either a) we were using the tool in a legal way, in which case we've had a major user experience break, or b) we were using the tool in an illegal way, in which case it would have been nice if we'd had some warning that we were about to get in trouble.
[14:12] <jelmer> AfC: I agree with that, but $tool in this case is dpkg-source, not bzr-builddeb
[14:12] <AfC> jelmer: well, obviously I think you're wrong about that, but we can move on.
[14:13] <jelmer> AfC: I'd really like to understand why you think that's wrong
[14:13] <AfC> that doesn't seem to be the ubg
[14:13] <AfC> jelmer: if the scrollback doesn't do it, I'll send you a link to the blog when I write about it.
[14:13] <AfC> anyway, dpkg-source --commit succeeeded
[14:14] <jelmer> AfC: http://lists.debian.org/debian-devel-announce/2011/09/msg00001.html is the background of this
[14:14] <AfC> it's bzr-builddeb that's again failing, this time with a different error. I'll see what happens with a fresh build
[14:14] <jelmer> AfC: you can also go back to the 1.0 format, for which dpkg considers this an appropriate way of building
[14:15] <jelmer> AfC: if there is only one diff file, why are you using "3.0 (quilt)" in the first place?
[14:17] <AfC> jelmer: think about it, mate. *I* didn't pick that. I'm branching off an existing package. If they are using 3.0, then I am too
[14:17] <AfC> {shrug} this is the first package I hit this on, [it's gedit]
[14:18] <AfC> but this is the first packaging I've done since Precise came out
[14:18] <jelmer> AfC: right, so if they picked 3.0 (quilt) that has an effect on the workflow you have to use
[14:18] <AfC> so I see
[14:21] <jelmer> AfC: if bzr would simply be creating a single patch for all the changes in the working tree, then that would defeat the purpose of 3.0 quilt, which is used to split the diff up into separate logical chunks.
[14:21] <jelmer> I also believe that's why the dpkg maintainers changed the default to no longer generate a diff but to error out
[14:22] <AfC> jelmer: yeah I understand
[14:22] <AfC> jelmer: seems like a regression though
[14:22] <AfC> for the past year I've been using bzr to manage changes to packages
[14:23] <jelmer> AfC: you still can manage your existing packages with "1.0" source format
[14:23] <AfC> Now apparently I'll have to throw those branches out and go back to not using a VCS.
[14:23] <jelmer> AfC: what would you have us do for "3.0 (quilt)" ?
[14:23] <AfC> jelmer: yeah, most of our branches are of packages that are existing Debian packages, and most of them have migrated to 3.0
[14:24] <AfC> jelmer: {shrug} I'd have you force in a single diff
[14:24] <jelmer> AfC: so you would want bzr-builddeb to alter the behaviour in existing tools?
[14:24] <AfC> jelmer: I'm not submitting this packages to anyone. I'm just trying to build .debs
[14:25] <jelmer> AfC: looking through dpkg-source, it seems adding "auto-commit" to debian/source/options would prevent this error
[14:26] <AfC> jelmer: if that's a "bad" idea, then fine, we'll learn to get with the new way of doing it. Far be it for me to fight Debian policy. I'm just glad you were here tonight to explain to me that what we've been doing the last couple years isn't going to work anymore.
[14:26] <AfC> jelmer: to be honest, I've never used `dpkg-source` before, but then, I haven't used `dpkg-builddeb` directly in years either.
[14:26] <AfC> {shrug} builddeb was taking care of all that for us. It was delightful.
[14:27] <AfC> (er, -buildpackage. You know what I mean)
[14:27] <jelmer> AfC: yeah, debuild/dpkg-buildpackage/etc :)
[14:27] <AfC> so, like I said, it feels like a 5+ year regression.
[14:28] <AfC> jelmer: so, since I'm clearly so far off base using Bazaar to manage working trees, can I ask what you use bzr-builddeb for?
[14:28] <AfC> jelmer: and where you do your actual packaging work?
[14:28] <jelmer> AfC: Again, you weren't off base. "3.0 (quilt)" is incompatible with working-directory changes against upstream.
[14:29] <jelmer> AfC: I use it as an easy way to build, mostly as an alias for "debuild"
[14:29] <jelmer> AfC: occasionally to build historical revisions, and to get the orig source out of the packaging branch.
[14:29] <jelmer> AfC: http://raphaelhertzog.com/2010/11/18/4-tips-to-maintain-a-3-0-quilt-debian-source-package-in-a-vcs/ might also be of help
[14:32] <AfC> Hm. So I committed a patch with dpkg-source, but the build is still failing.
[14:32] <AfC> Back to the drawing board.
[14:34] <jelmer> AfC: how did it fail, are there any unknown files reported by 'bzr st'?
[14:34] <AfC> I haven't used Quilt since running Gentoo in about 2003
[14:35] <AfC> jelmer:
[14:35] <AfC> modified:
[14:35] <AfC>   .pc/applied-patches
[14:35] <AfC>   debian/patches/series
[14:35] <AfC> unknown:
[14:35] <AfC>   .pc/99-change-redo-accelerator.patch/
[14:35] <AfC>   debian/patches/99-change-redo-accelerator.patch
[14:35] <AfC> the failure is weird, though:
[14:36] <AfC> dpkg-source: error: cannot read gedit-3.4.1.orig.vU2NEG/debian/patches/99-change-redo-accelerator.patch: No such file or directory
[14:36] <AfC> what a strange filename
[14:38] <jelmer> AfC: you'll need to 'bzr add' the new files in debian/patches
[14:39] <jelmer> AfC: and either add the .pc directory or undo the changes from the working tree
[14:39] <jelmer> "QUILT_PATCHES=debian/patches quilt pop -a" should do the latter for you
[14:39] <jelmer> there might be a shorter way, but my 3.0-quilt-foo is kindof limited
[14:40] <AfC> jelmer: does bzr-builddeb do a `bzr export` under the hood, or just a copy of the current working tree [with changes]?
[14:40] <AfC> I thought the latter
[14:40] <jelmer> AfC: it does an export of the working tree
[14:41] <AfC> so I have to bzr commit the .pc stuff, *then* build?
[14:41] <jelmer> AfC: so unversioned files won't be included in the export, but modifications will be
[14:41] <AfC> oh, ok
[14:41] <AfC> [weird corner case]
[14:41] <AfC> you said "add"
[14:41] <jelmer> AfC: yes, you'll have to add them so they're versioned
[14:41] <jelmer> AfC: but they don't have to be committed - bzr just has to know about them
[14:42] <AfC> yeah
[14:42] <AfC> ok, so this is just charming :/
[14:42] <AfC> a) I used `dpkg-source --commit` to create a patch
[14:43] <AfC> b) I reverted the change in my working tree
[14:43] <AfC> c) added the aforementioned .patch
[14:43] <AfC> [`bzr add` that is]
[14:43] <AfC> which got me past the previous crash
[14:43] <AfC> and now I have a crash which is identical to that which started the whole conversation: aborting due to unexpected upstream changes
[14:43] <AfC> freaky :)
[14:44] <jelmer> AfC: which files does it claim have changed?
[14:44] <AfC> [I must admit I don't understand what the .pc files are doing, and seeing patches in diffs is always horrid to try and read]
[14:45] <AfC> jelmer: it doesn't say...
[14:45] <AfC> (reading the .build file)
[14:46] <AfC> jelmer: ok
[14:46] <AfC> jelmer: so it said
[14:46] <AfC>    .pc/applied-patches
[14:46] <AfC> jelmer: was modified
[14:46] <AfC> jelmer: I reverted that file
[14:47] <AfC> and now it's building
[14:47] <jelmer> AfC: the .pc directory contains the quilt state, so which patches are applied, which unapplied, etc
[14:48] <AfC> jelmer: I couldn't believe it had an entire copy of the original [unmodified] file in there.
[14:48] <AfC> jelmer: I mean, I thought we got away from that after Subversion :)
[14:48] <AfC> talk about primative.
[14:48] <jelmer> heh, yeah :)
[14:49] <AfC> and this is the brand new shiny Debian packaging format? Jeesh
[14:50] <AfC> jelmer: well, thank you for your help
[14:51] <AfC> jelmer: there's no way I would have navigated that by myself.
[14:51] <AfC> Major conceptual mismatch, to be sure
[14:51] <jelmer> AfC: anytime :)
[14:51] <AfC> I'll have to sit my team down and have a review of this, because we were planning to ramp up our use of the "old" way of doing things quite substantially.
[14:52] <AfC> They were quite enthusiastic about bzr as a result of what I'd showed them about comparing different branches
[14:52] <jelmer> I guess in a way it's indeed like a primitive version control system, and that's one of the reasons it's so hard to deal with it /and/ bzr, git or hg.
[14:52] <AfC> Seeing patches in VCS diffs is not exciting in the sightest.
[14:52] <jelmer> I've been meaning to play with some of the git debian tools (there are three equivalents to bzr-builddeb for git), apparently they do some smarter stuff than we do, like maintaining separate branches for each patch and automatically generating debian/patches from that.
[14:53] <AfC> Interesting
[14:54] <AfC> jelmer: I have no Git skills at all, which is becoming harder and harder to admit to people.
[14:56] <AfC> Bah
[14:57] <AfC> I can't believe I am about to commit a *patch* to a version control system.
[14:57] <AfC> Next they'll be telling me to commit binaries :/
[14:59] <jelmer> AfC: Git's UI is significantly better than what it used to be 5 years ago, it's really not too bad. I'm sure you could learn most of it in a couple of hours.
[15:00] <AfC> jelmer: well, I'm about to have to do a bunch of work against a git repo. I'm hoping I can get by using bzr to shuttle patches to my git clone. It's not clear to me yet whether bzr-git will let me push from there safely or not. Hard to experiment without [risking] making a big mess
[15:00] <AfC> we'll see
[15:00] <AfC> [I dog fooded Git for 6 months circa 2006. Ick. Oh well :)]
[15:02] <AfC> [back to packaging]
[15:02] <AfC> Wow, this is a horrid regression
[15:02] <AfC> so before when upstream released a new version and that code propegated to us via import-dsc and friends,
[15:02] <AfC> we would get those changes into our working tree and then could resolve conflicts and carry on.
[15:03] <AfC> Now my changes are *not* in the working tree, but instead in unapplied patches.
[15:03] <AfC> God, I hope I'm missing something obvious about all this.
[15:03] <jelmer> AfC: yep
[15:04] <jelmer> AfC: you can use quilt to try and fix up the patches afterwards
[15:04] <AfC> This is awful
[15:04] <AfC> Are you sure we can't just take our working tree and blat it down as a single patch before building binaries?
[15:04] <jelmer> it would be really nice if we could represent patches as branches here (and just "up-merge" the new upstream release)
[15:04] <jelmer> AfC: you can, but I'm not sure if your comaintainers will appreciate that, since they changed to 3.0(quilt)
[15:05] <AfC> jelmer: {shrug}
[15:05] <jelmer> AfC: I think "echo auto-commit > debian/source/options" will do that
[15:05] <jelmer> (and bzr adding that file)
[15:05] <AfC> jelmer: I differentiate pretty significantly between what we have to do to maintain *our* packages, and then shifting frame-of-reference and doing whatever is necessary to submit a patch upstream (or to downstream peer)
[15:06] <AfC> jelmer: ok, I'll look at that
[15:09] <AfC> jelmer: I'm just reading the man page for dpkg-source now
[15:09] <AfC> jelmer: there's a useful discussion under --single-debian-patch
[15:10] <jelmer> AfC: hmm, indeed
[15:11] <AfC> jelmer: so I'm starting to get it now. I see the difference between 3.0 ({native,quilt,git,bzr})
[15:11] <jelmer> AfC: (note that 3.0 (git) and 3.0 (bzr) aren't actually used in practice)
[15:11] <AfC> jelmer: right; I need to adapt to whatever is going on in the original package I've forked from
[15:12] <jelmer> I don't think I've actually seen a package that used either "3.0 (git)" or "3.0 (bzr)"
[15:12] <AfC> jelmer: though now that I understand, I think auto-commit would be the least disruptive. Have to test it. Certainly be more sensible locally.
[15:12] <AfC> [in the event of a 3.0 (quilt)
[15:12] <AfC> format package[
[15:13] <jelmer> AfC: yeah, looks like it
[15:14] <AfC> jelmer: I will definitely write this up
[15:14] <AfC> jelmer: thanks for your help
[15:14] <AfC> [trying that experiment now, while everything is open]
[15:17] <AfC> Build running
[15:18] <AfC> Nice. So I suspended the build, and looked in ../build-area/
[15:18] <AfC> There is indeed a new patch added to the end of debian/patches/series
[15:18] <AfC> along with a new patch file there
[15:18] <AfC> filename
[15:19] <AfC> debian/patches/debian-changes-3.4.1-0ubuntu2~afcowie2~precise2
[15:20] <jelmer> ah, cool :)
[15:20] <AfC> Raises an interesting issue, of course
[15:21] <AfC> Are the debian/patches applied in the bzr[-builddeb] working tree, or not?
[15:22] <AfC> Huh. It seems they *are* applied.
[15:22] <AfC> [great!]
[15:23] <AfC> jelmer: did you know that?
[15:24] <jelmer> AfC: yeah, they would have to be
[15:24] <jelmer> bzr exports the tree including the working tree changes
[15:24] <AfC> [and then dpkg-source unapplies them before building where it ... applies them? Head hurts]
[15:24] <jelmer> and then calls dpkg-source in the working tree. dpkg-source then generates a matching patch in debian/patches and makes sure the other patches are all applied
[15:25] <jelmer> AfC: I think dpkg-source unapplied all patches first so it can generate your auto-commit patches without including the changes from the other patches.
[15:25] <AfC> Remind me to use 3.0 (native) for my own work :)
[15:25] <AfC> jelmer: maybe
[15:25] <AfC> jelmer: I'm just pleased that bzr-builddeb's working tree includes the debian/patch series applied
[15:27] <AfC> jelmer: 01:30 local, time for me to pack it in. Business calls first thing tomorrow.
[15:27] <AfC> jelmer: Thanks for your patience.
[15:28] <AfC> jelmer: we definitely need to write this up. I'll show you the post once I've got it drafted; please feel free to offer critique or corrections.
[15:29] <jelmer> AfC: sure, it would be great to document this better
[15:29] <jelmer> AfC: good night!
[15:40] <hmmh> hi guys - was wondering if anyone can lend a helping hand - i have the bazaar "daily" builds going for our pkg, but when i install them, there is no binary?!
[15:40] <hmmh> what am i doing wwrong?
[15:44] <jelmer> hmmh: hi
[15:44] <jelmer> hmmh: does building the package on your local machine work?
[15:48] <hmmh> yes (i have not confirmed the last recepie - will check that now, thanks) but I have no err during build and so on .... hmm
[16:04] <hmmh> yes it does build/install no problem
[16:04] <hmmh> if tested locally
[16:09] <hmmh> .....but there is no binary as well in the local install ....this is definitely a wrong recipe - any help?
[16:35] <jelmer> hmmh: have you tried the recipe locally?
[16:35] <jelmer> hmmh: this kind of issue is generally just a bug in the packaging
[16:38] <hmmh> jemler: yes i tried it locally - but i have the same result - makes and installs a pkg ..but with no binaries..
[16:41] <hmmh> jelmer: my recepie has "nest-part packaging lp:~our/+junk/ourpkg debian debian" - is this correct?
[16:44] <jelmer> hmmh: that seems right
[16:45] <jelmer> hmmh: have you tried creating just the source package and seeing if that has the right contents?
[16:46] <hmmh> jelmer: when i create regular pkgs (not for daily builds, not using the "code brunch") - there is no problem installing and creating the pkg
[16:51] <jelmer> hmmh: recipe builds only create source packages, the binaries that are created afterwards are built from those source packages and are not in any way special
[16:52] <jelmer> so if this is a problem with the recipe, you should be able to find the issue in the source packages that are created by "bzr dailydeb"
[16:58] <hmmh> jelmer: which source pkgs? it creates the sources dirs and nests the debian dir under...... what just noticed is that in my control file i have " (1.3beta1-4ubuntu4) maverick; urgency=low"
[16:58] <hmmh> jelmer: could "maverick" be the issue
[19:47] <hmmh> hi, does anybody know how can i upload to my "code" from Git?
[20:08] <lifeless> what do you mean by your "code" ?
[20:11] <hmmh> well ... i would like to make a bazaar branch FROM a git repo..
[20:11] <hmmh> and then build daily pkg based on a receipt
[20:12] <hmmh> i meant recipie
[20:31] <lifeless> In Launchpad, or separately ?
[20:33] <hmmh> in launchpad
[20:34] <hmmh> I have a launchpad , I would like to clone a git repo, import that into bazaar and make daily builds based on it and continue to import new revsisions from the git master - is that possible ?
[20:34] <lifeless> you can use an import branch to get your code into bazaar
[20:35] <lifeless> https://help.launchpad.net/Code/Imports
[20:35] <hmmh> yep I saw that - so this is the only way - I have to request an official import?
[20:46] <lifeless> that or manage it yourself
[20:47] <lifeless> e.g. use git-bzr or bzr-git and cron and so on
[20:48] <hmmh> thank you for the answer - how do i use bzr-git? ant example?
[20:53] <jelmer> hmmh: 'bzr branch git://some/git/url bzr-import', if you have bzr-git installed
[20:56] <lifeless> hmmh: most folk wanting recipe builds do it all in Launchpad
[20:56] <lifeless> hmmh: as its easier
[20:56] <hmmh> jelmer: is that the preferred way, or you can use that as well - bzr git-import git://some/git/url  ?
[21:25] <jelmer> hmmh: bzr git-import imports all branches, 'bzr branch' just the current one
[21:26] <hmmh> jelmer: the current one , you mean the current revision of git?
[21:27] <hmmh> the last commit ?
[21:29] <jelmer> hmmh: the active branch
[21:30] <jelmer> hmmh: IOW, HEAD
[21:31] <hmmh> k, thanks
[21:34] <hmmh> jelmer: after i do "'bzr branch git://some/git/url" , can i import that directly - "bzr push lp:~ourlaunchpad" ?
[21:39] <hmmh> jelmer: and use it as a base, then get the pkging info from a different LP id? would that be ok to do? or not supposed to do it that way?
[21:42] <jelmer> hmmh: you can push to lp:~ourlaunchpad after you've imported, yes
[21:42] <jelmer> hmmh: a recipe can use branches owned by different users
[21:43] <lifeless> hmmh: the way you're meant to do it is use an LP code import + an LP hosted packaging branch, the owners of the two things can be different
[21:53] <hmmh> thank you guys
[21:58] <jelmer> hmmh: have you tried downloading the source package and seeing if that is correct?
[21:58] <hmmh> jelmer: this is the problem that we have - https://code.launchpad.net/~oisf/+recipe/testing-daily-2 - everything builds fine ... but when installed , there are no binaries - sorry to bother, much appreciated if you can share an oppinion.
[21:58] <jelmer> hmmh: have you tried downloading the source package and seeing if that is correct?
[22:06] <hmmh> yes ... when i get the source pkg , i get the tar.gz the .dsc everything is there...
[22:50] <jelmer> hmmh: in that case the recipe is unrelated - the recipe is only used to build the source package
[22:50] <jelmer> hmmh: after that, it's just the regular build process for source packages


[00:33] <TheMuso> Thats weird. I used zsync to update isos on the weekend and had no problem.
[00:37] <arand> TheMuso: Yea, it worked for me, on the cdimage server at least, if it working for you atm, or care to confirm Bug #775192 ?
[01:35] <highvoltage> slangasek: howdy. any chance of a keysigning party again at UDS-O?
[01:49] <cjohnston> lifeless: I have a bug that's been tagged apport-crash and has apport retracing since 4/8/11
[01:51]  * RAOF could do with actually getting into the strong set.
[02:09] <serge_> should this have happened?  I 'update from 11.04 to 11.04' using desktop cd;  it preserved /opt, but it wiped out /var/mail!  (I had a backup, but that seems a horrible decision)
[04:04] <Bsims> stupid question lsmod shows pcspkr is available but when I try to modprobe it in it shows module not available
[04:37] <slangasek> highvoltage: there's certainly chance for a keysigning party, but I have no energy to organize one this year :)
[04:38] <slangasek> ScottK: bug #764096> hngh, cursed chroots
[04:39] <ScottK> Since it's our default configuration, it kind of ought to work ....
[04:39] <slangasek> yes, yes it should
[04:40] <slangasek> come to think of it, I'm using postfix and haven't seen this problem, I wonder why it works for me
[04:40] <slangasek> but yeah, I'll poke the package
[06:31] <pitti> Good morning
[06:32] <pitti> jcastro: seems cjwatson beat me to it
[07:05] <micahg> hi pitti, could you please copy chromium-browser from -proposed to -security/-updates for lucid-natty (bug 771935)
[07:18] <pitti> micahg: will do in a bit
[07:19] <micahg> pitti: thanks
[07:26] <speakman> mornin' folks!
[07:28] <speakman> How does Debian/Ubuntu handles packages using /var/lib/package - is the directory specified in debian/ directory, or how does the package know that it has to mkdir it? My package using GNU Autotools.
[07:31] <StevenK> Likely specified in debian/dirs, and therefore created by dh_installdirs during the package build process.
[07:40] <speakman> StevenK: Looks like a proper place. Just wondering how pure Autotools packages creates the dir at "make install" time.
[07:42] <StevenK> speakman: My knowledge of autotools is sadly spotty, but I'd think they'd have a mkdir call in the install target
[07:45] <speakman> ok
[07:49] <speakman> looks like a install-data-hook target is the way to create it at install time
[07:49] <speakman> http://osdir.com/ml/attachments/txtA8gAhtcp1W.txt
[07:50] <RAOF> Do you need the directory to exist, or for the directory to contain a file - if it contains a file, just add it to an autotools install target.  Otherwise, install-data-hook is good.
[08:08] <cjwatson> doko_: it looks like you did a sync of db_5.1.25-10 but didn't flush it
[08:08] <cjwatson> doko_: (I guess we're just going to hope that the Java bits will cross-build now?)
[08:18] <dholbach> good morning
[08:19] <mvo> hey dholbach, good morning
[08:19] <dholbach> hey mvo
[08:20] <speakman> RAOF: Just to create the dir. Files will be created by the program when running
[08:20] <speakman> Is there a debhelper tool to upgrade packages from upstream?
[08:21] <dholbach> speakman, check out uscan and uupdate
[08:21] <speakman> dholbach: thanks!
[08:21] <dholbach> (a devscripts tool)
[08:22] <speakman> it's here. But no upgrades available on mcelog unfortently :(
[08:23] <speakman> (having sporadious machine check exceptions, causing kernel panics. very annoying)
[08:24] <RAOF> speakman: Yeah, then you probably want to use install to create the directory in the -data-hook.
[08:26] <speakman> and OnTopic again; the mcelog daemon doesn't start at boot, even though it's symlinked in /etc/rc[2-5].d/. Running /etc/init.d/mcelog start manually works perfectly. No entries in log either. Is there a way to look at startup messages in retrospectively, or do I have to reboot to see if there's any error?
[08:27] <speakman> RAOF: thanks alot, mate!
[08:28] <cjwatson> speakman: /var/log/boot.log
[08:29] <cjwatson> if anything was printed at startup, it should be thre
[08:29] <cjwatson> *there
[08:29] <speakman> cjwatson: wow, thanks!
[08:37] <pitti> mvo: is bug 767776 fixed in oneiric as well?
[08:39] <mvo> pitti: yes, let me update that, fixed with the most recent apt upload
[08:39] <pitti> mvo: nice, thanks
[08:51] <cdbs> pitti: ping, when does the 'copy of all SRUs to dev release' happen?
[08:52] <pitti> cdbs: in the first days of opening a new release, when the versions are still the smae
[08:52] <cdbs> pitti: So I guess it means, now/
[08:52] <pitti> I'm doing that for the first round of 0-day SRUs, as when they got uploaded it wasn't possible to do an oneiric upload
[08:52] <cdbs> ?
[08:52] <pitti> cdbs: right
[08:53] <pitti> we'll stop doing so for future uploads, though, to have the updates be built against the oneiric toolchain
[08:55] <pitti> cjwatson, SpamapS: FYI, I committed an sru-release script (using launchpadlib) into ubuntu-archive-tools, and disabled the one on cocoplum; so Clint can now release SRUs without shell access
[09:04] <cjwatson> pitti: noted, thanks
[09:05] <cjwatson> cdbs: I have already been copying SRUs to oneiric when I notice them
[09:05] <cjwatson> periodically, in bulk
[09:06] <cjwatson> I have a script that looks for packages newer in natty-updates than oneiric
[09:06] <cdbs> cjwatson: okay, thanks
[09:06] <cdbs> cjwatson: We don't move -proposed packages?
[09:07] <cjwatson> cdbs: I don't
[09:07] <cdbs> I thought it was done, I sure was wrong
[09:07] <cjwatson> I never have
[09:08] <cjwatson> other people may have done, or it may have happened in certain cases
[09:08] <cjwatson> I don't consider it obviously safe to do in bulk
[09:10] <pitti> I usually copy them to -updates and devel at the same time, i. e. when they got verified
[09:10] <pitti> it's easiest from a workflow perspective and reasonably safe
[09:10] <cjwatson> right, I think that's sensible
[09:10] <cjwatson> the ones that I catch with my bulk runs are generally security updates
[09:52] <speakman> Are there any predefined paths for autotools parameters in debian/ubuntu? like --sysconfdir is probably defined somewhere?
[09:56] <cjwatson> speakman: that depends on what tools you're using.  If you're using dh_auto_configure (usually via dh), then it defines several default parameters, yes.  See /usr/share/perl5/Debian/Debhelper/Buildsystem/autoconf.pm
[09:57] <cjwatson> There are no universal defaults because debian/rules is entirely entitled to call ./configure directly if it likes.
[10:03] <talat> Hi i want to rebuild/repackage python2.6 package. is it possible ?
[10:04] <speakman> cjwatson: thanks alot! again! :D
[10:07] <tumbleweed> doko_: talat wants http://bugs.python.org/issue1813 fixed in python2.6 (apparently you applied a patch for it in python2.5)
[10:08] <talat> doko_: yes i want to apply isssue1813 patch in 2.6
[10:08] <talat> doko_: and other newer version :(
[10:09] <talat> doko_: is it possible ?
[10:10] <tumbleweed> talat: with most packages i'd say just post a patch and go through the sponsorship process, but for python you probably want to talk to doko (although he may not be around right now)
[10:11] <talat> tumbleweed: ok. Thnx. I will wait doko :)
[10:49] <seb128> is there anything that need to be run manually to get germinate datas on the ubuntu-archive people page for oneiric?
[10:49] <seb128> (just asking because the ubuntu-desktop version tracking use those to determine what to list in the desktop set)
[10:51] <cjwatson> seb128: oh, I forgot to update that script.  done now
[10:51] <cjwatson> you'll get output in a couple of hours or so
[10:52] <seb128> cjwatson, thanks
[10:52] <cjwatson> I'll create oneiric package sets tomorrow
[10:52] <cjwatson> (not actually at work today despite appearances)
[10:54] <lucidfox> seb128, have you seen that email about easytag?
[10:56] <seb128> lucidfox, hi, sort of, I read through it quickly, I've not been maintaining easytag for some years and I've no real opinion so whatever people thing is right just do it
[10:56] <lucidfox> ahh
[11:05] <drdozer> hi - I just upgraded to natty using the upgrader in maverick via kde
[11:06] <drdozer> now I can´t boot
[11:06] <drdozer> I
[11:06] <drdozer> I´ve not had any feedback in #ubuntu so thought I´d ask here
[11:06] <drdozer> error: symbol not found: `grub_env_export´.
[11:06] <drdozer> grub rescue>
[11:21] <lucidfox> seb128, my idea is to rebase easytag to stsquad's github fork as the new upstream, since the sourceforge version is basically dead. And if you have no time to maintain the package on your own, you could perhaps contribute it to the Debian Multimedia team
[11:22] <seb128> lucidfox, you are welcome to take over the package and put it under debian multimedia if you want
[11:22] <lucidfox> Okay, thanks
[11:27] <seb128> is there any known issue with qt softwares and systray?
[11:28] <seb128> we received some gnome-panel and unity bugs about systray icons being 1 pixel icons, seems specific to qt applications, I'm wondering if that could be a Qt issue
[11:32] <directhex> am i the only person using natty with a laptop plugged into an external monitor, with the internal laptop screen turned off? and by "using" i mean "failing to use"
[11:33] <RAOF> directhex: What's broken about that?
[11:34] <seb128> likely bug #737891
[11:34] <RAOF> directhex: If I were to guess that your external monitor stops updating when you turn off the internal monitor, would that be correct?
[11:35] <RAOF> Ahh, Intel.  Where would we be without your modesetting bugs.
[11:38] <directhex> RAOF, as soon as i log in, BOTH screens go blank? and if i badger it into letting me in by un-docking during login, as soon as i disable the internal screen, BOTH screens get disabled
[11:38] <directhex> seb128, similar, but i'm using displayport not vga. so my symptoms are different
[11:39] <RAOF> directhex: Then you're probably seeing…
[11:39]  * RAOF hunts for the Arrandale+DP black screen bug
[11:42] <RAOF> directhex: That might be bug #745112 but I recall another one that's DP specific.
[11:43] <directhex> RAOF, i'm reading that one, but i'm not exceeding the intel 4096x4096 limit
[11:43] <RAOF> directhex: The take home message?  drm-intel-next-proposed kernels from our friend the kernel team PPA are quite likely to fix the problem :/
[11:44] <directhex> 771344 ?
[11:44] <directhex> i'll try a newer kernel from that ppa
[11:55] <directhex> a desktop!
[11:55] <directhex> first time!
[11:55] <directhex> it didn't even apply my thinkpad ICC profile to my dell monitor this time!
[11:56] <RAOF> :)
[13:12] <dupondje> the Ubuntu MoM isn't updated anymore ?
[13:18] <pitti> it's supposed to update, but apparently got stuck
[13:19] <dupondje> give it a kick :)
[13:19] <pitti> -EPERM
[13:19] <pitti> (and -ECLUE too)
[13:22] <mvo> dupondje: just having a look, but it seems like its just very busy
[13:22] <mvo> dupondje: i.e. lots and lots to work on
[13:24] <dupondje> The html pages are updated 17-Apr-2011 23:02
[13:24] <dupondje> but dirs are indeed up-to-date it seems
[13:24] <Sweetshark> seb128, pitti: http://sweetshark.livejournal.com/857.html
[13:26] <pitti> \o/
[13:27] <diwic> Sweetshark, hmm, headline says "10.04"
[13:27] <Sweetshark> diwic: thanks.
[13:29]  * Sweetshark mumbles something about breaking things with last minute changes being never a good idea.
[13:29] <Sweetshark> diwic: fixed.
[13:29] <diwic> Sweetshark, it's all about fixing errors :-)
[13:58] <dupondje> Any idea when Gnome3 gets pushed into Oneiric ? :)
[14:03] <dholbach> dupondje, check out the oneiric-changes list - a lot of 3.0 gnome stuff got uploaded already
[14:37] <doko> janimo: could you make the rebuilt apt available somewhere?
[14:39] <janimo> doko, I will shortly
[14:47] <mvo> janimo: oh?
[14:47] <mvo> janimo: its just a rebuild that is needed?
[14:47] <janimo> mvo, ARM only. Relax :)
[14:47] <mvo> I was just looking into it on the porter machine but its *slow*
[14:48] <mvo> so did not get even close to diangosing it
[14:48] <mvo> janimo: what is the issue? gcc-4.6 incompatible changes?
[14:48] <janimo> mvo, I do not know yet, the only thing so far is that a rebuild with -O0 does not crash
[14:49] <mvo> janimo: cool, thanks!
[14:49] <janimo> it crashes in libapt-pkg in some printf-sytle function. If -fshrink-wrap was not disabled until fixed I would suspect that
[14:50] <doko> janimo: hmm, is shrink-wrap in Linaro 4.6 at all?
[14:51] <janimo> doko, no idea
[14:52] <doko> janimo: please wait with an upload until we know the reason
[14:55] <janimo> doko, I am not uploading anything
[14:56] <janimo> especially since I don't see how it will not FTBFS itself. Would it not?
[15:01] <doko> janimo: sure, but even a manual build would require an upload
[15:01] <janimo> doko, right
[15:48] <pitti> barry: hey Barry, how are you?
[15:48] <barry> pitti: hi, good, and you?
[15:49] <pitti> barry: quite well, thanks! successfully moved to Augsburg over the weekend
[15:49] <barry> congrats!
[15:49]  * barry looks up augsburg
[15:50] <pitti> barry: Tomeu just asked whether you would have an opinion about my patch in gnome bug 649165
[15:54] <Sweetshark> pitti: augsburg? try not to forget how to speak proper german then ...
[15:55] <pitti> Sweetshark: FSVO "proper" -- I'm from Saxony
[15:58] <barry> pitti: hi okay, i'll take a look
[16:01] <Sweetshark> pitti: hehe, that has not gone unnoticed when we had some phone calls.
[16:01] <pitti> Sweetshark: nu glar
[16:12] <stgraber> Laney: ping
[16:13] <stgraber> Laney: can you update https://blueprints.launchpad.net/ubuntu/+spec/other-o-dmb-meeting to be something else than "Complete" ? that might be why it doesn't appear on the schedule ...
[16:17] <barry> pitti: i have some comments
[16:17] <stgraber> jono: ping
[16:17] <jono> stgraber, hey
[16:18] <barry> pitti: let me know when you're ready :)
[16:18] <stgraber> jono: do you have a sec to look/approve two UDS specs in the community track ? https://blueprints.launchpad.net/edubuntu/+spec/community-o-debian-edu-edubuntu-collaboration and https://blueprints.launchpad.net/ubuntu/+spec/community-o-edubuntu
[16:18] <jono> one sec
[16:18] <stgraber> jono: they have special scheduling needs but I'll take care of that once they hit the summit website
[16:18] <jono> stgraber, done :-)
[16:20] <genis> hi
[16:20] <genis> apparently for python-qt4-sql there is no support for postgresql
[16:20] <genis> QSqlDatabase: QPSQL driver not loaded
[16:20] <genis> QSqlDatabase: available drivers: QSQLITE QMYSQL3 QMYSQL
[16:21] <genis> from the defaul deb packages
[16:21] <genis> on 10.10
[16:21] <DoctorPepper> hi  guys!!!
[16:21] <genis> where can I find out if it will be supported
[16:21] <genis> in a future update?
[16:21] <pitti> barry: perhaps we should discuss that in the bug, so that the upstream guys can follow?
[16:22] <Laney> stgraber: do you mean 'informational'?
[16:22] <stgraber> jono: thanks!
[16:22] <jono> :-)
[16:23] <stgraber> Laney: I'd at least change the "Complete" status for something else as I doubt completed specs appear on summit.u.c, changing to something else than informational may also be a good idea
[16:23] <stgraber> I don't know the exact criteria, but the current spec is approved and wasn't imported on summit.u.c, so something is wrong :)
[16:23] <Laney> I can't edit the Status bit
[16:23] <barry> pitti: okay.  i'll go get an account :)
[16:24] <Laney> but I changed Implementation and it made Status go to 'Not started'
[16:24] <Laney> we'll see what that does
[16:24] <pitti> barry: oh, you don't have one? thanks
[16:24] <barry> pitti: actually, i do!
[16:25] <stgraber> jcastro: ^ can you change the status ?
[16:27] <jcastro> stgraber: on it
[16:28] <stgraber> jcastro: thanks
[16:40] <barry> pitti: comment posted
[16:40] <davidm> jcastro, we need to send map info to proximalabs folks or should we just skip map info?
[16:41] <jcastro> davidm:  wait I thought marianna sent you a map?
[16:41] <jcastro> let me reping
[16:43] <davidm> jcastro, I can't find an email with a map attached
[16:45] <hallyn> SpamapS: re bug 719448, when you say 'accepted to sru', does that mean you're pushing the package, or that you're waiting for me to push the fix to lucid-proposed and maverick-proposed and you'll allow it when I do?
[16:45] <jcastro> davidm: I have a PDF they sent me on april 1st that I forwarded to you that day, do you have that?
[16:55] <pitti> barry: ah, thanks!
[16:56] <pitti> barry: so you generally agree to the approach, just the implementation could be more robust?
[16:58] <SpamapS> hallyn: that means its accepted for the series as a valid SRU (as opposed to being too intrusive for instance)
[17:01] <hallyn> SpamapS: do i need to push the package to the -proposed archives?
[17:02] <SpamapS> I swear, UDD is just plain broken. :( 50/50 chance the package branch will be out of date
[17:02] <SpamapS> http://package-import.ubuntu.com/status/bash-completion.html#2011-03-15 20:29:05.392361
[17:03] <SpamapS> hallyn: yes thats the typical workflow (step 4 at https://wiki.ubuntu.com/StableReleaseUpdates :)
[17:03] <SpamapS> james_w`: is there anything someone in my position can do to improve UDD? Should I be manually importing/fixing branches?
[17:07] <hallyn> SpamapS: james_w`: yes, that's been killing me lately.  bzr checkout rarely gives me the actual current archive copy
[17:09] <hallyn> SpamapS: yeah, sorry, i'm to queezy about uploading things.  will push those then, thanks much.
[17:09] <SpamapS> hallyn: its good to be hesitant in this case. :)
[17:14] <jcastro> davidm: ok she sent one better than what I sent you before, in your inbox.
[17:14] <davidm> jcastro, thanks I'll forward now to proximalabs
[17:15] <jcastro> sorry about that I thought I had closed that loop
[17:23] <j1mc> pitti: i have marked you as an approver for my blueprint, but i'm not sure if you're the right person. i picked you because you were signed up as the approver for several desktop-* blueprints.
[17:23] <j1mc> pitti: here's the link: https://blueprints.launchpad.net/ubuntu-docs/+spec/desktop-o-ubuntu-docs-strategy
[17:23] <j1mc> if someone else should be assigned, please feel free to re-assign
[17:24] <jcastro> davidm: any idea when the app will suck in the schedule?
[17:27] <dupondje> thanks to the guy who fixed the MoM :)
[17:34] <stgraber> pitti: for bug 436936 should I upload the suggested fix to Oneiric for both gdm and kdebase-workspace and upload the same to natty-proposed for testing (bug will need extended testing with a range of graphic cards to make sure we don't get any regression)
[17:35] <dupondje> somebody should accept openssl into oneiric :) cant build half of packages because of it now :)
[17:36] <micahg> dupondje: it's in binary new
[17:38] <dupondje> micahg: I know. but pbuilder can't build alot now because ca-certs depends on it
[17:41] <micahg> jdstrand: do you have time to look at openssl in binary new?
[17:42] <jdstrand> micahg: not atm-- possibly later today (another aa who is on duty today may be able to)
[17:42] <jdstrand> micahg: that said armel is ftbfs
[17:42] <micahg> jdstrand: ugh, should that be fixed before going through binary new, it's blocking most of the archive?
[17:43] <jdstrand> micahg: meh
[17:43]  * jdstrand looks
[17:43] <jdstrand> it is a weird error in armel, I don't know how to fix it. might be a chroot problem
[17:43] <micahg> jdstrand: I only pinged you in case it needed some sort of security team review, was going to ping the AA on duty
[17:43] <jdstrand> lamont: ^
[17:44] <lamont> it's arm.
[17:44] <jdstrand> micahg: cjwatson did the upload, so I don't think it needs anything special
[17:44] <micahg> jdstrand: k, I'll ping another AA
[17:45] <jdstrand> micahg: I'm already doing it
[17:45] <micahg> jdstrand: oh, heh, sorry then, but thanks :)
[17:45]  * jdstrand was thinking the armel thing would need to be fixed, but since it is blocking everything, let's not
[17:47] <lamont> apparently apt needs a recompile to survive what 4.6 did to it
[17:48] <lamont> so don't expect oneiric arm builds until I get poked to do the bootstraporama
[17:49] <lamont> jdstrand: and it'll require me to deal with it
[17:49] <lamont> for some value of "me"
[17:49] <stgraber> Laney: ping
[17:50] <Laney> stgraber: hi
[17:50] <stgraber> Laney: hi, spec still didn't appear on the summit website ... can you try setting Definition to new maybe ?
[17:50] <Laney> haha
[17:50] <Laney> maybe someone can tell us how this was done in the past? ;-)
[17:50] <stgraber> Laney: scheduler should run in 10 minutes, if it still doesn't appear, I'll just add it manually in the DB :)
[17:52] <stgraber> Laney: comparing with other specs I registerd and that got approved, only the Definition is different, so if changing it doesn't work, I don't know what will :)
[17:53] <j1mc> stgraber: you might not be the right person for this, but i think i registered my blueprint under the wrong project. i can't change the project, should i just create a new one, and mark the old one as superceded?
[17:54] <j1mc> stgraber: here's the link: https://blueprints.launchpad.net/ubuntu-docs/+spec/desktop-o-ubuntu-docs-strategy  if you go to https://blueprints.launchpad.net/ubuntu-docs/ it says, "Launchpad does not know how Ubuntu Documentation tracks feature planning or documentation."  that the project
[17:54] <j1mc> which isn't good.  : )
[17:54] <stgraber> j1mc: don't you see a "re-target" button ?
[17:54] <jdstrand> lamont: heh, ok :)
[17:54] <stgraber> s/button/link/
[17:54] <j1mc> yep
[17:54] <j1mc> ah, got it... thanks.
[17:55] <stgraber> yeah, for whatever reason it's not in Edit details :)
[17:55] <j1mc> i thought that might be just for re-targeting to a new sprint or release milestone
[17:56] <stgraber> Laney: did you change the Definition to new ? scheduler is supposed to run in ~5 minutes
[17:57] <Laney> stgraber: rushing, lost network
[17:58] <Laney> done
[18:00] <jdstrand> micahg: done
[18:01] <micahg> jdstrand: thanks
[18:01] <jdstrand> sure
[18:01] <stgraber> Laney: thanks
[18:02] <micahg> dupondje: openssl should be done, there might be other issues though
[18:06] <Laney> stgraber: no good?
[18:06] <stgraber> Laney: just appeared on the schedule!
[18:06] <stgraber> I'm going to move it to the right slot now
[18:08] <stgraber> Laney: ok, scheduled at 16:15 in a 20 slots room. Now to solve the conflicts :)
[18:11] <Laney> :-)
[18:18] <stgraber> Laney: we still have multiple conflicts but next run of the scheduler should move some stuff around to fix that
[18:25] <ScottK> Did someone look into perl 5.12?
[18:25] <ScottK> I'm not volunteering to do it, but with the transition started in Debian, I think the sooner the better.
[18:27] <SpamapS> ScottK: nah, lets just hold off until 6.00 ;)
[18:27] <ScottK> Python3 will be default befor that happens.
[18:33] <stgraber> ScottK: I'm currently looking at bug 436936 and preparing the new upstart job for kdebase-workspace. Is that something you want uploaded to Oneiric as soon as it's ready or do you prefer to wait until someone has something else to upload ?
[18:34] <ScottK> stgraber: kdebase-workspace is a huge build.  It's probably better just to commit it to bzr.
[18:35] <stgraber> ScottK: what's the right place to commit that ? apt-get showsrc tells me lp:~kubuntu-members/kdebase-workspace/ubuntu but bzr tells me it doesn't exist ...
[18:35] <ScottK> stgraber: Should be ~/kubuntu-packagers.
[18:35] <ScottK> We just moved them and the packages aren't updated yet.
[18:35] <ScottK> You should have access there.
[18:36] <stgraber> ok, I'll also make sure debian/control has the rights Vcs field then :)
[18:57] <kees> jcastro: how do I mark a blueprint to _not_ be auto-scheduled for UDS? i.e. I want to keep it as a work-item tracker but not have discussion.
[18:58] <slangasek> kees: have it rejected for the sprint
[18:58] <slangasek> it can be targeted to oneiric without being accepted for uds-o
[18:58] <jcastro> kees: what he said ^
[18:58] <kees> slangasek: ah-ha! okay
[19:03] <stgraber> ScottK: ok, pushed to ~kubuntu-packagers/kdebase-workspace/ubuntu/. Was just wondering how you're dealing with SRUs though as I noticed a natty-proposed changelog entry in that branch (not sure you want to mix -proposed and oneiric changelog entries)
[19:04] <ScottK> stgraber: We normally just keep a 'trunk' so building you change on top of natty-proposed is good.
[19:30] <SpamapS> hmmm.. LP shows openssl 1.0 in oneiric, but my mirror does not..
[19:30] <Laney> it is/was in NEW
[19:31] <SpamapS> DOH
[19:32] <SpamapS> https://launchpad.net/ubuntu/oneiric/+queue?queue_state=0&queue_text=openssl
[19:32] <SpamapS> maybe just need to wait for a mirror update?
[19:32] <micahg> SpamapS: yeah, it was freed about 90 minutes ago
[19:32] <SpamapS> AH
[19:32] <SpamapS> where is that time? the package in LP says 17 hours
[19:33] <micahg> SpamapS: check scrollback here :)
[19:33] <SpamapS> doh
[19:37] <maco> pitti: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/494141 im lost. a 10.10 user says this still happens for them, yet it's marked fix released in karmic and discussion continues... any idea what the next step is?
[19:40] <SpamapS> maco: IIRC it was converted to an upstart job in 10.10 .. maybe the start on needs work?
[19:49] <maco> SpamapS: yes it was converted, and there's also a comment in there with pitti sru'ing something...and i dont know what the patch was that he sru'd
[19:59] <SpamapS> maco: I believe the fix was to send smbd a HUP whenever cups starts
[20:00] <stgraber> ScottK: ok, now for the SRU. I see that there's already a kdebase-workspace in proposed. Should I upload the upstart job SRU now or do you prefer to wait for the current one to hit -updates and then upload the upstart job fix in -proposed ?
[20:01] <SpamapS> maco: actually no, what happens is smbd starts cups in its pre-start
[20:02] <SpamapS> Oh wait, no.. ugh.. ok.. so confused .. thats not done either.
[20:04] <ScottK> stgraber: I'd prefer to let the current one get to -updates first.
[20:04] <ScottK> Entangled SRUs get complex.
[20:05] <bbigras> I made a branch and a debdiff to fix a little bug I got with pnopaste on Lucid (bug 771421). What should I do next?
[20:05] <SpamapS> ScottK: +1 .. one at a time please. :)
[20:06] <stgraber> ScottK: ok. I'll have the gdm uploaded in a few minutes, so we can probably do the testing with this one and if it works fine, the kdebase-workspace one should be easy (as the diff is identical)
[20:43] <spartan-11510> Hi!
[20:43] <spartan-11510> I've a little proplem
[20:43] <spartan-11510> I can't upload my pgp key on launchpad
[20:44] <micahg> spartan-11510: try #launchpad for support with that
[20:44] <spartan-11510> Ok thx
[21:04] <cjwatson> dupondje: I just finished fixing MoM this morning, so it was probably running when you asked about it.  the first successful run for ages completed at 13:58 UTC
[21:05] <geser> \o/
[21:06] <cjwatson> it required backporting patch 2.6 in order to successfully unpack banshee, and then running pack-archive to free up some disk space
[21:07] <geser> is there enough free space or do we get "disk full" during oneiric?
[21:07]  * micahg hugs cjwatson for fixing MoM
[21:07] <cjwatson> geser: I think it should be OK; the problems typically arise if it breaks for a while and nobody notices
[21:07] <cjwatson> because it uses temporary space proportional to the size of the packages it needs to operate on in a given run
[21:07] <cjwatson> (AIUI)
[21:08] <cjwatson> /dev/cciss/c0d0p1    557446636 472874300  78953604  86% /
[21:08] <cjwatson> also the more merges get done the fewer base revisions it has to keep
[21:11] <jcastro> ScottK: try to edit the schedule now
[21:11] <ScottK> Trying ...
[21:12] <ScottK> I have the edit button now.
[21:12] <ScottK> jcastro: Thanks.
[21:33] <dupondje> cjwatson: :) nice
[22:58] <soren> Yay. First server upgraded to oneiric.
[22:59] <ajmitch> as long as it's not a critical production server
[22:59]  * highvoltage will try for oneiric+1 then :(
[23:08] <Keybuk> I wish the Ubuntu dch would recognise "unstable" ...
[23:22] <soren> ajmitch: Hardly :)


[00:01] <ibmr50e> yo guys
[00:01] <ibmr50e> steam won't start
[00:57] <Kamilion> Well, that's a helpful bug report.
[00:57] <Kamilion> Did you try to run it in a terminal?
[01:11] <ibmr50e> terminal is fine, login screen looks very weird https://imgur.com/a/yrfdm
[01:43] <mr17> hello again .. are you on wxl  ?
[01:44] <mr17> just wanted to tell you the problem is back :/ --- but in desperation i tried Mint 18.2 XFCE. Booted live, and my 3g usb modem went online instantly.
[01:45] <mr17> i wonder what is missing in the lubuntu distro
[01:46] <mr17> gn8 :)
[01:46] <tsimonq2> wxl: This is the same issue. http://bazaar.launchpad.net/~lubuntu-dev/ubuntu-seeds/lubuntu.bionic/view/head:/ship-live-share#L9
[01:46] <tsimonq2> wxl: Yet Another Person has an issue because of it.
[04:17] <wxl> @tsimonq2: this is a support channel XD
[04:18] <tsimonq2> wxl: I...know?
[04:18] <tsimonq2> wxl: If you look *directly* above my message, a user was reporting a problem (then took off) that I really believe is caused by the seed issue
[04:19] <wxl> the steam one? or the 3g usb modem?
[04:19] <tsimonq2> 3g
[04:19] <wxl> i don't think so
[13:39] <guacamole> hi i need help
[13:39] <hateball> !ask
[13:40] <guacamole> sorry bad english, when i play video, audio and motion is out of sync, try many things but no conclusion, any ideas
[13:41] <guacamole> oh and also sometimes my chromium browser just freezes, im trying to fix this in past months but no conclusion my friends :(
[13:45] <guacamole> i need watch video and cant do it man, i need to study magnetism but no good now because audio dont follow video or video dont follow audio
[13:45] <hateball> guacamole: Is this on youtube or where?
[13:45] <guacamole> !ask
[13:45] <guacamole> anywhere @hateball
[13:46] <guacamole> instagram youtube,any website, and even when i download video
[13:46] <hateball> guacamole: What system specs do you have? If this is an older lower power machine, high definition will be a heavy task to decode
[13:46] <guacamole> whats specs means ? i have a dell inspiron mini, if that ok
[13:47] <hateball> guacamole: Do you have an exact model?
[13:47] <hateball> guacamole: What type of CPU? You can check with "lscpu"
[13:47] <hateball> Also how much RAM, you can check with "free -m"
[13:47] <guacamole> i dont understand ok i copy and paste ok
[13:48] <guacamole> https://thepasteb.in/p/X6hBKpP4JKPi3
[13:48] <guacamole> https://thepasteb.in/p/JZhpw0WBGlRSg
[13:48] <guacamole> there my friend
[13:50] <guacamole> any idea?
[13:52] <hateball> Well, that thing seems to not want to load
[13:52] <hateball> or at least incredibly slow
[13:53] <guacamole> yeah man no good. and i try installing adobe flash and disable accelerator
[13:53] <hateball> yeah, pretty low specs on your machine guacamole. for youtube, does it work if you pick a lower quality?
[13:53] <hateball> even 720p is probably too heavy
[13:53] <guacamole> not even 144p very bad
[13:53] <guacamole> it just sounds like a robot voice freezing
[13:53] <guacamole> and video slow
[13:54] <guacamole> funny in the beggining when i just installed lubuntu it used to work, idk why now doesnt work
[13:54] <guacamole> but it used to freeze chromium as usual
[13:55] <guacamole> and mouse too freezing
[13:55] <hateball> hmmm, mouse just freezing when you're doing nothing special? maybe your hard drive is not feeling so well
[13:55] <guacamole> yeah nothing special man, just freezes after reboot
[13:56] <hateball> guacamole: it could also be a problem with the GPU driver I guess
[13:56] <guacamole> i like to install tools u see...i like to install stuff so i can learn, ruby for example, i installed so i could learn, u think that can be a issue?
[13:56] <guacamole> whats gpu drive
[13:57] <hateball> guacamole: no having things installed should not be a problem as long as they are not running and using up system resources
[13:57] <hateball> guacamole: you can run "lspci -k|grep -A 3 VGA"
[13:57] <hateball> Sometimes there are bugs in the video drivers
[13:58] <guacamole> hm..i see..
[13:58] <guacamole> https://thepasteb.in/p/2RhK3n20zr2h4
[13:58] <guacamole> i copy there
[13:58] <guacamole> i dont understand a lot man, i need more study
[13:58] <hateball> guacamole: And it could be that it worked well on install, then you get a kernel update which has a regression
[13:58] <hateball> It is not uncommon
[13:59] <guacamole> i understand...
[13:59] <guacamole> maybe that what happened, u think i should press upgrade dist?
[14:00] <hateball> guacamole: what version are you running now?
[14:01] <guacamole> idk man
[14:01] <hateball> guacamole: cat /etc/issue
[14:01] <guacamole> Ubuntu 16.04.3 LTS \n \l
[14:01] <guacamole> i run this
[14:02] <hateball> yeah that should be fine
[14:02] <hateball> googling shows this thread https://ubuntuforums.org/showthread.php?t=2230238
[14:02] <guacamole> ok i take a read
[14:03] <hateball> suggests that you can change some X options for the driver
[14:03] <guacamole> i try running nvidia gpu drive automatic detection but could not find for my system, i hope the forum thread show another vision
[14:04] <guacamole> thanks ill be back soon
[14:04] <guacamole> i go read now
[14:04] <hateball> guacamole: nvidia? it shows you have intel gpu
[14:05] <guacamole> oh sh :/
[14:11] <guacamole> oh man i tried creating file and still no good hateball
[14:15] <guacamole> this guy said to me install mesa util
[14:15] <guacamole> u try before?
[14:27] <guacamole> same ol
[14:28] <guacamole> still trying to fix
[14:28] <guacamole> follow this now https://askubuntu.com/questions/166224/how-do-i-install-the-intel-graphics-driver-in-my-system
[14:29] <hateball> guacamole: the proper drivers should already be installed
[14:30] <hateball> guacamole: for 16.04 if you want later mesa, you can use oibaf ppa
[14:30] <guacamole> yes but when i did the file no config was there, it was just blank
[14:31] <hateball> guacamole: how exactly did you try to make your xorg.conf ?
[14:31] <guacamole> like the way u send me on askubuntu
[14:31] <guacamole> with gedit
[14:32] <guacamole> and gksudo before the /etc
[14:32] <hateball> guacamole: Well you need root permissions to write into... ok then
[14:32] <hateball> "gksudo gedit /etc/X11/xorg.conf" should work
[14:32] <guacamole> yes that was the way but nothing happend
[14:32] <guacamole> i reboot system twice
[14:33] <guacamole> and still video freezin without sync of audio
[14:33] <hateball> well you can try using nano in a terminal also, just "sudo nano /etc/X11/xorg.conf"
[14:33] <hateball> and then paste in that section (ctrl+shift+v to paste in terminal"
[14:33] <hateball> ctrl+x to save and exit
[14:34] <guacamole> Device"
[14:34] <guacamole>             Identifier "Intel Graphics"
[14:34] <guacamole>             Driver "intel"
[14:34] <guacamole>             Option "AccelMethod" "uxa"
[14:34] <guacamole> EndSection
[14:34] <guacamole> i did it
[14:35] <hateball> Just remember that if your system fails to start X after you will need to switch into a tty (ctrl+alt+f1) and sudo rm /etc/X11/xorg.conf
[14:36] <guacamole> my thanks my friend
[14:37] <guacamole> one other dude told me to report to send bug
[14:37] <guacamole> but i dont think will solve
[14:37] <guacamole> i think is my bad learning the issue not the bug
[14:38] <guacamole> if i could just understand more about these drivers, and why is not work
[14:38] <hateball> I am afraid I can't help much more, I don't have a device like that myself
[14:38] <guest___> When i install VLC mediaplayer i got 5-6 icons.
[14:39] <guacamole> i understand hateball i go try to fix here, thank u for the time
[14:41] <guacamole> look hateball
[14:41] <guacamole> https://thepasteb.in/p/qjhLNmyq6yXiB
[14:42] <guacamole> i now understand how do i config to my intel be there
[14:57] <guacamole> not good man, no progress
[14:59] <guacamole> hey hateball i think i solved
[15:00] <guacamole> i went simply to software and update
[15:00] <guacamole> drivers additionals
[15:01] <guacamole> using processor microcode firmware for intel cpus wasnt marked so i mark now
[15:03] <guacamole> ok it got better but no solved
[15:03] <guacamole> :(
[15:07] <hateball> guacamole: :/
[15:07] <hateball> guacamole: you might want to ask on askubuntu.com I guess
[15:07] <guacamole> ok
[15:07] <hateball> guacamole: since this channel is usually quite idle, not many people looking
[15:09] <guacamole> yeah man :(
[15:09] <guacamole> robots everywhere ha!
[15:09] <wxl> what's the issue again?
[15:09] <guacamole> my video and audio not sync good
[15:10] <guacamole> i use lubuntu in dell
[15:10] <wxl> with what?
[15:10] <wxl> what videos in what app?
[15:10] <guacamole> everywhere man, youtube gnome player, instagram
[15:10] <guacamole> they all sound like robot and with delay
[15:10] <guacamole> even in 144p
[15:10] <wxl> so in a browser
[15:11] <guacamole> yeah in a browser or when i download
[15:11] <wxl> have you tried downloading the youtube videos and playing them in e.g. vlc?
[15:11] <guacamole> yeah man same problem
[15:11] <hateball> It is a single cpu 1.3ghz atom with 1GB ram, should be noted
[15:11] <wxl> what video card and what driver are you using?
[15:11] <hateball> with intel gma500
[15:12] <guacamole> i guess hateball answered my friend
[15:12] <wxl> nope
[15:12] <guacamole> how do i see videocard
[15:12] <hateball> guacamole: what you pastebinned earlier
[15:12] <guacamole> oh ok
[15:12] <wxl> lspci -nnk will give you all sorts of information, including about the driver
[15:12] <guacamole> i copy and paste here wait my friend
[15:13] <hateball> guacamole: this is it https://thepasteb.in/p/2RhK3n20zr2h4
[15:13] <wxl> don't paste here
[15:13] <wxl> that pastebin works
[15:13] <guacamole> oh ok
[15:13] <wxl> gma500 wth is that XD
[15:13] <guacamole> old school
[15:13] <guacamole> ha!
[15:14] <wxl> this is old but says driver support is poor https://community.linuxmint.com/tutorial/view/70
[15:14] <guacamole> but as i talked to hateball, when i installed lubuntu everything worked fine, some issues remained like system freeze or mouse freeze
[15:14] <wxl> of course that's super old but XD
[15:15] <guacamole> i see so i should not upgrade
[15:15] <wxl> https://wiki.ubuntu.com/HardwareSupportComponentsVideoCardsPoulsbo
[15:15] <wxl> that suggests the lack of hardware accelerated video playback makes it act poorly with video
[15:16] <wxl> you could  use mplayer to solve the issue, but you'd have to download stuff
[15:16] <guacamole> ok sound good to me man
[15:16] <guacamole> anything to solve stuff
[15:17] <guacamole> im in the past 3 months trying to learn ruby with youtube but no good
[15:17] <hateball> Personally I would try and save up some money and get a newer hardware
[15:17] <guacamole> because of this delay
[15:17] <hateball> That thing has seen its prime
[15:17] <guacamole> oh that sounds even better hateball, which one u suggest
[15:18] <guacamole> thanks wxl
[15:18] <guacamole> i try to fix stuff too
[15:18] <guacamole> thanks for the time my friends
[15:19] <wxl> this person's looking for help too https://askubuntu.com/questions/469427/choppy-video-playback-with-intel-gma-500-chipset
[15:19] <wxl> tl;dr this is kind of How It Is™ fot that chip
[15:19] <hateball> guacamole: Anything you can afford really, that is celeron or up
[15:19] <guacamole> the first link u send wxl no packages can be found for download
[15:19] <guacamole> thx
[15:20] <hateball> Keeping old hardware alive is good and all but sometimes we have to accept defeat :)
[15:20] <wxl> if you read what i sent you will see that i mentioned something on the page, not as an instruction of what to do
[15:20] <wxl> although the fact that there have been ppas out there may mean searching for a ppa might find you alternatives
[15:20] <guacamole> yes im reading hardware support wxl. and yes hateball this old dell is from 2007
[15:20] <guacamole> its a grandma
[15:21] <guacamole> in 10 years a lot have changed
[15:21] <guacamole> thats cool to see
[15:21] <guacamole> but as u say, defeated
[15:21] <guacamole> ha!
[15:22] <guacamole> wxl the ppas are unchecked here, they gave me a big head pain in the past because of error messages
[15:22] <wxl> ppas are not supported by anyone except their owners
[15:23] <wxl> so you need to decide on whether or not you will add a ppa based on research that will help you decide whether or not to trust them
[15:23] <guacamole> oh...i see...
[15:30] <guacamole> choppy thats a good word for what happening
[15:35] <guacamole> oh nice gotta try this ill be back guys thx
[15:36] <wxl> s/guys/folks/
[15:50] <guacamole> wxl and hateball its fixed!!!!
[15:50] <guacamole> thanks so much!!!
[15:51] <guacamole> omg i cant believe this man
[15:51] <guacamole> =D =D =D
[15:51] <wxl> happy to help use a search engine for you guacamole XD
[15:51] <guacamole> :D :D :D
[15:51] <guacamole> i try so many things that i lost count
[15:51] <guacamole> that last module stuff helped me
[15:51] <guacamole> the last link
[15:52] <guacamole> im listening to electromagnetism class in this moment! :D :D :D
[15:52] <guacamole> \o/ so happy
[15:52] <wxl> cool
[15:53] <guacamole> no choppy video or audio anymore \o/
[15:53] <wxl> if you find any new information or feel like something could be updated (e.g. "worked on this version") on the wiki, feel free to send your notes to<EMAIL_ADDRESS>or just edit t yourself :)
[15:53] <guacamole> all right!
[15:56] <guacamole> now there is another issue going on
[15:56] <guacamole> the mouse freezes when i start
[15:56] <guacamole> and i didnt find no where in askubuntu no solution good
[15:56] <wxl> what kind of mouse?
[15:56] <guacamole> my notepad
[15:57] <wxl> are you using synaptics on it?
[15:57] <guacamole> whats synaptics
[15:57] <guacamole> wait i google
[15:57] <guacamole> ha!
[15:58] <wxl> i would imagine if you're NOT using it `synclient` would return nothing
[16:00] <guacamole> yes i guess no synaptics
[16:00] <wxl> weird
[16:00] <wxl> i would probably use synaptics personally.
[16:01] <guacamole> no synaptics menu im following a solved stuff here
[16:01] <guacamole> https://help.ubuntu.com/community/SynapticsTouchpad
[16:01] <guacamole> :D
[16:01] <guacamole> thx again man
[16:36] <guacamole> wxl u still here?
[18:48] <venik> how do I use an HDMI projector with Lubuntu 17.10?
[18:48] <venik> or ANY projector/
[18:53] <venik> thanks-- I think I figured it out
[19:19] <ibmr50e> Guys! I tried to make my grub2 BEAUTIFUL by editing it with grub-customizer. I wanted to add Kanye West background image. It didn't work, now my grub2 is UGLY and has basic colors and fonts and I can't reverse it.. How to make it BEAUTIFUL or at least NORMAL again? Thank you!
[22:07] <Guest__> How can i use Huawai mobile modem on Lubuntu ? Will it work without install anything ?
[22:19] <ibmr50e> what was the apt-get command to install ubuntu software manager?
[22:36] <ibmr50e> how to launch some directory from terminal using this pcman?
[22:37] <krytarik> "pcmanfm <directory> &"
[22:39] <ibmr50e> what does & do?
[22:40] <ibmr50e> wow i did sudo pcmanfm and finally can delete things
[22:40] <ibmr50e> i had useless things in /boot/grub thank you
[22:41] <krytarik> !sudo
[22:42] <ibmr50e> ye i know
[22:42] <krytarik> Also, '&' sends the process to the background.
[22:43] <ibmr50e> so terminal won't stay open stupidly?
[22:44] <ibmr50e> cool cool


[00:47] <MOSHU> Hi! I have some problems after upgrading Ubuntu from 10.04 to 12.04..... One is upgraded MySQL 5.5 (from 5.1) didn't start.... Can anyone help me, please?
[00:52] <dlentz> MOSHU, please use #ubuntu for support
[00:53] <MOSHU> Why? It's an apparmor upgrade bug
[00:54] <MOSHU> Anyway... The bug is reported since april, so.... sleep well, guys.
[05:57] <lotuspsychje> i have this bug thats been unsolved for years now, and affects many users in different forms..can i paste this here?
[05:59] <lotuspsychje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/556782
[05:59] <ubot2`> Ubuntu bug 556782 in linux "[rs690m] Graphics corruption with ati x1200" [Critical,Confirmed]
[13:10] <paul_> Having bug issue with Display on a new Samsung laptop. It revolves around the brightness changing on the Display.
[15:40] <TheLordOfTime> if a bug being filed is a regression between oneiric and precise, should it be tagged `regression`?
[15:41] <TheLordOfTime> (or precise and quantal, or other such regressions that only show up between releases)
[15:50] <brendand> regression-release (i believe)
[16:19] <micahg> TheLordOfTime: regression-release with a task added
[16:19] <micahg> and the release the regression is in as a tag as well
[16:20] <TheLordOfTime> micahg:  ah, i see.
[16:20] <TheLordOfTime> well, considering the bug that *is* a regression between oneiric and precise is already awaiting SRU team approval, i don't think that'd be necessary, but now i know what to do :P
[17:12] <cousteau> bug #919899 is marked as a duplicate of bug #961741 but I think it shouldn't; could someone confirm this?
[17:12] <ubot2`> Launchpad bug 919899 in console-setup "Compose sequence apostrophe+c produces a cedilla instead of acute (dup-of: 961741)" [Undecided,Confirmed] https://launchpad.net/bugs/919899
[17:12] <ubot2`> Launchpad bug 961741 in unity "REGRESSION: can't type characters with accent (dead keys)" [Medium,Fix released] https://launchpad.net/bugs/961741
[17:13] <cousteau> first one is about a compose sequence printing a different character than it used to;  2nd one is about dead keys not working on Dash
[17:16] <cousteau> hmm...  I just clicked "Remove duplicate link" and the duplicate notice just disappeared.  Is it that easy to remove duplicate notices?
[17:23] <mapreri> cousteau: yep, it is so easy :) LP is for lazy people :)
[17:24] <cousteau> wouldn't that lead to dupe/undupe wars?
[17:25] <cousteau> user A thinks bug is a duplicate and marks it, user B thinks it isn't and unmarks it, user A considers B didn't understand the problem and marks it, user B is "what's A doing??" and unmarks it, etc
[17:29] <mapreri> cousteau: we hope users wil follow the CoC also if they don't sign it
[17:30] <cousteau> (which reminds me, maybe I should sign it...)
[17:35] <cousteau> ok, thanks for the help  :)
[20:06] <Logan_> Can somebody please make Bug 1044429 public, assuming that it doesn't contain any private information?
[20:24] <jibel> Logan_, done
[20:24] <Logan_> jibel: Thanks. :)
[23:15] <phillw> hi, any staffers in from ubuntu bugs?
[23:15] <phillw> I have a complaint from QA that I'd like resolvng,
[23:16] <hggdh_> phillw: try it -- perhaps we can help
[23:19] <phillw> hggdh_: one of the testers has complained that his bug report has been marked as a dupe to a private bug report. This means he can not access it to update it. This is not a wise step to do for a ubuntu tester. It does cause them to raise a complaint with me & my having to come here.,
[23:20] <jtaylor> which bug?
[23:20] <hggdh_> well, this can indeed happen. But instead of a complaint, they could have pointed it out. When this happens, we look at the bug, and decide if there is private data justifying keeping the bug private
[23:20] <phillw> jtaylor: hggdh_https://bugs.launchpad.net/bugs/1024202
[23:20] <ubot2`> phillw: Error: <Bugtracker.plugin.Launchpad instance at 0xa2d980c> bug 1024202 not found
[23:20] <hggdh_> but, as jtaylor pointed out, we need the bug number
[23:21] <phillw> https://bugs.launchpad.net/bugs/1041007
[23:21] <ubot2`> phillw: Error: <Bugtracker.plugin.Launchpad instance at 0xa2d980c> bug 1041007 not found
[23:21] <phillw> they have been marked private
[23:22] <hggdh_> stacktrace bugs are born private
[23:23] <hggdh> but, for apport, I doubt there will be private data. The stacktrace does not have it
[23:23] <phillw> I've asked the tester to attend
[23:23] <hggdh> I marked it public
[23:24] <hggdh> but, ideally, they should point out the bug is private here. It will happen, and it will still happen, at least for a while
[23:24] <phillw> hi guys, can you please explain in simple language to nm_geo and myself why he cannot access his own bug report?
[23:24] <hggdh> oops
[23:24] <nm_geo> yes please
[23:25] <hggdh> his *own* bug report he certainly can
[23:25] <nm_geo> no the private that mine was dupped too
[23:25] <hggdh> somebody else's bug report -- like a bug _yours_ was dupped against -- is a completely different thing
[23:26] <hggdh> nm_geo: OK. Here's what happens:
[23:26] <nm_geo> I do understand that
[23:26] <jtaylor> it was automatically dupped
[23:26] <nm_geo> That is what I thought
[23:27] <hggdh> when a stacktrace bug is opened (an apport bug, specifically), this bug is opened private. Apport then goes, and GDBs it, and prints out a nice formatted stacktrace
[23:27] <phillw> and how do you dupe a public bug into private so he can no longer access it? I guess we have to come here and ask you guys?
[23:27] <hggdh> the problem is there *may* be private data being shown on the output of 'thread apply all bt full'
[23:28] <nm_geo> That is why I test using test as a password
[23:28] <hggdh> so apport leaves the bug private, pending someone with crash access to look and release
[23:28] <hggdh> nm_geo: it is good you test with throw-away private data. But not all bugs are from tests, some are from real usage :-)
[23:29] <nm_geo> Well I decide to Public mine hoping it would help but then it got dupped
[23:29] <jtaylor> you can remove the duplicate status
[23:29] <hggdh> whenever that happens (a private bug, with dups against it), then the best option is to come in this channel, and ask for someone to look at it
[23:29] <nm_geo> jtaylor: ok
[23:29] <jtaylor> but its better to ping someone here to make the master bug public
[23:30] <nm_geo> I will do that in the future if it appears to be needed bug Thank you guys
[23:30] <hggdh> nm_geo: and this is what I did -- I went into the bug, and looked at the potentially-private areas, saw nothing critical, made it public
[23:31] <hggdh> nm_geo: BTW, thank you for helping :-)
[23:31] <nm_geo> Hey you guys are the ones that have the tough job I just try to find them
[23:31] <TJ-> Whilst we're on the subject of bug reports going private I had a similar issue recently. I was actively working on a bug that I'd assigned to myself, I'd attached a debdiff patch and subscribed sponsors, and then next time I tried to get into the report to add my linked lp bazaar branch, the bug was no longer accessible. I'm a member of bug-control. It is/was bug #1008289
[23:32] <hggdh> TJ-: I also get a message stating there is no such bug. Was it a security issue?
[23:33] <TJ-> hggdh: It was apt sending a truncated token for auth to the private PPAs for purchased apps, so it could have become that I guess. I got no notification as a bug subscriber though
[23:33] <hggdh> nm_geo: you would be amazed, then, to find out that *we* really appreciate your help. Really.
[23:33] <nm_geo> Some day when phillw and Lubuntu get tired of me I might try on the bug-squad
[23:33] <TJ-> hggdh: And as I was assigned to it last time I looked I was very confused for a while!
[23:34] <hggdh> TJ-: this is indeed weird. Perhaps you should ping the folks at #ubuntu-hardened
[23:34] <jtaylor> you could ask in -hardened
[23:34] <hggdh> (cuz I also have no access to security bugs)
[23:34] <TJ-> hggdh: Oh that's encouraging! If you think it's weird too :D
[23:34] <hggdh> :-)
[23:34] <jtaylor> if its no security issue then its probably a bug for #launchpad
[23:34] <TJ-> hggdh: It would be nice if, at least, the bug owner and anyone assigned got a courtesy email telling them the big was being made secure and who to contact about it
[23:34] <hggdh> yeah
[23:35] <hggdh> TJ-: usually it is very difficult to re-bag the cat once it is out of the first bag
[23:35] <TJ-> Oh I dunno... I'm a farmboy... never had any problems with that here :D
[23:35] <hggdh> one can always try a larger bag, but still..
[23:36] <phillw> hggdh: would you prefer me to update the QA area for this answer, or can you guys put it up on bug wiki?
[23:36]  * hggdh now goes to bed, 44 hours up & running are starting to tell me I am not young anymore
[23:37] <hggdh> phillw: if you could, yes, I would really appreciate
[23:37] <hggdh> I am tired as hell
[23:37] <jtaylor> I got to get to bed too, n8
[23:37] <hggdh> heh
[23:37] <phillw> hggdh: I'll catch you after we have sleep :)
[23:38] <hggdh> phillw: tomorrow morning, US CDT time :-)
[23:38] <phillw> I'm on 24:38 GMT / UTC
[23:40] <TJ-> 44 hours is a slow train wreck! Get some sleep!!
[23:40] <phillw> hggdh: remind me at<EMAIL_ADDRESS>[23:51] <BHO1> I just installed Xbuntu yesterday.  Today I forgot to plug in my laptop and it died.  Ever since it died, my screen has been dim and i can not figure out how to brighten it.
[23:57] <phillw> BHO1: join #xubuntu that is where the support team is


[03:36] <RPG-Master> Even though I'm using 10.10, is their any PPA I could use to play with the new, compiz using, desktop oriented Unity?
[11:41] <wrst> RPG-Master: i'm using natty and i haven't noticed that change yet, but i could be mistaken
[14:42] <Goog_Josh> where can i read about hack iis server?
[16:06] <wrst> RPG-Master: you can find a little info on what you are wanting here: http://askubuntu.com/questions/9941/when-will-compiz-based-version-unity-be-available-for-testing
[16:34] <Wubbbi> Hi guys ;D
[16:36] <coz_> so guys.. I am wondering.. the desktop wallpaper options... will they be fixed in natty?
[16:36] <coz_> I realize this is minor but the bug reports from lucid/maverick  are long concerning this issue
[16:38] <coz_> rather for dual monitors
[16:40] <IdleOne> Can someone run: xdg-open http://www.google.com/ and tell me if the default browser is used to open the link. In my case it is gedit that opens.
[16:42] <Ian_Corne> IdleOne: gnome-open has the same issue
[16:42] <IdleOne> Ian_Corne: any fix?
[16:42] <Ian_Corne> Not that I know of
[16:42] <jpds> IdleOne: System → Preferences → Preferred Apps?
[16:42] <IdleOne> you know of a bug report?
[16:42] <IdleOne> jpds: set to chromium-browser
[16:43] <Ian_Corne> jpds: that's already set to a browser
[16:43] <Ian_Corne> same here
[16:43] <IdleOne> jpds: same problem if i set it to firefox
[16:43] <Ian_Corne> https://bugs.launchpad.net/bugs/670128
[16:43] <IdleOne> not exactly the same bug for me
[16:43] <Ian_Corne> well
[16:43] <IdleOne> but seems related
[16:43] <Ian_Corne> the discription is to limited
[16:43] <Ian_Corne> It's what I've experienced
[16:54] <IdleOne> jpds: do you know what package I should file a bug against for this issue?
[16:55] <IdleOne> or is libgnome the correct package?
[17:24] <jo-erlend> is there any plans to add support for SPICE in Natty?
[18:11] <RPG-Master> wrst: Thanks for the link :)
[18:16] <wrst> you are welcome RPG-Master, i'm looking forward to that as well
[22:28] <BUGabundo> evening
[22:28] <charlie-tca> hello, BUGabundo
[22:36] <khussein> Hi guys. Can someone please tell me where can I see the list of blueprints or features that are planned/approved for the next release?
[22:37] <BUGabundo> Current status: 98 updates [+98], 41725 new [+25].
[22:37] <BUGabundo> Need to get 220 MB of archives. After unpacking 18.5 MB will be used.
[22:37] <BUGabundo> we are pushing the bar :S
[22:37] <BUGabundo> khussein: launchpad?
[22:37] <BUGabundo> hunder natty blueprints
[22:40] <charlie-tca> khussein: https://blueprints.launchpad.net/ubuntu?searchtext=n-
[22:41] <khussein> BUGabundo and charlie-tca thanks :).
[22:46] <Ian_Corne> 41k New BUGabundo ?!
[22:46] <Ian_Corne> Current status: 29 updates [+18], 25 new [+22].
[22:48] <yofel> I had: Current status: 367 updates [+366], 150 new [+10].
[22:49] <Ian_Corne> hmm
[22:51] <yofel> I think most were kde 4.5.3 updates
[22:53] <Ian_Corne> Aha
[22:53] <Ian_Corne> I steer clear of kde :)
[23:40] <histo> khussein: www.ubuntu.com/testing  I believe will have a link to blueprints
[23:41] <khussein> Thanks. I found them on launchpad under natty
[23:42] <khussein> I wanted to look at the approved ones and see if I can start helping with any of them. I am new to Ubuntu Server and would like to contribute if I can.
[23:58] <BUGabundo> someone put me on pair with Wayland