| OdyX | tkamppeter_: Hi. Can you enlighten us on Debian's #698141 ? As I understand it, 2) is the answer, right ? | 09:37 |
|---|---|---|
| === tkamppeter_ is now known as tkamppeter | ||
| tkamppeter | OdyX, 1, 2, 4 is corect, 3 is wrong. | 09:58 |
| OdyX | tkamppeter: great, thanks | 09:59 |
| tkamppeter | OdyX, 1 needs BrowseLocalProtocols cups, 2 needs BrowseRemoteProtocols cups, 4 needs BrowseRemoteProtocols dnssd and avahi-daemon. | 10:00 |
| OdyX | tkamppeter: ah, fantastic; will add that to the package description then. | 10:02 |
| OdyX | tkamppeter: does it really work on Cups < 1.6 ? | 10:03 |
| tkamppeter | OdyX, I did not test, but the requests it sends to CUPS are only creating and removing queues. This should not have changed between CUPS 1.5 and 1.6. So it should work with old CUPS when appropriate legacy CUPS broadcasting ot browsing is activated as I described above. | 10:23 |
| OdyX | tkamppeter: besides there's no real interest in doing that, no? (unless we'd provide backports) | 10:25 |
| tkamppeter | OdyX, yes, there is really no necessity of using it with 1.5 as you say, as all distros with 1.6 contain it. | 11:02 |
| tkamppeter | OdyX, so in the bug 4) principally works, but in this situation one would use cups-browsed on the remote server instead. | 11:03 |
| ubottu | bug 4 in Launchpad itself "Importing finished po doesn't change progressbar" [Medium,Fix released] https://launchpad.net/bugs/4 | 11:03 |
| === elmo__ is now known as elmo | ||
| === Cheery_ is now known as Cheery | ||
| infinity | Does anyone else find GCC's '-mcmodel=large' option hilarious? Or am I just suffering lack of sleep? | 15:33 |
| === cjwatson_ is now known as cjwatson | ||
| penguin42 | infinity: You need some sleep | 15:40 |
| === Claudinux__ is now known as Claudinux | ||
| === highvolt1ge is now known as highvoltage | ||
| === Claudinux_ is now known as Claudinux | ||
| mzaza | Hello, I just finished learning C++ and I was looking to contribute to a C++ project to master the language and extend my skills. Any recommendation for small scale project someone with almost no experience could start working on? | 19:08 |
| mzaza | Is that the right place to ask such question? | 19:11 |
| penguin42 | it's a bit general here - but there are lots of C++ based projects; Qt is heavily C++ | 19:15 |
| JanC | often the best way to get started in a project is to investigate & fix some bugs in the bug tracker of the project | 19:16 |
| infinity | `reverse-depends libstdc++6` is a lovely list of C++ projects. | 19:16 |
| jbicha | could someone mark https://code.launchpad.net/~darkxst/ubuntu/raring/gnome-contacts/lp1033262/+merge/167876 as merged | 19:20 |
| stgraber | done | 19:21 |
| infinity | Wouldn't the importer have caught that on its own anyway? | 19:21 |
| infinity | Well, once it was accepted, I guess. | 19:22 |
| stgraber | not sure, in my experience the only reliable way to get one of those closed is to have them properly merged in the UDD branch or have a TB member manually mark them as such. | 19:22 |
| stgraber | I'm not sure how the importer would notice that this specific branch has been merged, short of trying to merge every pending branch and see if the result matches the current state of the world | 19:22 |
| infinity | stgraber: It seems to do an okayish job if you upload something pretty close to identical and then it's imported into the branch. | 19:23 |
| jbicha | what would I need to do if I wanted to properly merge it? | 19:23 |
| infinity | (But it's certainly not foolproof) | 19:23 |
| infinity | jbicha: Merge to the branch, then upload from that, though I never do that either. | 19:23 |
| jbicha | I tweaked the description and the version number so I don't know if it would catch that they're the same | 19:23 |
| stgraber | jbicha: bzr merge into the branch, commit and push. That should mark the branch as merged (or we have some other bug on LP) | 19:23 |
| infinity | Frankly, it's fundamentally broken if you can upload to something, but not commit or mangle MPs. | 19:24 |
| jbicha | or I could ask darkxst to kill it I guess | 19:24 |
| stgraber | anyway, pinging on IRC to have a TB member change the status is fine too, most people do that and it's the advantage of being effective immediately (so the entry disappears on the sponsoring list) | 19:24 |
| stgraber | infinity: yes, the ACL or lack thereof has been annoying for a long time, mangling those MPs is pretty much restricted to the TB at the moment | 19:25 |
| stgraber | (well, ~ubuntu-branches which is TB + James Westby + the package importer role account) | 19:26 |
| stgraber | it'd make a lot more sense to have those use the upload ACLs instead, but I guess that needs quite a few changes to LP and it's never been high priority | 19:26 |
| infinity | Any reason to not add, at least, core-dev to that group? | 19:26 |
| infinity | (But yes, they should have finer-grained upload ACL mappings, but that's Real Work) | 19:27 |
| infinity | core-dev seems sane, though. They can upload to everything in Ubuntu, so why not also be able to mangle MPs for ubuntu branches? | 19:27 |
| infinity | And that's as simple as adding them to the ubuntu branches group. | 19:28 |
| stgraber | I'd be fine with adding coredev and think that'd make sense, though it may be best to ask one of the folks who setup that stuff to confirm that doesn't give some very weird rights as well | 19:28 |
| jbicha | stgraber: thanks | 19:28 |
| infinity | wgrant: Do you know, off-hand, if ~ubuntu-branches confers any weird/fancy privs that would be inappropriate to give to ~ubuntu-core-dev? | 19:29 |
| infinity | james_w: ^ | 19:29 |
| infinity | jbicha: Accepted. | 19:31 |
| jbicha | infinity: ooh that was fast :) | 19:31 |
| stgraber | infinity: do you know if someone is supposed to be able to commit to the release pocket branch of a released series? I thought that wasn't possible but apparently I can, so that may be a difference between ~ubuntu-branches members vs non-members | 19:31 |
| infinity | stgraber: I suspect anyone *can*, there's just no point. | 19:32 |
| infinity | stgraber: And there's no real harm in letting people do so either, it's not like we build from bzr or anything, so it would just be a lame revision. | 19:33 |
| Laney | Yeah, it denies the push for me | 19:33 |
| infinity | Curious. | 19:33 |
| stgraber | ok, so that's indeed a difference then | 19:33 |
| infinity | A difference that's probably meaningless, as above. | 19:34 |
| Laney | Maybe. Hopefully. | 19:34 |
| infinity | Cause, really, who cares if someone pushes to a dead branch? | 19:34 |
| stgraber | indeed | 19:34 |
| infinity | Now, if we ever want to move to a build-from-VCS model, we need to get sane ACLs on all of this, but we're laughably nowhere near such a utopia. | 19:35 |
| stgraber | outside of that, ~ubuntu-branches members can obviously do stupid things like removing the branches, or changing which is the master branch, both tend to confuse the importer a fair bit, but are sometimes necessary and difficult enough to do (requires API) that it's unlikely to happen by accident | 19:35 |
| infinity | (Though, actually, to be fair, I could write the VCS->dpkg-souce->upload bot over a weekend... I just kinda don't want to force such a shift with things in such a shambles on that side of the world, while source uploads Just Work) | 19:35 |
| Laney | Can they do non-stupid things like fixing the importer? | 19:36 |
| mzaza | penguin42: What exactly could I start working on in Qt, because Qt is big project and bigger than my level I think... | 19:36 |
| Laney | 'cause that would be good | 19:36 |
| stgraber | so yeah, until wgrant or james_w can think of something else, it should be safe to add coredev to the team | 19:36 |
| infinity | Laney: If they can remove branches and change the master, then they could also fix a stuck/confused importer, since I think that's the general fix... | 19:36 |
| stgraber | Laney: kinda, we can run the scripts on our own machines, do the import and push the new one on top of the other. I've been doing that for a few stuck branches. | 19:36 |
| penguin42 | mzaza: I don't know the Qt guys well, but try looking at their own mailing list - they'll have bugs and features they want to add | 19:36 |
| stgraber | Laney: though the real way of fixing the importer needs ssh access to a box in the DC and mangling its database to unblacklist the branch. | 19:37 |
| Laney | Yeah, wouldn't know anything about what's good to do there | 19:37 |
| penguin42 | mzaza: Similarly KDE, and I think Unity | 19:37 |
| Laney | but "try this thing, it might work but won't make it worse" could be useful in the right hands | 19:37 |
| infinity | stgraber: I guess if we ever decided to swap to build-from-VCS, that would fix all the importer bugs in one go. | 19:37 |
| mzaza | penguin42: Yes, It's just do you think I can get enrolled in such projects. When I looked at the KDE's source code I felt lost :D | 19:37 |
| stgraber | infinity: sure, it'd guarantee we'd be in sync, you just wouldn't be able to "upload" instead of having an out-of-sync branch post-upload :) | 19:38 |
| infinity | stgraber: Well, there would be no "uploading", just pushing a tag. | 19:38 |
| infinity | Or a pair of tags, in the case of a new upstream. | 19:38 |
| stgraber | infinity: sure, though what usually confuses the importer are some of the weird merges done in the bzr branch, those would likely make the source package building part of the process explode in a similar way | 19:39 |
| penguin42 | mzaza: Pick a project that you use, then go and ask at that project - they often have starter projects; e.g. small bugs and things | 19:39 |
| stgraber | infinity: so just moving the problem, though we'd indeed safe ourselves from all the problems related to .dsc imports for Ubuntu (we'd still need that for Debian) | 19:39 |
| infinity | stgraber: The source package part is just "build orig from upstream tag" then "build source package from Ubuntu tag". That can't go "wrong" unless what you pushed is unbuildable. In which case, you push a new version. | 19:40 |
| jbicha | I wouldn't mind so much if the UDD branches were debian/ only | 19:40 |
| infinity | stgraber: For Debian sync --force, if people aren't attached to obsolete Ubuntu history, you just wipe the packaging branch and import a fresh copy with no history. | 19:40 |
| infinity | jbicha: The way I did this in git with maemo, the packaging branches were essentiall just debian, in that they were a topic branch on top of an upstream import. | 19:41 |
| infinity | jbicha: So, you had the full source there, but only the debian bits were represented in the branch, in reality. | 19:41 |
| infinity | Import a new upstream, tag foo_1.2.3, switch to packaging branch, fix, fix, test, tag foo_1.2.3-1, push, rejoice. | 19:42 |
| jbicha | I meant like the ~ubuntu-desktop branches with bzr-builddeb merge mode or something similar | 19:42 |
| infinity | jbicha: But, in a 'build-from-VCS' world, you need to get your orig from somewhere, it can't just magically appear. | 19:43 |
| infinity | jbicha: So, you need that upstream branch. | 19:43 |
| infinity | And, if we're being anal about it, we also need pristine-tar. | 19:43 |
| jbicha | I don't trust 'bzr mu' to do the right things in a full-source branch as I've had problems before | 19:43 |
| stgraber | infinity: hmm, yeah, I guess building the source package should always work unless you messed the branch to the point of having it unreadable (but then you should just re-create it). The usual problems are imports and merges so we'd just hit those points for the Debian UDD branches (on the importer), during merges from Debian (on the developer's machine) and for syncs (unless we wipe the history). | 19:44 |
| infinity | stgraber: To my mind, wiping history on syncs would be an acceptable compromise, I suspect people who hate losing history EVAR would disagree. | 19:44 |
| infinity | stgraber: But we already lose history on syncs in the source-package-centric world. We drop all changelog deltas, etc. So, it's analogous. | 19:45 |
| infinity | But you could also just do a shallow force overwrite on syncs. | 19:45 |
| stgraber | well, I suppose some will argue that anything we can pull from the archive or LP (through pull-lp-source) should also be available as tag in the branch, I don't really care much myself though | 19:46 |
| infinity | Preserve all history up until then, wipe the top revision clean, replace with Debian's contents, have an icky huge diff that might be nonsensical. | 19:46 |
| infinity | The key being that if the top revision matches bit-for-bit with your sync, it doesn't really matter if you preserved history or not. | 19:47 |
| infinity | You just can't be silly and try to MERGE a sync in. | 19:47 |
| infinity | (ie: a sync -f would assume you want the tip to match Debian, even if you had staged commits that post-date the last tag) | 19:47 |
| infinity | I hate when I start talking about this and think I should start implementing it. Cause I pretty much refuse to implement it on top of bzr, and I don't want to have the cost-analysis-of-switching-to-git argument this week. | 19:48 |
| stgraber | ;) | 19:50 |
| infinity | Ultimately, I think build-from-VCS (but publish source packages to the archive, on CDs, and to buildds) is the right answer. And not actually a *ton* of work. It's the bzr-vs-git argument that's the soul-draining bit. | 19:50 |
| infinity | And, coming from someone who likes working with source packages, and never uses UDD, that's saying something. :P | 19:53 |
| stgraber | well, that's because you currently can't trust UDD, doing things with UDD, then producing a debdiff with what's in the archive because you don't trust it isn't terribly efficient :) | 19:54 |
| infinity | stgraber: To be honest, I still used that workflow even in a build-from-VCS that I trusted. | 19:55 |
| infinity | stgraber: I want to know what the bot's going to do to my tag, so I'd still dpkg-buildpakage and debdiff before I pushed the tag. | 19:55 |
| infinity | (Which also saves on angry emails when the build fails) | 19:55 |
| infinity | But it's nice when the lack of trust is only in myself, and not also in my tools. | 19:56 |
| stgraber | right, build-from-VCS is no excuse to stop test building locally so yeah, doing an extra debdiff on top of that isn't really time consuming | 19:56 |
| === yofel_ is now known as yofel | ||
| infinity | bzr doesn't do signed tags, does it? | 20:00 |
| infinity | That's another argument for git in this sort of workflow, cause the tag signature is what you check on "upload". | 20:01 |
| stgraber | infinity: that sounds right, so in the bzr world we'd have to required a signed commit containing some indication that we want a build | 20:03 |
| infinity | Well, my neighbor just invited me over for beer, I'm saved from having to think about this any more this afternoon. | 20:08 |
| stgraber | yeah, doesn't sound like the kind of thing you should be spending your Sunday afternoon thinking about. Have fun! | 20:09 |
| infinity | Laney: What have you got against girraffes anyway? | 20:11 |
| Laney | They're so tall. It's creepy. | 20:28 |
| === sunweave1 is now known as sunweaver | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| jbicha | "We collect hundreds of thousands of error reports daily from millions of machines." really? https://errors.ubuntu.com/ | 22:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!