[00:23] <bdmurray> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== freeflying_away is now known as freeflying
=== _salem is now known as salem_
[02:14] <phillw>  If there is someone available, could you tell me the difference between sudo do-release-upgrade and the apt-get update & dist-upgrade route?
[02:14] <phillw> brian intimated that they are not the same.
[02:15] <phillw> bdmurray: ^^
=== freeflying is now known as freeflying_away
[02:53] <phillw> ScottK: I assume they are away for the w/end - I'll ask again in 'normal office hours' :)
[03:06] <ScottK> I don't know what you expect them to tell you I didn't already.  The pointer here was not meant to cause you to re-ask the question I already answered in -release.
[03:12] <bdmurray> phillw: ScottK answered the question pretty well.
[03:14] <phillw> bdmurray: I must have missed the answer.
[03:15] <bdmurray> phillw: "the simple version is it does lots of special-casing to make release upgrades smoother"
[03:19] <phillw> bdmurray: I do not suppose there is a cat on hells chance of that being explained on a sub page of https://wiki.ubuntu.com/Testing/Testing_The_Devlopment_Release ?
[03:22] <phillw> I've yet to write up the dist-upgrade page page, so knowing the difference between that and do-release-upgrade would be of real help (not only to me, as I do not know the difference)
[03:23] <phillw> -page
[03:24] <ScottK> From a test perspective, all you need to write is that the supported upgrade method is using the release upgrader and describe how to do it.
[03:24] <bdmurray> The recommended way to upgrade between releases of Ubuntu is using the release upgrader.
[03:25] <bdmurray> I don't think other not recommended ways should be documented.
[03:25] <phillw> ScottK: bdmurray so for people using ubuntu+1 they should use do-release-upgrade and not update / dist-upgrade?
[03:25] <ScottK> yes
[03:26] <ScottK> no
[03:26] <bdmurray> Additionally, during the testing of the development release you wouldn't use do-release-upgrade.
[03:26] <ScottK> When you upgrade from one release to another, use do-release-upgrade.
[03:26] <bdmurray> That's used to move from release to release.
[03:26] <ScottK> Not when updating packages
[03:28] <phillw> so, I should advise  update / dist-upgrade
[03:29] <bdmurray> No, because that is for upgrading between releases.
[03:29] <bdmurray> Using update-manager is the recommended way to install updates.
[03:30] <phillw> bdmurray: I'm running 13.10, what is the best method to update it on a real (or virtual) machine?
[03:31] <bdmurray> use update-manager
[03:31] <phillw> I did not get linux kernel update because I needed to use dist-upgrade
[03:32]  * phillw confused, as usual :)
[03:33] <phillw> so, can I ask in terms of simple? I'm running 13.10 - what is the method to ensure it gets all the updates?
[03:34] <bdmurray> Again using update-manager is the way to get all updates.
[03:40] <phillw> running update-manager from terminal now :)
[03:41] <phillw> bdmurray:  I'm sorry for n00b questions, but it is an area of the testing wiki area I want to be fully correct.
[03:45] <phillw> bdmurray: is there a method of issuing that command and see progress?
=== salem_ is now known as _salem
[03:46] <bdmurray> update-manager is a gui application so I'm not sure what you mean
[03:47] <phillw> when using update manager from menu, we do have an option to see the progress :)
=== freeflying_away is now known as freeflying
[03:48] <phillw> "Failed to download repository information" check your internet connection
[03:49] <phillw> Not too helpful :P
[04:07] <phillw> bdmurray: update-manager is not fit for testing purposes, it has no way of giving any error reports. Is there any other way to do the task via terminal?
[04:09] <phillw> bdmurray: also Gtk-WARNING **: Unable to locate theme engine in module_path: "murrine", at /usr/share/perl5/Debconf/FrontEnd/Gnome.pm line 96.
[04:09] <phillw>  is repeated many times.
[04:14] <bdmurray> phillw: this is what update-manager looks like - http://people.canonical.com/~brian/tmp/Screenshot%20from%202013-08-23%2021:13:01.png  is that what you are using?
[04:15] <phillw> bdmurray: I'm just filing a bug, it will be there in a couple of minutes.
[04:15] <bdmurray> phillw: could you answer my question?
[04:17] <phillw> bdmurray: nope. I do not see that.. just a small GUI window of the status. I will grab a screen shot to add to the bug.
[04:22] <phillw> bdmurray: anything else you need for bug 1216199 ?
[04:22] <ubottu> bug 1216199 in update-manager (Ubuntu) "update-manager shows no reason for a failure" [Undecided,New] https://launchpad.net/bugs/1216199
[04:23] <bdmurray> well the screen shot
[04:24] <phillw> drat... just kicked in the ubuntu-bug command.... awaiting it to cancel :)
=== Ursinha is now known as Ursinha-afk
[04:29] <phillw> bdmurray: window shot added.
[04:30] <bdmurray> and then after that screen you should see one like I posted
[04:30] <phillw> I can add the entire screen if that would help, but I doubt it would.
[04:30] <phillw> Nope, never saw the next screen. as when it failed I had a choice of cancel or continue regardless.
[04:31] <bdmurray> You mentioned that it failed to download repository information earlier.
[04:31] <bdmurray> I suspect you have some PPAs enabled that don't support saucy.
[04:32] <phillw> yep, I have a dodgy PPA... but that should not cause a total failure
[04:33] <bdmurray> well remove that then
=== Ursinha-afk is now known as Ursinha
[04:33] <phillw> as testers, we are asked to run PPA's. https://wiki.ubuntu.com/QATeam/PPA_Testing
[04:34] <phillw> bdmurray: that then causes other issues, next it will be remove -proposed etc. It HAS to handle testing, or we need a CLI option.
[04:34] <infinity> You're not asked to run PPAs that 404, I imagine.
[04:35] <phillw> that one had failed, but it should not really cause a catastrophic failure?
[04:35] <phillw> I'll remove the PPA
[04:35] <infinity> It didn't.  It gave you the option to continue.
[04:35] <infinity> Your definition of catasrophe is curious.
[04:39] <phillw> It did not progress to your screen shot? I'm trying to get a heads up as to how to write the wiki page. As at present, on the screen shot I have does not state, nor can, state any error it is an 'abort' or 'ignore'. As there is the 'minor' issue of https://wiki.ubuntu.com/U%2B1/partial_upgrade which it does not seem to be able to handle
[04:40] <phillw> nor can it handle or report a 404 error
[04:42] <bdmurray> I don't know what you mean by "on the screen shot I have does not state, nor can, state any error it is an 'abort' or 'ignore'".  Could you explain that a bit more?
[04:46] <phillw> bdmurray: maybe I should try this from a different angle... give me a few minutes to write an idea up and pastebin it for you to read.
[04:47] <bdmurray> phillw: that's not really necessary
[04:47] <bdmurray> the dialog I see that is labelled "Failed to download repository information" has two buttson
[04:47] <bdmurray> Try Again and Ok
[04:47] <bdmurray> clicking ok presents the same screnshot I posted earlier
[04:47] <bdmurray> which then allows you to upgrade
[04:49] <phillw> yup, I did the try again, but as I have a known 404 on a ppa, that would be okay. However but, and it is a big 'BUT', i also see errors on apt-get update that needs me to re-run it again because of time outs.
[04:51] <phillw> bdmurray: please don't think I'm being awkward, I'm just trying to get a wiki page written up that can be referred to as the "Gold Standard" for people to refer to.
[04:52] <bdmurray> phillw: and I believe that the standard is update-manager, even though it may not be working for you personally
[04:54] <phillw> if on ubuntu+1 with other testing going on that we do get involved in, is a GUI the best option? If that is your considered opinion, I will write the page up as that. We'll then have to to think about how best to proceed when it throws an error message up.
[04:57] <phillw> "Failed to download repository information - check your internet connection"... Options are "Settings", "Try Again" and "OK". There is no way of seeing what the issue is.
[04:57] <bdmurray> phillw: I'm really not sure what you are looking for, but if the goal of testing is to test apps that our users use then the testers should be using the recommended software to install updates - which in this case is update-manager.  If you run into bugs with it then those should be reported.
[04:58] <bdmurray> So yes a GUI is the best option, and I'm not sure why you put it that way.
[04:59] <phillw> infinity: https://wiki.ubuntu.com/U%2B1/partial_upgrade I have no way of knowing if I use the GUI
[05:00] <phillw> s/ infinity / bdmurray
[05:00] <bdmurray> phillw: I think what you are complaining about is similar to bug 1153569
[05:00] <ubottu> bug 1153569 in update-manager (Ubuntu) ""Failed to download repository information" alert is unattractive" [Medium,Triaged] https://launchpad.net/bugs/1153569
[05:01] <phillw> possibly, but for a partial upgrade it can well bork your system. Which is why they go on to length about not doing it :D
[05:01] <bdmurray> or at least resolving that bug should give more information when it fails
[05:02] <bdmurray> I'm talking about the 404 issue you were mentioning earlier, I haven't read the partial upgrade page.
[05:03] <phillw> bdmurray: I usually have to run apt-get update twice to have it happy, before I issue the apt-get dis-upgrade.
[05:04] <phillw> I've got a crappy <narrow>band link, which can drop out at times
[05:04] <phillw> *dist-upgrade*
[05:05] <bdmurray> I'm headed off
[05:06] <phillw> is 06:05 here, I've turned off the ppa from chad miller for chromium and the wallch one. I'll have a play after some sleep :)
[05:07] <phillw> thank you for your time.
[07:47] <vipul_> hey!
[07:47] <vipul_> can anybody tell me the difference between kernel programming vs device drivers programming?
[09:55] <zequence> Ubuntu Studio devs would like help uploading one last package before FF. Anyone around who could assist?
[09:55] <zequence> lp:~ubuntustudio-dev/ubuntustudio-default-settings
=== tvoss_ is now known as tvoss|test
=== tvoss|test is now known as tvoss_
=== tvoss_ is now known as tvoss|test
=== freeflying is now known as freeflying_away
[15:03] <xnox> zequence: is that complete branch name?
[15:03] <xnox> =)
[15:04] <OvenWerks> xnox: let me check
[15:04] <xnox> zequence: please set development focus branch, such that lp:ubuntustudio-default-settings works =)
[15:05] <xnox> OvenWerks: i guess it's lp:~ubuntustudio-dev/ubuntustudio-default-settings/UbuntuStudio
[15:05] <OvenWerks> yes
[15:09] <xnox> TheMuso: can you please set maintainer/driver of ubuntustudio-default-settings (and/or other ubuntustudio packages) to ~ubuntustudio-dev?
[15:30] <xnox> zequence: have you considered to apply via Developer Membership Board for upload rights to ubuntustudio packageset? it should be trivial for existing Debian Developer who upload same packages in Debian.
[15:32] <xnox> zequence: OvenWerks: done.
[15:40] <OvenWerks> xnox: Thank you
[16:16] <OvenWerks> xnox: I can see the ubuntustudio-default-settings build, but the branch does not show the commit for the release. That is the changelog in the deb differs from the changelog at the branch
[16:21] <OvenWerks> xnox: I can sync the branch if you would prefer
[16:23] <xnox> OvenWerks: pushed.
[16:24] <OvenWerks> Thank you
[16:53] <evfool> hi, does anyone know what's the target gtk+ version for saucy?
[17:07] <zequence> xnox: None of us have upload rights to anywhere at the moment, but we're working on it :)
[17:13] <xnox> evfool: current gtk+ stable, 3.8?!
=== charles_ is now known as charles
[17:17] <evfool> xnox: just wanted to know as 3.10 stable will be released before the final beta, and it could've been included in saucy, but I guess then saucy will be released with 6months old gnome stack :(
[17:19] <Laney> we'll get that next time
[18:51] <ari-tczew> does have someone armel to test a package against FTBFS?
[18:51] <mlankhorst> ari-tczew: armel is only for precise
[18:51] <infinity> (and quantal)
[18:53] <ari-tczew> ok, does have someone armhf?
[18:53] <infinity> Well, I have both.  But maybe it would help if you pointed someone at the diff/fix?
[18:53] <infinity> Some of us can identify if it'll fix the problem even without compiling.
[18:54] <ari-tczew> infinity: I'd like to test libopenraw from Debian
[18:54] <ari-tczew> if builds fine on armhf, I'd like to sync it
[18:55] <infinity> Erm, why?
[18:55] <infinity> Ours is already fixed.
[18:57] <infinity> ari-tczew: We get exactly nothing out of syncing it, nothing's changed except the symbols files and ours are already correct.
=== Nitrodex is now known as Guest36251
[18:58] <ari-tczew> infinity: if package builds fine (from Debian on saucy) we don't need to take a look again in the next cycle
[18:58] <infinity> ari-tczew: Note that "we" is "me", since it's on my merge list.
[18:59] <infinity> And I do actually look at my merge list.  Even when helpful people decide they know better. :P
[19:00] <ari-tczew> infinity: hmmm I didn't notice that you're the last uploader
[19:01] <ari-tczew> but in DIF asking the last uploader of merge is not necessary
[19:01] <ari-tczew> after DIF *
[19:01] <infinity> Err, wut?
[19:01] <infinity> Who on earth told you that?
[19:01] <ari-tczew> infinity: ScottK
[19:02] <infinity> DIF is a freeze.  Restrictions are tighter, not looser.
[19:02] <infinity> It's Debian Import Freeze, not Debian Import Free-for-all.
[19:03] <ari-tczew> infinity: so you mean every contributor should ask always for every sync/merge last uploader?
[19:03] <ari-tczew> of I can?
[19:03] <ari-tczew> or *
[19:03] <stgraber> TIL always applies
[19:03] <infinity> It's generally not a bad idea to ask the last uploader.
[19:04] <stgraber> there are obvious cases where it doesn't (no change rebuilds, ...) but those are as I said, obvious, so if it's not obvious, ask the last uploader
[19:04] <infinity> In some cases, a sync-over-last-bugfix is "obvious" and if you've tested it thoroughly, not a big deal.  But you'd better be positive that the only delta you're dropping is now upstream.
[19:04] <ari-tczew> infinity: I'm preparing syncs/merges since 1 month and you're the first person which have a problem with that
[19:04] <stgraber> especially when it's someone as active as infinity who will be able to give you a go/no-go within minutes (or even seconds)
[19:04] <infinity> (I've lost far too many of my patches to people who sync because 1/3 of my patches got upstream)
[19:05] <infinity> Honestly, I'm still not sure who decided that "doing other people's merges" was a sane way to contribute. :/
[19:06] <stgraber> and doing merges/syncs after DIF is usually a very bad idea as the potential for regressions/new issues is pretty high with those. So unless you're very familar with a package (in which case you're likely to be the TIL anyway), it's best to wait till the next cycle.
[19:06] <infinity> ari-tczew: Maybe I'm just the first one to be outwardly annoyed by it? :P
[19:08] <ari-tczew> if we cannot sync/merge package when that can only last uploader, always will be slowly updated/upgraded
[19:09] <infinity> ari-tczew: If the TIL person isn't responsive, by all means, hijack away.  We don't have a concept of package *ownership* in Ubuntu, but we still have a sense of politeness and an understanding of domain expertise.
[19:09] <infinity> For instance, the person who offered to merge dpkg for me was given a firm "no". :P
[19:09] <infinity> But at least he asked.
[19:11] <ari-tczew> infinity: so I've got wrong info and I need to clear it with the person who told me that
[19:11] <ari-tczew> anyway, infinity, you're the first with problem about that
[19:11] <stgraber> ari-tczew: not having the latest version of a given package isn't necessarily a bad thing, especially when it's because the domain expert is too busy with other things. If you'd merge the package for him, he'd likely have to deal with the bugs, which he probably wouldn't have time to do and Ubuntu would just end up being more buggy (albeit with a new shiny verison of a broken package)
[19:14] <infinity> (Granted, this sync is a bad example of the above, but it's still nice to ask, or to not bother with a pointless no-op sync that just creates churn)
[19:17] <ari-tczew> stgraber: ok, maybe we should attach a mail to a sync/merge request with confirmation that last uploader gives ACK for this one
[19:18] <infinity> ari-tczew: FWIW, the new openraw builds on armhf, but Debian's symbols file is a complete mess, and it only builds because he's slack on his makeshlibs failure mode.  I'll probably submit a better patch later (but keep it forked for now).
[19:19] <infinity> Anyhow, there's no point in syncing it.  The software itself hasn't changed at all.
[19:19] <ari-tczew> infinity: ok, that's why I asked
[19:19] <stgraber> ari-tczew: let's not add extra paperwork. Either you have the ok and you file the bug, or you don't and you don't. If you do the work without asking first, I'd expect the sponsor to get in touch with the TIL and depending on his mood, just ignore your work entirely.
[19:20] <stgraber> (because it always takes longer to review a merge than do it from scratch, so for my packages, I just ignore people doing the merge for me and I'll do it myself from scratch when I actually have time for that stuff)
[19:22] <ari-tczew> if the people make a]
[19:22] <ari-tczew> make packages better from scratch instead a merge, why we work closes with Debian?
[19:22] <infinity> That's now what he meant.
[19:23] <ari-tczew> now we are going to point that merging  and syncing don't make sense
[19:23] <infinity> He meant it's easier for a reviewer to just do a merge themselves than to review a merge.
[19:24] <infinity> Merges come in two flavours: 1) trivial merges that I can do in about 5 seconds.  Sponsoring someone else's saves me no time there.  2) Very complex merges that can take hours.  The only way to review one of those is to do it myself, and compare the output.  At which point, I've just re-done what you did.
[19:26] <ari-tczew> infinity: and what's your point? you don't like to sponsor someone else?
[19:26] <stgraber> no, his point is that sponsoring merges is a bad idea and that this work is better left to the TIL
[19:26] <stgraber> who will be able to do it in a fraction of the time and have it done correctly the first time around
[19:27] <infinity> I'd much rather sponsor bugfix patches and such.  Things where the contributor had to put in real effort that I wasn't going to or didn't have time to.
[19:27] <stgraber> whereas doing the work for the TIL, only forces him to do it NOW to review your work, so then you've had two people do the merge which means you either wasted your time, or the TIL's time
[19:27] <infinity> If you look at my history of sponsored uploads, you'll be hard pressed to find merges in there.  Just sayin'.
[19:29] <ari-tczew> stgraber, infinity: do you believe that every contributor asks last uploader before prepare/upload a merge?
[19:29]  * infinity grumbles at fixing corosync and sheepdog and still not managing to get libcorosync4 safe on the NBS list, and squints harder to find the cause.
[19:29] <infinity> ari-tczew: I don't believe everyone does, and you're not the only one I've asked to do so.
[19:30] <infinity> ari-tczew: Do you believe everyone asks before stabbing their parents in the face?  What others do should have no bearing.
[19:30] <stgraber> ari-tczew: I know not everyone does it because I fairly often have to remind people about it, it's no excuse not to do so though.
[19:31] <infinity> ari-tczew: There's also something to be said for knowing the people you're messing with.  As much as we'd like to pretend otherwise, not everyone is the same, and relationships matter.
[19:32] <infinity> ari-tczew: For instance, despite being a core-dev, I tend to ask before I do evil things to KDE packages.  But if I wanted to mangle one of stgraber's packages, I'd just do it because we work closely together and he'd hunt me down and smack me in the kneecaps if it annoyed him.
[19:32] <infinity> ari-tczew: Until you're sure you have the latter relationship with the people who might be irked by your actions, it's always safer to assume the arm's-length stranger relationship and be polite.
[19:35] <ari-tczew> if there is a clear sync - small delta forwarded to Debian and applied there, do I have to ask last uploader, as well?
[19:37] <Ampelbein> ari-tczew: I'd consider it polite to ask, yes. Maybe the last uploader holds off on uploading on purpose because he has other changes in the queue. A small "Hey XXX, mind if I sync libfoo from debian?" doesn't cost much time.
[19:37] <stgraber> if you can build on all architectures and confirm the rest is absolutely identical to what's in the archive, syncing is probably fine without asking. However there are cases where we don't want to automatically sync from Debian, and doing a sync would bypass that, so it's always better to ask (and only takes a minute, so why not do it?)
[19:39] <ari-tczew> stgraber: +1 for 1st sentence
[19:40] <ari-tczew> stgraber: 2nd sentence: there is a blacklist for archive, right?
[19:40] <infinity> ari-tczew: We only blacklist things we NEVER want to sync, not temporary "we're holding at this version on purpose" things.
[19:46] <infinity> Oh, thanks launchpad, publishing two versions of libcorosync4 is exactly what I wanted you to do.
[19:46]  * infinity headdesks.
[19:49] <ari-tczew> infinity: so in that case please leave a comment on MoM "don't merge 0.1.2-3"
[19:49] <ari-tczew> or sync, nevermind
[19:50] <Ampelbein> Or just ask the TIL to give the ok.
[19:53] <infinity> Sweetsha1k: Did you really mean to drop python-uno but keep half of libreoffice depending on it?
[20:01] <ari-tczew> Ampelbein: if TIL doesn't response, what's next?
[20:04] <Ampelbein> ari-tczew: If there is no response in a reasonable timeframe (I'd say 1 week for non-critical stuff, less for more severe issues), carefully check a) the bugs in LP, b) the bugs in debian for new issues, c) possibly the vcs the debian developer is using (some ubuntu uploaders work with their debian upstreams).
[20:05] <Ampelbein> ari-tczew: And then if you are sure that everything works, upload to Ubuntu. Unlike me, who uploads his own package to Ubuntu and only then notices a FTBFS in Ubuntu.
[20:06] <ari-tczew> ok
[20:10] <ari-tczew> Ampelbein: if there is a merge which is available since e.g. half year, should do I ask?
[20:10] <ari-tczew> (or more)
[20:12] <Ampelbein> ari-tczew: Use some common sense. Is the TIL otherwise active in Debian/Ubuntu? Is it something critical or just a minor fix for a spelling mistake in the manpage?
[20:13] <infinity> ari-tczew: There may always be a reason for an outstanding merge.  Age doesn't mean much.
[20:13] <infinity> ari-tczew: (My dpkg merge is a month old now, and there's definitely a valid reason I haven't merged it, for instance)
[20:13] <ari-tczew> Ampelbein: I'm just asking theoretically
[20:14] <infinity> I'd like to think, of course, that in the case of dpkg, a sponsor would shut you down if you tried to merge it, but still worth asking so you don't waste your time.
[20:14] <Ampelbein> ari-tczew: I can't give you a definite answer (I believe noone can). In any case, if a merge is 6 months old, it doesn' hurt to ask the TIL and wait another week for an ok.
[20:15] <Ampelbein> There are literally tens of thousands of bugs open, you can work on any of those while waiting ;-)
[20:17] <ari-tczew> Ampelbein: I'd like just to clean out outstanding merges from trivial syncs and then to ship new upstream releases (now it's quite too late, only a few days are remaining to FFe)
[20:21] <Ampelbein> ari-tczew: I understand that. But there are few situations where waiting a week is hurting.
[21:09] <xnox> ari-tczew: i didn't read a whole scrollback, but essentially working especially on finding (a) packages that can now be synced (b) "pointless merges" (e.g. debian changes email, bumps standards version, etc. without actually fixing any bugs) doesn't bring any visible benefit to Ubuntu. Because the reason why sync is now possible is most likely because the person who TIL forwaded the changes to debian and they got accepted there, so TIL person will no
[21:09] <xnox> tice it.
[21:10] <xnox> ari-tczew: (b) will cause a package rebuild, bump version, but again there is no benefit to the user, that "Standards-Version" is now the latest.
[21:12] <xnox> ari-tczew: it's better to for example focus on fixing bugs in highest crashing apps: https://errors.ubuntu.com/?release=Ubuntu%2013.10&period=year or for example focusing on fixing otherwise high priority bugs for packages of your interest.
[21:13] <xnox> or looking at the merges list, and seeing/identifying which patches (a) make sense to be in debian (b) haven't been forwarded to debian yet. And doing modifications / forwarding patches to debian sensibly.
[21:13] <xnox> "Getting packages in sync" with debian is ubuntu goal. But it means "actually do the work, prepare patches against debian package, test it & send to debian". Rather then filing "requestsync bugs and/or doing syncpackage" that's just a minor last step.
[21:14] <xnox> ari-tczew: Fixing these http://qa.ubuntuwire.com/ftbfs/ is also a good way to contribute to ubuntu.
=== freeflying_away is now known as freeflying
=== Soupermanito is now known as GridCube_