| === jamesh_ is now known as jamesh | ||
| === icey_ is now known as icey | ||
| seb128 | SRU team, could you review those uploads libxmlb in bionic/NEW , then fwupd in bionic and fwupd-signed in bionicNEW? they have been sitting there unreviewed for some weeks and oem is waiting on them | 09:09 |
|---|---|---|
| Laney | bdmurray: are you aware of the error tracker being quite unresponsive lately? | 09:34 |
| tjaalton | seb128: sru team can't handle NEW | 09:41 |
| tjaalton | not all of us anyway | 09:41 |
| tjaalton | only AA's | 09:41 |
| seb128 | tjaalton, should I just accept it myself then? ;) | 09:41 |
| seb128 | or does it still need to go through the sru-accept script or whatever? | 09:41 |
| seb128 | I guess best is to have a SRU team member who is AA to accept it | 09:42 |
| tjaalton | if it's not on the queue anymore, then the next step is to accep it from new? | 09:42 |
| tjaalton | *accept | 09:42 |
| seb128 | you mean not in the queue? | 09:42 |
| seb128 | tjaalton, https://launchpad.net/ubuntu/bionic/+queue?queue_state=0 | 09:43 |
| seb128 | it's still there | 09:43 |
| tjaalton | unapproved queue, which the sru team handles | 09:43 |
| tjaalton | fwupd is | 09:43 |
| tjaalton | also, generally #ubuntu-release is a better fit for sru pings | 09:44 |
| tjaalton | so things are not lost in noise | 09:44 |
| seb128 | should I ask there again? | 09:45 |
| tjaalton | nah | 09:45 |
| seb128 | tjaalton, since we are speaking SRU, could you review/approve the update-notifier/bionic one I just uploaded? it's some fixes to the current one that failed verification | 09:58 |
| SwedeMike | tty0: /win 207 | 09:58 |
| SwedeMike | oops | 09:58 |
| seb128 | tjaalton, should be an easy one, it's some lines of python diff which are pretty simple | 09:58 |
| juliank | So | 10:02 |
| juliank | PackageKit installs multiple service files | 10:02 |
| juliank | It runs dh_installsystemd --no-enable --no-start --no-restart-after-upgrade | 10:02 |
| juliank | which is OK for packagekit.service and offline-upgrades.service | 10:02 |
| juliank | but I'm adding the user/pk-debconf-helper.socket, and I do need that enabled | 10:02 |
| juliank | do I have to make two calls, one for existing units, and one for the socket? | 10:05 |
| === cpaelzer_ is now known as cpaelzer | ||
| juliank | Oh I guess I should just ship a symlink | 10:07 |
| LocutusOfBorg | juliank, hello, any reason for not having forwarded dkms patch upstream? https://github.com/dell/dkms/commits/master | 10:54 |
| juliank | no reason | 10:55 |
| blackflow | Hello, trying to figure out how to find deb src source that's actually used to produce .deb files, through LP. In particular I'm interested into the linux kernel package, I wanna see the patches Ubuntu is adding. | 10:55 |
| LocutusOfBorg | juliank, will you do it, or shall I do? I don't honestly want to touch your patches, but I can do if needed | 10:56 |
| LocutusOfBorg | blackboxsw, pull-lp-source linux gets the latest version in development (needs installed ubuntu-dev-tools) | 10:57 |
| LocutusOfBorg | otherwise apt-get source does the job I guess | 10:57 |
| Unit193 | dget https://path/to/package.dsc is nice. | 10:58 |
| juliank | LocutusOfBorg: does not make sense to forward really | 10:59 |
| juliank | LocutusOfBorg: It's only needed for shim_secureboot_support.patch | 10:59 |
| juliank | and that's not upstream eithert | 10:59 |
| blackflow | LocutusOfBorg: well the thing is, `apt-get source linux` doesn't seem to include the patches... | 11:03 |
| blackflow | Could someone please direct me to the source code of the final, binary Linux(tm) kernel package as distributed and installed in "Ubuntu(tm) Linux 18.04.2 Bionic Beaver", I believe the redistributed binary package is linux-image-4.15.0-50-generic. I am unable to locate the (reproducible) source and lack of such access is GPL violation. Under GPLv2 provision 3, subsection (A), the binary package | 11:26 |
| blackflow | must be accompanied "with the complete corresponding machine-readable source code". It is not. | 11:26 |
| Unit193 | Oh hah, someone goofed: gcr-viewer.desktop:X-GNOME-Bugzilla-Component=gcrX-Ubuntu-Gettext-Domain=gcr | 11:27 |
| cjwatson | There's no GPL violation, we absolutely provide the source. https://launchpad.net/ubuntu/+source/linux/4.15.0-50.54 has it if you can't get apt-get source to work | 11:32 |
| cjwatson | (Our processes are such that it's not possible for us to provide binaries in Ubuntu without the source also being available) | 11:33 |
| cjwatson | If you're having a technical problem with the build then #ubuntu-kernel will probably be better-able to help | 11:34 |
| cjwatson | The linux package doesn't break out its patches into separate files, but there's no GPL requirement for that - they're just applied directly to the unpacked source package that apt-get source linux gives you | 11:35 |
| cjwatson | If you're trying to trace individual patches then https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic might be more helpful | 11:35 |
| juliank | Will be uploading aptdaemon in a minute | 11:40 |
| juliank | Fxed the test suite | 11:40 |
| juliank | :) | 11:40 |
| juliank | Let's turn all those red autopkgtests green again | 11:40 |
| rbasak | blackflow: what Colin says - we do publish the source, through the "apt-get source" mechanism. If you can't figure out how to use our tooling, then you're welcome to try and get help here, but your technical inability to deal with our preferred tooling is not a GPL violation and screaming about it here is only going to put people off helping you. | 11:40 |
| rbasak | blackflow: and no, there is no requirement in the GPL that binary packages include their sources. No binary distribution does that. We do publish the sources alongside in the apt repository, which has long been considered sufficient by all those in the community. Debian does it the same way. | 11:41 |
| blackflow | cjwatson: separate patches would be nice, but I can always diff myself, if I knew what to compare and I don't because the whole process is not transparent. Even now with the links you gave I am not sure which, of the gazillion links that follow from there, is the source code for the redistributed binary installed on my PC. | 11:41 |
| rbasak | blackflow: there is nothing special or obscure here. It works the same as any other Debian package. | 11:42 |
| blackflow | rbasak: fine, but published _where_. How do I find them. | 11:42 |
| cjwatson | blackflow: The three files under Downloads | 11:42 |
| cjwatson | .orig.tar.gz, .diff.gz, .dsc | 11:42 |
| cjwatson | dpkg-source -x foo.dsc then unpacks that | 11:42 |
| juliank | this is not rocket science | 11:42 |
| blackflow | rbasak: and that's not true. I found Debian's sources, with patches, with literally three links from packages.debian.org. I'v been trying to find the same/similar via LP for over an hour now. | 11:43 |
| cjwatson | But this is just the same as what apt-get source linux should already have given you (possibly modulo minor version differences) | 11:43 |
| rbasak | blackflow: packages.ubuntu.com also exists. | 11:43 |
| juliank | blackflow: Go to https://launchpad.net/ubuntu/+source/linux | 11:43 |
| juliank | blackflow: Click the version | 11:43 |
| juliank | blackflow: There are three files under downloads | 11:44 |
| juliank | blackflow: Download them | 11:44 |
| juliank | blackflow: dpkg-source -x them | 11:44 |
| juliank | blackflow: And you are done | 11:44 |
| blackflow | juliank: thanks. | 11:44 |
| juliank | If you want the individual patches / commits on top of the combined diff, clone the git repository listed in Vcs-Git | 11:45 |
| juliank | or just do debcheckout linux | 11:46 |
| juliank | Ran 79 tests in 58.138s | 11:46 |
| juliank | OK (skipped=22) | 11:46 |
| juliank | WOOOHOO | 11:46 |
| juliank | Gotta SRU the test suite fixes with the other stuff, so we get proper SRUing for aptdaemon | 11:47 |
| blackflow | wel I don't need the patches per se as much as I need to find what exactly is Ubuntu adding to the kernel.org sources. | 11:47 |
| blackflow | which I would from teh patches, or, lacking them, from a diff, but for that I need it to be transparent enough to know what is what. | 11:48 |
| juliank | well, that's in the .diff.gz | 11:48 |
| juliank | the patches are applied directly to the upstream source from the .diff.gz | 11:48 |
| juliank | there are no debian/patches | 11:48 |
| blackflow | I see. but is there no versioning tracker for those modifications? | 11:50 |
| === ricab is now known as ricab|lunch | ||
| juliank | There's a git repo | 11:50 |
| juliank | the diff.gz is the diff from the git repo to the upstream one | 11:51 |
| Unit193 | I believe the git repo was linked to you twice now. | 11:51 |
| juliank | the git repo even has tags! | 11:51 |
| blackflow | Unit193: Yes, I'm looking through it right now. | 11:52 |
| blackflow | problem is, this is a black box, nearly impossible to understand, to an outsider like me (and I'm not a noob in coding or contributing to open source packages). Of course this is easy for y'all, Dunning-kruger and all. It is extremely frustrating to someone else. | 11:53 |
| blackflow | and by "this" I mean the millions of repos, subrepos, links, tarballs, versions, subversions, etc... with no documentation or indication as to what is what. | 11:54 |
| juliank | It's not a blackbox | 11:54 |
| juliank | it's standard tooling | 11:55 |
| cjwatson | It's an inherently complex system, though we're gradually working towards doing everything in a more consistent set of git repositories; it'll take time | 11:55 |
| juliank | It's listed in Vcs-Git, it can't get easier than that | 11:55 |
| juliank | I want to find the source code: I run apt source linux; oh I want git, let me look at Vcs-Git | 11:56 |
| cjwatson | (Also I'm not quite sure that Dunning-Kruger is the study you're reaching for here, unless you're saying we're all too incompetent to know our own limitations, which doesn't make sense with the rest of your sentence) | 11:56 |
| juliank | ooh it's there, let me clone that repo | 11:56 |
| juliank | -> done | 11:56 |
| juliank | works on a lot of packages | 11:56 |
| juliank | (some do have debian vcs-git but ubuntu changes, but linux is not one of them) | 11:56 |
| cjwatson | Eventually "git ubuntu clone linux" will work consistently | 11:57 |
| Unit193 | 'linux' isn't the least complex either though, most packages just have changes stacked on top whereas linux acts more like a fork, I'd think. | 11:57 |
| cjwatson | I don't know whether it yet does | 11:58 |
| juliank | linux is complex in that the signed binary is produced by linux-signed | 11:58 |
| blackflow | cjwatson: no I was referring to the other side of the effect. you're too skilled and too knowledgeable about these processes to understand how it looks like to someone who is not. | 11:58 |
| juliank | so source linux-image-$(uname -r) gives you the wrong package | 11:58 |
| cjwatson | As a matter of fact I do understand that it is complicated, but I think you're overstating somewhat based on my experience with other people | 11:58 |
| juliank | blackflow: this is basic debian packaging | 11:58 |
| cjwatson | Most people don't jump straight to GPL violation :) | 11:59 |
| cjwatson | We're working on improvements | 11:59 |
| cjwatson | But throwing metaphorical rocks doesn't really help | 11:59 |
| === alan_g is now known as alan_g|lunch | ||
| blackflow | no I stand behind what I said. this is all easy-pease, "standard this", "standard that", to someone who's neck-deep into the process for years. the violation is that somoene who got the binary part, does not have obvious access to the soruces. they're buried under layers and layers and layers of abstraction and redirection of a megaton of repos, subrepos, links, versions, ... | 12:01 |
| blackflow | sans teh typos. | 12:01 |
| juliank | no they're not | 12:03 |
| juliank | the number of layers is the same as for debian to get to working source code | 12:03 |
| juliank | then there is one more layer if you need individual changes | 12:03 |
| cjwatson | You're massively overstating things. "apt-get source linux" gives you the source. | 12:03 |
| cjwatson | That's not a megaton of repos and subrepos and stuff. | 12:03 |
| blackflow | and yes, GPL _does_ require sources accompany the redistributed binary. Provision 3(A) of GPLv2 (under which the kernel is licensed). Unless you want to redefine the word "accompany". | 12:04 |
| juliank | And they do | 12:04 |
| * cjwatson is out of this conversation since it isn't productive | 12:04 | |
| juliank | Both binaries and source are in http://archive.ubuntu.com/ubuntu/pool/main/l/linux/ | 12:05 |
| juliank | they are also both in launchpad | 12:05 |
| LocutusOfBorg | blackflow, did you try... pull-lp-source linux bionic? | 12:05 |
| LocutusOfBorg | easy, and works with every launchpad package/distro | 12:06 |
| LocutusOfBorg | in a consistent way | 12:06 |
| LocutusOfBorg | even version | 12:06 |
| LocutusOfBorg | even old version | 12:06 |
| sladen | blackflow: there is a significant overlap in people + technology + source code between Debian and Ubuntu: people who care about source availability and being able to recompile from scratch | 12:09 |
| LocutusOfBorg | I really don't get all this kind of troubles, apt-get source or pull-lp-sorce works both on my bionic machine, as well as dpkg-buildpackage seems to be running on kernel | 12:11 |
| sladen | blackflow: there are *multiple* versions of "the source code" for a package (ie. "linux" kernel), *and* multiple ways of obtaining the source code: which *exact* version, and which *exact* method is not working---we would love to fix it if there is something broken | 12:11 |
| sladen | blackflow: please can you past the *exact* commands being used: then we can help pin-point any errors | 12:12 |
| sladen | paste | 12:12 |
| rbasak | blackflow: from a GPL compliance perspective, it's best to just consider "apt-get source" _the_ way of doing it. No other layers of abstraction. The same apt repository ships all sources for all its binaries, side-by-side. | 12:16 |
| blackflow | sladen: I got the diffs now (see above), after asking here. | 12:17 |
| rbasak | blackflow: if you think that's a GPL violation in itself because the sources aren't shipped inside the binary packages, then that's your opinion, but I don't think it would match the opinion of anyone involved, not even the FSF. Debian does it the same way, and I believe Trisquel (FSF-endorsed) probably does too. | 12:17 |
| blackflow | rbasak: no, I think the frustration to get to the sources is the violation. | 12:17 |
| rbasak | blackflow: what's wrong with "apt-get source"? | 12:18 |
| blackflow | but neway, I got the diffs now, thanks. | 12:18 |
| blackflow | rbasak: which package name? :) | 12:18 |
| blackflow | because sources for linux-image-$(uname -r) ain't int | 12:18 |
| blackflow | *it | 12:18 |
| rbasak | blackflow: clearly it's not reasonable to block outsiders from access that insiders have. But I don't see how the GPL requires anything further than that. | 12:19 |
| rbasak | As I say, I don't think that community consensus (across the entire ecosystem) expects anything further. Clearly the majority of people in the world won't know how to get the source regardless of what we do. | 12:19 |
| rbasak | The only standard is that it's available to the same level that we access it ("preferred source") | 12:20 |
| rbasak | And we do meet that. | 12:20 |
| juliank | rbasak: the only real-ish problem is that linux-image is built by linux-signed and you need to figure out that it gets the binaries it signs from linux | 12:20 |
| juliank | that's a small discoverability problem | 12:20 |
| blackflow | rbasak: maybe I'm just spoiled by distros like gentoo which have a very straightforward (and easily accessible) path to the sources (even if you forget teh fact that you literally get teh sources via portage first thing). after working with gentoo (and FreeBSD) packages and sources, I found myself in the Twisty Passages, all alike, in the Ubuntu world. | 12:20 |
| sladen | "straight-forward" | 12:21 |
| rbasak | blackflow: it could be better, yes. We're working on that. However it's not really significantly different from Debian (certainly any Debian developer wouldn't have a problem finding Ubuntu sources), and the reason it's like this is that Debian pre-dates all modern tooling. | 12:21 |
| rbasak | (unless you count CVS) | 12:21 |
| sladen | blackflow: please make a suggestion for how to make it *even* more "straight-forward" | 12:21 |
| rbasak | sladen: "where can I git clone the sources for package X from?" | 12:22 |
| rbasak | I think in the modern era that's a reasonable request. | 12:22 |
| juliank | portage is a lot less straight forward | 12:22 |
| rbasak | But we (and Debian) predate git. | 12:22 |
| juliank | It does not even ship the source code alongside the patches | 12:22 |
| juliank | same for freebsd ports | 12:22 |
| sladen | blackflow: would eg. git clone ubuntu:linux for straight-forward/enough, or could things be made even simpler? | 12:23 |
| blackflow | rbasak: it's much different (and easier) with Debian. https://tracker.debian.org/pkg/linux-latest and there's a Browse Source Code link on the right, poof done. It is NOT like that in Ubuntu. The repo you linked above is not the one you get from the linux package in LP. | 12:24 |
| rbasak | blackflow: and how did you find tracker.debian.org? | 12:24 |
| blackflow | and I got to that tracker page easily, "Developer Information" from here: https://packages.debian.org/buster/linux-image-amd64 | 12:24 |
| blackflow | so the binary package name led me to the source in three clicks. | 12:24 |
| blackflow | rbasak: I asked google, just like I asked google for Ubuntu. | 12:24 |
| TJ- | how about teaching apt-get source the option of using the Vcs-*: field of the package control file to do a suitable VCS clone of the source (which includes commit history) as opposed to just a snapshot fetch of the source as it does by default? | 12:25 |
| Unit193 | TJ-: That's what `debcheckout` does. | 12:25 |
| juliank | TJ-: It tells you to use debcheckout | 12:25 |
| juliank | TJ-: Well, to git clone the repo | 12:25 |
| juliank | git clone git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/disco | 12:25 |
| juliank | to retrieve the latest (possibly unreleased) updates to the package. | 12:25 |
| juliank | is precisely what it says | 12:25 |
| juliank | blackflow: So, and for portage or freebsd ports it's _a lot_ harder | 12:26 |
| sladen | blackflow: equivalent of packages.debian.org is packages.ubuntu.com https://packages.ubuntu.com/eoan/linux-image-generic | 12:26 |
| TJ- | juliank: isn't that only when you're already doing "apt-get source <package>" though? it's not the same as being able to do "apt-get source --vcs <package>" which is what I'm suggesting | 12:26 |
| LocutusOfBorg | with a "download source package" in only one click | 12:26 |
| rbasak | blackflow: start from https://packages.ubuntu.com/, search for the filename whose sources you're interested in, go to that package, see "Download Source Package" on the right. | 12:26 |
| blackflow | sladen: yes. And how many clicks to reach the source from there? | 12:26 |
| LocutusOfBorg | blackboxsw, ONE | 12:26 |
| LocutusOfBorg | one single click | 12:26 |
| LocutusOfBorg | directly on the page | 12:27 |
| juliank | TJ-: Well, yes, but you do have a Ctrl and a C key | 12:27 |
| LocutusOfBorg | "Download Source Package linux-meta: " | 12:27 |
| blackflow | no, that's for linux-meta | 12:27 |
| juliank | And the Debian one is for linux-latest | 12:27 |
| LocutusOfBorg | ok two clicks | 12:27 |
| LocutusOfBorg | you click on the actual package, in this case https://packages.ubuntu.com/eoan/linux-image-5.0.0-15-generic | 12:27 |
| LocutusOfBorg | and then download source package | 12:27 |
| juliank | it's impossible to get from the source code from there | 12:27 |
| LocutusOfBorg | still one less click than debian | 12:27 |
| blackflow | LocutusOfBorg: still nope, that's linux_signed :) | 12:28 |
| rbasak | In any case, I still insist that "apt-get source" is the cleanest way to get the source for the binary that you have just installed (for example), and that is a very well known mechanism. | 12:28 |
| blackflow | LocutusOfBorg: do you see my frustration now? :) | 12:28 |
| rbasak | We don't control Google so it isn't reasonable to use Google against us just because it doesn't find it easily for you. | 12:28 |
| juliank | blackflow: Same problem in Debian | 12:28 |
| LocutusOfBorg | blackboxsw, one more click https://packages.ubuntu.com/eoan/linux-modules-5.0.0-15-generic | 12:28 |
| LocutusOfBorg | so equal to Debian :D | 12:28 |
| juliank | blackflow: Just that in Debian, your kernel package will be named linux-signed | 12:28 |
| blackflow | juliank: I beg to differ. I found the debian source in three clicks. I've been looking for the correct one in LP for an hour before I came here, frustrated. | 12:28 |
| juliank | Well, linux-image-signed or something | 12:28 |
| TJ- | juliank: but the point of all this discussion is about ease of discoverability and capture even when unfamiliar with the Debian/Ubuntu packaging ecosystem. I'm suggesting teaching apt-get to do it, no matter what VCS the package uses (e.g. I have to read man-pages to refresh my mind if it's bazaar, or hg (mercurial). | 12:29 |
| rbasak | blackflow: as I said before, your personal inability doesn't make it a GPL violation. | 12:29 |
| blackflow | TJ-: sic! | 12:29 |
| juliank | TJ-: We're not going to run a command for you based on the control file | 12:29 |
| juliank | you can check the command and run it yourself | 12:29 |
| rbasak | TJ-: the intention is that "git ubuntu clone" will do it correctly. | 12:29 |
| juliank | blackflow: YOu only found the Debian source package because you started from a different spot | 12:29 |
| LocutusOfBorg | and yes, sources.ubuntu.com and codesearch.ubuntu.com might be useful | 12:30 |
| LocutusOfBorg | ^^ | 12:30 |
| blackflow | rbasak: but it's not just my personal inability. this is clear and easy for you because you're familiar with the processes and all the repos. It is totally a black box to anyone who is not. | 12:30 |
| juliank | If you started from Debian's signed kernel image, you'd end up with the same issues | 12:30 |
| rbasak | Though the complexity of mapping for signed kernel packages I don't have a great solution for, except that I hope that one day "git ubuntu clone" will take a file on the local system as input. | 12:30 |
| sladen | ...the discussion about how to make finding source *even easier* (than three clicks) is useful to have. The discussion about not complying the GPL is not useful. Please try to keep conservation focused on useful suggestions and input | 12:30 |
| TJ- | rbasak: OK, so can we teach apt-get to wrap that or state it in help/man-page *before* we've already tried "apt-get source <package>" ? | 12:30 |
| juliank | Also, if you get linux-signed you can read the code and figure out where to go next | 12:30 |
| rbasak | TJ-: I don't think apt is the right tool for this kind of thing any more. | 12:30 |
| rbasak | TJ-: we should document it somewhere, but we should tackle the place that people decide they want to use apt in the first place. | 12:31 |
| sladen | eg. man linux-source | 12:31 |
| rbasak | TJ-: if you care about higher level stuff like package mappings, then apt is too far down the stack already. | 12:31 |
| juliank | huh | 12:31 |
| juliank | no | 12:31 |
| Unit193 | rbasak: The fourth result for 'ubuntu linux kernel' for me was https://wiki.ubuntu.com/Kernel/SourceCode. Regardless, I don't see this discussion going anywhere and only expect it'll devolve more. | 12:32 |
| TJ- | rbasak: Users go to apt by default for package management; moving away from that just introduces more confusion, as the whole bazaar debarcle demonstrated. | 12:33 |
| juliank | Unit193: that page is wrong | 12:33 |
| Unit193 | juliank: Git section looks right. | 12:33 |
| juliank | yes | 12:33 |
| juliank | but the other one is not | 12:33 |
| juliank | gotta have unsigned somewhere in there | 12:34 |
| rbasak | TJ-: I'm not sure what bazaar thing you're referring to, but regardless, apt is about packages in the repository. apt doesn't know (by design) anything above that, such as semantic (as opposed to depends/recommends etc) relationships between packages. | 12:34 |
| sladen | blackflow: https://bugs.launchpad.net/ubuntu/+source/linux/+filebug Please can you file a bug with the title "Make Linux source code even easier to find", and past the bug number here: we can then help to fill out the rest with ideas, and will be able to get back in to contact with you with suggestions are being proposed | 12:34 |
| rbasak | sladen: I'm not sure that's the right place. Maybe the Ubuntu top level project? Because (presumably) no fix can be made in the linux package itself to solve this. | 12:35 |
| TJ- | rbasak: some packages moved to bazaar VCS, then that got abandoned by some and it became almost impossible to reliable determine where to find the correct source. LP especially made that even more difficult with so many out-of-date repos. | 12:35 |
| sladen | rbasak: man page | 12:36 |
| rbasak | TJ-: the correct source has always been the source package, since that is the single source of truth | 12:36 |
| rbasak | sladen: potentially, but it isn't obvious that's the correct answer, and the answer may be something other than in the linux package. | 12:36 |
| TJ- | rbasak: that's silly; most of the time we require the source to see the commit history for e.g. bug-hunting, regression, etc. | 12:36 |
| sladen | rbasak: then we can move it as soon as blackflow has successfully opened the bug report | 12:36 |
| Unit193 | TJ-: Unfortunately, in Debian even the maintainer declared vcs-* fields can be out of date, it's the nature of relying on people that some things are forgotten. | 12:36 |
| juliank | we should have hooks for apt source | 12:36 |
| juliank | so linux images can hook in and say "you probably want linux not linux-signed" | 12:37 |
| juliank | otoh | 12:37 |
| juliank | only linux has that problem | 12:37 |
| TJ- | Unit193: so a deficiency in the process. Maybe there are ways to automate inclusion of the correct Vcs tag? | 12:37 |
| sladen | linux is special ... | 12:37 |
| sladen | perhaps a contributing factor | 12:38 |
| blackflow | sladen: against what? | 12:38 |
| rbasak | TJ-: I'm trying to fix that with git ubuntu. I still maintain that apt isn't the right place to solve this. | 12:38 |
| Unit193 | TJ-: git-buildpackage and other tools do make it easy, but if people no longer use git, move repos without noting, or simply forget to push... | 12:38 |
| sladen | blackflow: https://bugs.launchpad.net/ubuntu/+source/linux/+filebug would open it against linux. COuld also, per suggestion of rbasak file it against the top level "Ubuntu". But we can shuffle it around as sooner is we have the bug number | 12:38 |
| juliank | I still maintain that git-ubuntu is not the solution | 12:39 |
| TJ- | rbasak: that's fine; what I'm saying is apt should tell us *before* we do "apt-get source <package>" there is a better method, not as an aside whilst it is already downloading the source package | 12:39 |
| rbasak | sladen, blackflow: just don't get offended by the autoreplies you get from filing the bug against the linux package, please. | 12:39 |
| juliank | like it's OK as a fallback, but you usually want a proper git-buildpackage repo | 12:39 |
| juliank | it's just another more convenient layer to get the uploaded source packages :) | 12:40 |
| rbasak | If you are an individual package maintainer you probably want a separate repo, yes. | 12:40 |
| rbasak | But if you are a drive by contributor then what you want is a consistent view, and separate repos that follow their own policies are not hat. | 12:41 |
| rbasak | that | 12:41 |
| rbasak | Incidentally, I have a plan to make it possible for your "proper git-buildpackage repo" to _be_ the git ubuntu repo. | 12:41 |
| rbasak | But that's quite far down the road. | 12:41 |
| Unit193 | That seems to favor drive-by people over reg contributors.. | 12:41 |
| juliank | Also, grab-merge is still a lot easier than git-ubuntu | 12:42 |
| rbasak | Regular contributors know what they're doing and so don't need to use defaults. | 12:42 |
| TJ- | rbasak: the reason I suggest *before* is that frequently, when I'm travelling with a poor/limited Internet connection, I chose to pull in and browse source related to some bug I'm investigating. So it is frustrating for at least 2 reasons: 1) source download starts before 'apt-get source' tells me where the packaging Vcs is, and 2) Manually trying to discover the authoriative source-code repo for the | 12:42 |
| TJ- | binary package version I'm investigating | 12:42 |
| rbasak | juliank: history proves you wrong on that. Start using git-ubuntu for merges and you'll continously discover merge errors made by people using grab-merge. | 12:42 |
| Unit193 | TJ-: apt-cache showsrc $pkg will show you before you `apt-get source` | 12:42 |
| rbasak | juliank: (since grab-merge provides no easy way to check for correctness and humans make mistakes) | 12:43 |
| cjwatson | sladen: please remember that when you recommend such URLs to a non-developer they're going to run straight into https://help.ubuntu.com/community/ReportingBugs#Filing_bugs_manually_at_Launchpad.net; better to give an appropriate URL to bypass that, especially when the discussion is already contentious | 12:43 |
| juliank | I run grab-merge, edit the conflicts, generate two debdiffs (old and new), then diff the debiffs, and if that looks right, I upload | 12:43 |
| blackflow | rbasak: you got any more insults before I wrap this up? | 12:43 |
| TJ- | Unit193: yes, but many casual investigators/bug hunters don't know that. If that is so then 'apt-get source' (or its help/man-page) should state that explictly where it is easily discoverable. | 12:43 |
| rbasak | juliank: "if that looks right" --> often it looks right but is wrong | 12:43 |
| juliank | I don't want to split out individual commits and do rebasing for a simple merge, it's just _a lot_ of effort | 12:43 |
| Unit193 | TJ-: Also if you are on a limited connection, you can ctrl+c out of the download. | 12:44 |
| rbasak | git-ubuntu doesn't _require_ you to split out commits. | 12:44 |
| rbasak | If you wish, just use git rebase directly. | 12:44 |
| TJ- | Unit193: indeed, but that is a kludge, not a solution to discoverability | 12:44 |
| rbasak | That's essentially precisely what MoM does. | 12:44 |
| juliank | That only works for throw away the git and upload the dsc scenarios though | 12:45 |
| Unit193 | TJ-: As I noted, the proper discovery is apt-cache showsrc, or just `debcheckout`. | 12:45 |
| juliank | if I want to git ubuntu submit it, people will get nasty | 12:45 |
| rbasak | juliank: I think we're conflating a bunch of things here. | 12:45 |
| rbasak | juliank: there's git-ubuntu the set of imported repositories. There's the MP flow that the server team is using. And there's the merge workflow the server team is using. | 12:45 |
| rbasak | juliank: they don't all have to be used together. | 12:46 |
| Unit193 | rbasak: I don't suppose git-ubuntu is packaged yet? | 12:46 |
| rbasak | juliank: you can use the set of imported repositories only, do it locally using git, and (as a core dev with no peer review requirement) just upload it, if you wish. Nobody will know if you used MoM/grab-merge or git-ubuntu | 12:46 |
| juliank | rbasak: Right, but that means you lose git history | 12:47 |
| rbasak | Unit193: it is a snap. Packaging in the apt repository is insanely hard because of edge case behaviours in dpkg and that kind of thing. | 12:47 |
| Unit193 | Hrm, so it isn't. :/ | 12:47 |
| juliank | also, I think the end goal is to nto upload, but just push? | 12:47 |
| rbasak | juliank: no different from MoM. If keeping git history is a requirement for you, then clearly MoM/grab-merge is unacceptable by that definition. | 12:47 |
| rbasak | Unit193: what do you mean by "it"? The imported repositories are still available :) | 12:48 |
| TJ- | Unit193: I feel we're talking at corss-purposes here. The information is there, yes, but it is buried in a lot of other info. If you don't already know what to look for (not initimately familiar with Debian packaging) it can easily be missed. What I'm suggesting is making discovering the Vcs for the specific binary package an explicit option of some (apt) tool | 12:48 |
| juliank | rbasak: well, yes, but with git-ubuntu there's a history I can render less useful that was not there before | 12:49 |
| Unit193 | rbasak: git-ubuntu was what I was referring to. | 12:49 |
| rbasak | juliank: I don't follow. From my perspective you seem to keep changing your position. What's your actual position? | 12:49 |
| juliank | My position is that in order to be considerate to heavy users of git-ubuntu, I have to follow git-ubuntu best practices | 12:49 |
| juliank | even if I personally don't care about that | 12:49 |
| rbasak | juliank: you mean when you do package merges? | 12:50 |
| rbasak | juliank: or other times too>? | 12:50 |
| juliank | I guess when merging only | 12:51 |
| juliank | or when importing a new upstream version maybe, idk? | 12:51 |
| rbasak | I don't think a new upstream version going in without rich history would bother anyway. | 12:51 |
| rbasak | s/anyway/anyone/ | 12:51 |
| sladen | cjwatson: sure. What URL would be better to give to blackflow? | 12:51 |
| juliank | It's one reason I did not merge multipath-tools last cycle; because it is maintained in git-ubuntu, shared with server team; and the process annoys me a lot | 12:52 |
| rbasak | It is true that if someone is maintaining (multiple package merges) a particular package using git-ubuntu, then it'll be a pain if you stomp in and do a package merge without the git-ubuntu package merge process, because that'll flatten the breakdown of commits as well as any changes you make. | 12:52 |
| rbasak | What we want preserved is the rich version of the Ubuntu delta. We don't care how you get to that. | 12:53 |
| cjwatson | sladen: If you're going to direct somebody to file a bug directly against an Ubuntu package where "ubuntu-bug" is inappropriate or not useful, then you need to add ?no-redirect to the end. But I can't say I'm hugely convinced that the maintainers of the linux source package specifically are in a good position to improve this | 12:53 |
| cjwatson | (However I don't really want to get sucked into debating that, so ...) | 12:54 |
| juliank | cjwatson: one thing I sometimes stumble upon is that'd I'd like to have https://launchpad.net/ubuntu/+source/<binary> | 12:54 |
| sladen | cjwatson: ah yes, kudos for spotting lack of ?no-redirect | 12:54 |
| rbasak | If you flatten that, then for a more complex delta I think it's quite right for people to be upset. That isn't git-ubuntu specific though, that's just a quality thing on doing complex package merges in maintainable way. | 12:54 |
| juliank | redirecting me to the source package | 12:54 |
| juliank | because sometimes I have a binary, and I don't want to do a source package lookup locally first | 12:55 |
| Unit193 | Like the tracker does. I hit the tracker, then click the 'ubuntu' button for that. :P | 12:55 |
| rbasak | juliank: note that the binary->source mapping changes | 12:55 |
| juliank | yes | 12:55 |
| rbasak | So you'd need to qualify it somehow to disambiguate, or define some disambiguation algorithm in any case. | 12:55 |
| juliank | Look at latest series first, and go downward until you find a match | 12:56 |
| juliank | it works reasonably well for Debian tracker | 12:56 |
| rbasak | That wouldn't be helpful to users who might be on the previous LTS with a different mapping. | 12:56 |
| rbasak | I suppose you could add a UI to ask which the user means. | 12:56 |
| rbasak | (as it's a web UI already) | 12:57 |
| cjwatson | juliank: Well, they obviously couldn't go under +source. There actually are binary URLs, but they're some of the worst-linked URLs in LP (https://launchpad.net/ubuntu/bionic/amd64/linux-image-4.15.0-50-generic) | 12:57 |
| juliank | cjwatson: Well, I do want the source package for a given binary | 12:57 |
| rbasak | Ah yes, because arch matters too :) | 12:57 |
| juliank | Like https://tracker.debian.org/apt-utils redirects me to https://tracker.debian.org/pkg/apt | 12:57 |
| cjwatson | Yeah, but it still can't be in +source for name-clash reasons | 12:57 |
| cjwatson | I agree we could do better | 12:58 |
| juliank | Well, if there's a name-clash the source package wins | 12:58 |
| Unit193 | juliank: I have an alias in my browser, pts apt-utils will take me there, as uts apt will take me to the +source page. | 12:59 |
| cjwatson | Do file a bug against LP about that, but please in a solution-neutral way (i.e. state the problem that getting from binary to source is harder than it should be, not your specific proposed solution) | 12:59 |
| cjwatson | If we were adding something that was potentially ambiguous between binary and source package names then it would need to be in a different bit of URL namespace | 12:59 |
| cjwatson | launchpad.net does a lot more varied things than tracker.debian.org does though, and it has to curate its URL namespace a good deal more as a result | 13:01 |
| cjwatson | Grabbing whole chunks of arbitrary namespace has historically turned out to be a mistake | 13:01 |
| cjwatson | e.g. there's some awkwardness in git URLs because bzr URLs claimed too much of the namespace and that turned out to be a problem n years later | 13:02 |
| cjwatson | juliank: Also maybe somebody could consider setting up a tracker instance for Ubuntu? It seems as though it'd be pretty useful, and it wouldn't have to have the same URL namespacing concerns that LP has | 13:08 |
| cjwatson | tracker.ubuntu.com would be a nice thing to have | 13:09 |
| juliank | maybe | 13:09 |
| juliank | probably needs a lot of work to get something useful | 13:09 |
| cjwatson | https://qa.pages.debian.net/distro-tracker/admin/vendor.html looks like it has at least been considered | 13:10 |
| cjwatson | And I see that https://pkg.kali.org/ exists which looks like the same codebase | 13:10 |
| === alan_g|lunch is now known as alan_g | ||
| juliank | ack | 13:10 |
| === ricab|lunch is now known as ricab | ||
| blackflow | sladen: so the summary of everything is... which package/project should I file a bug against? I know my way around LP and how to file without ubunt-bug | 13:21 |
| sladen | blackflow: Plese a bug against "Ubuntu" (eg. the "I don't know" option). Once the bug report is filed, and we have the bug number, it can be repointed | 13:22 |
| blackflow | k, thanks | 13:23 |
| === waveform_ is now known as waveform | ||
| blackflow | sladen: is bug #1830379 acceptable? | 13:48 |
| ubottu | bug 1830379 in Ubuntu "It is not clear how to install sources for the running kernel" [Undecided,New] https://launchpad.net/bugs/1830379 | 13:48 |
| sladen | blackflow: thank you! | 13:53 |
| blackflow | please let me know if you want me to word it differently. | 13:53 |
| sladen | blackflow: wording appears to be fairly neutral and factual. Thank you | 13:54 |
| coreycb | seb128: is there any chance we can push my software-properties change through first since the other has regressions. | 14:04 |
| seb128 | coreycb, you mean? | 14:04 |
| seb128 | coreycb, the other is in bionic-updates, rolling got stopped because it has new e.u.c reports | 14:05 |
| seb128 | I don't think so no | 14:05 |
| coreycb | seb128: ah so the regressions are in -updates | 14:05 |
| seb128 | yes | 14:05 |
| seb128 | we could stack your changes with the other fixes | 14:05 |
| seb128 | but I think we better fastrack the regressions fixes | 14:05 |
| rbasak | blackflow: that bug report looks fine, thanks. I'm not sure you can expect anyone to work on it, but at least it's a place for discussion. | 14:05 |
| coreycb | seb128: either option is ok i guess. happy to help stack if you want to go that route. | 14:06 |
| seb128 | coreycb, I'm doing a SRU, will probably use 8.1 then but I'm unsure what to do with the vcs | 14:06 |
| seb128 | there are enough dot, I'm going to do another .9 | 14:07 |
| seb128 | then we rebase yours as .10 | 14:07 |
| coreycb | seb128: ok | 14:08 |
| seb128 | I'm pondering going back to .8 in the vcs, doing my changes and pushing --force | 14:08 |
| coreycb | seb128: i don't care either way. i would prefer to stack mine in if possible since it's tiny and blocking the cloud archive. | 14:08 |
| seb128 | bdmurray, tjaalton, other SRU team mamber around? | 14:09 |
| seb128 | I want to do a software-properties/bionic upload to fix some regressions with the previous SRU (which is bionic-updates) | 14:10 |
| seb128 | is that fine if that upload includes that change as well? http://launchpadlibrarian.net/423881822/software-properties_0.96.24.32.8_0.96.24.32.9.diff.gz | 14:10 |
| blackflow | rbasak: agreed. | 14:21 |
| seb128 | bdmurray, tjaalton, could you review https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=software-properties ? it fixes some regressions from the SRU that moved to -updates earlier this week and a fix the cloud team is waiting on, would be good to have it in proposed today so we don't delay too much the regression fixes (like we can maybe talk about moving to -updates after the weekend) | 15:15 |
| seb128 | coreycb, ^ | 15:15 |
| seb128 | coreycb, I pushed -f to the bionic branch, you might want to refetch that | 15:15 |
| bdmurray | seb128: I got it | 15:17 |
| coreycb | seb128: thanks! | 15:29 |
| === Wryhder is now known as Lucas_Gray | ||
| seb128 | bdmurray, thx | 17:48 |
| raghu_ | hi | 19:11 |
| raghu_ | i'm new to open source,interested in contributing to ubuntu can someone help me out with links for getting started page, documentation page, beginner friendly bugs | 19:13 |
| sladen | hello raghu_: best place is to "scratch an itch". ie. is there a piece of software, an application, or a menu that you are already using---but perhaps a translation is not quite right, or there is a small bug | 19:19 |
| sladen | raghu_: it much easier to start, and drill down with something you already know + care about; then to just generically ask | 19:19 |
| ahasenack | dannf: hey, is updating freeipmi on your radar? If not, I was about to start | 19:26 |
| dannf | ahasenack: go for it :) | 19:26 |
| ahasenack | yay | 19:26 |
| ahasenack | we missed updating it for 19.04 | 19:26 |
| ahasenack | ok, updated the mom page | 19:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!