[00:08] can anyone tell me how I get backportpage check universe? [00:09] backportpackage* [09:21] doko, it would be nice if you documented a bit more why you do hacks/workaround, like why you disabled gdc in meson, is that pending a gcc fix or...? [09:35] seb128: why are you interested in the dropped test dependencies? [09:38] doko, because I'm likely going to merge/sync that package on Debian next time and now I've no clue if that delta is meant to stay, if it's Ubuntu specific and why it's there [09:38] should the same change be applied in Debian? [09:41] I file separate bug reports for debian. that package is a hell ... [09:43] thx [09:45] didrocks: do you have a sec to answer a ubiquity question? [09:45] acheronuk: sure [09:47] didrocks: I was following what jbicha did to do his changes, and on running debconf-updatepo is makes changes to debian/po and debian/real-po. Jeremey only committed the debian/real-po changes. is that correct? [09:48] acheronuk: yes! Did you have to change strings though? If you reused the strings than the ones we have in debian/templates*, it should be a no-op [09:49] didrocks: yes, I did make some new strings to better explain the software selection for KDE [09:50] acheronuk: ok, so, just ensure you added tem correctly to debian/templates* (not extracted from .ui file it seems), then, run debconf-updatepo as you did, and only commit debian/real-po [09:50] didrocks: that is precisely what I have done :) [09:51] excellent \o/ :) [09:52] didrocks: I'll double check it all for a bit, then commit to a branch to merge later. I assume I use Jeremy's branch with my changes on top, as the changes make no sense without his work [09:53] fundies: backportpackage doesn't care whether something is in universe or not; you don't need to do anything to get it to check universe [09:54] fundies: (I suspect there may be a category error in your question, so if you still have problems please give more details ...) [09:56] didrocks: oh. po is a symlink to real-po! duh.... [09:56] * acheronuk feels sheepish [09:56] Right, that was a hack so that LP Translations would import things [09:56] I forget the exact details [10:01] cjwatson, I gave up but basically libgrpc-dev isn't in trusty I try to back port in a trusty vm using backportpackage and it couldnt find it in xenial [10:02] under the lists of repos it looked where security and few others but uinverse wasn't listed [10:02] and the package is in universe [10:02] were* [10:03] fundies: backportpackage works by source package, not by binary package [10:03] fundies: so the name you should give to backportpackage is grpc [10:04] grpc is just a meta package isnt it? [10:04] i tried libgrpc0 as well [10:04] grpc is not a metapackage, but even if it were that would be irrelevant. [10:05] It's the name of the source package that builds libgrpc0 and libgrpc-dev. [10:05] well i ran backportpackage on it and it worked but it didnt add the children to my ppa [10:06] "children"? [10:06] ie libgrpc0 and libgrpc-dev [10:06] Binary packages have to be built before they're published ... [10:07] I thought backport package would rebuild them [10:07] guess the tool does less than I thought [10:07] If you've told backportpackage to upload to a PPA, then Launchpad does the building [10:07] What PPA is this? I can look [10:09] https://launchpad.net/~cheeseboy16/+archive/ubuntu/ppa [10:09] fundies: You haven't registered a GPG key with Launchpad, so Launchpad threw away your upload [10:09] fundies: You need to do https://help.launchpad.net/YourAccount/ImportingYourPGPKey first [10:09] fundies: And then do the backportpackage thing again [10:09] cjwatson, is ok I've went another route [10:10] #ubuntu people told me I couldnt get help with backportpackage at all [10:10] #ubuntu people are often wrong [10:11] There are certainly ways in which backportpackage might fail when you'd be on your own, just not this one :-) [10:11] I tried to tell them they were and they tried to report me to ops [10:11] Well, there are ways of saying things [10:12] I don't think I was too harsh [10:13] I deleted my ubuntu image [10:13] I think the conversation just got kinda confused [10:14] they where trying to help me despite knowing as litte (probably less) as I did [10:15] It may yet be that grpc won't backport cleanly to trusty for one reason or another; they're certainly correct that you're on your own if that is the case [10:16] It is true that there is absolutely no guarantee whatsoever that a source package from a later release will be backportable to an earlier one. It's often true, but by no means always [10:16] cjwatson, my question was purely why calling backportpackage wasn't finding the -dev [10:16] However, in this case the problem was just in even getting started [10:16] Right, and that's because of a category error, libgrpc-dev is a binary package name and backportpackage takes source package names [10:17] they said something like ubuntu doesnt support backporting that werent in trusy packages [10:17] and when I tried to tell them that can't be the case they got mad [10:17] Which is true [10:18] Lots of things happen to work a lot of the time that aren't supported as such [10:18] I just built my own deb real quick [10:19] and tossed vm [10:20] Things switching to dh 11 even make backporting to xenial and artful more than no-change backports, unless one first backports dh 11. :P [10:20] ...Then pkgbinarymangler too needs a rebuild, for PPAs. [10:21] dh? [10:21] debhelper [10:25] it's pretty annoying travis-ci only offers acient ubuntu and I gotta deal with this all the time [10:26] but its free so I can't complain too much [10:34] cyphermox: is it known that network-manager (the UI) calls home to some gnome.org domain (forgot the name of the subdomain) when a wifi network requests a user id and password? [10:34] a la captive.apple.com [10:54] tsimonq2, LocutusOfBorg, is any of you looking at the gsequencer & why3 autopkgtest issues blocking the recent gtk+2.0 update? [10:57] seb128, they are both regressed in release, but I can have a look shortly [10:58] LocutusOfBorg, well if they are then maybe the right thing is to ask for those to be ignored? [10:58] LocutusOfBorg, thx [10:59] yes, I want to ask for glib/gtk2 and gtk3, as soon as retries against release are finished and I looked at them [11:03] LocutusOfBorg, great, thx [11:38] doko, I guess you saw that your meson update failed to build on "Unknown compiler "javac"" errors? [11:43] seb128: yes, uncovered by removing the gdc dependency [11:44] I don't see how it would fail. the meson tests are independent of the java version [11:44] all these test dependencies look so wrong ... [12:28] cjwatson, you still about? [12:28] fundies: What's up? [12:29] I decided to try again [12:29] I'm getting Unable to identify 'Greg Williamson': in launchpad [12:29] Hi there, current base-files in bionic seems to produce the empty package when rebuilt.. sitter mentioned to me that this issue seems to be fixed in debian version 10.1 : http://metadata.ftp-master.debian.org/changelogs/main/b/base-files/base-files_10.1_changelog [12:33] oh my email got cutoff [12:33] idk how [12:33] got it now I think [12:35] right, @.com certainly isn't going to work :) [12:36] cjwatson, funny it can send an email to my correct email telling it I set the email incorrect [12:37] cjwatson, https://launchpadlibrarian.net/362282244/buildlog_ubuntu-trusty-amd64.grpc_1.3.2-1ubuntu2~ubuntu14.04.1~ppa1_BUILDING.txt.gz [12:37] anything I can do about that? [12:38] It can email you because it can identify your account from the GPG key [12:38] I have no idea, now you're in the "you're on your own" territory [12:38] Terra-incognita ? [12:39] You will apparently have to modify the package in some way to get it to build on trusty, but I don't know the details here. If you're lucky it's as simple as playing with compiler/linker flags in debian/rules [12:40] I'm able to build the source on trusty [12:41] locally [12:41] Perhaps you're not using the xenial packaging though [12:41] I wasnt [12:41] I used straight from grpc [12:41] So work out the differences between your successful build and the failed build [12:42] how do I see ubuntu's rules? [12:42] debian/rules in the source package [12:42] that's the entry point [12:44] If you still have the .dsc that backportpackage constructed, you can use dpkg-source -x on that to unpack the source package [12:45] If you don't, you can download it from your PPA - go to the web UI for the PPA, "View package details", expand the source in question, copy the URL to the .dsc file, and use dget on that URL to fetch and extract it (dget is in the devscripts package) [12:48] make shared_c [12:49] thats not a real cmd [12:49] real target I mean [12:49] what kinda trickery is it doing... [12:50] No mention of shared_c in your build log [12:51] There's "make shared prefix=/usr"; that's simply part of the upstream build system as far as I can see [12:53] Though "shared_c" certainly is a real target, right there in Makefile [12:54] oh the xz doesnt give me the src [12:54] sigh [12:54] I told you how to unpack it [12:55] dpkg-source -x on the .dsc file [12:55] sorry i missed that [12:55] (dget wraps the download of multiple times and the unpack in a single step) [12:55] *multiple files [12:55] fundies: A first thing to try IMO, and this is just an educated guess, would be to comment out "export DEB_BUILD_MAINT_OPTIONS = hardening=+all" from debian/rules; I suspect that the details of the hardening rules aren't quite right for trusty and this package together, or something [12:56] I could be wrong [12:58] how do I tell it to build this locally the same way the ppa server tried to? [12:59] https://wiki.ubuntu.com/SimpleSbuild [13:00] ubuntu doesn't make any of this easy... [13:01] or, if you already have an environment with all the necessary build-dependencies installed, then you can run "dpkg-buildpackage -b -uc -us" - that's a much less good emulation of what Launchpad does to build the package, and it's less "safe", but it involves much less setup [13:04] (we have git-based work in progress to make this kind of thing a lot easier, but it's not quite there yet) [13:04] bleh ran outta space [13:05] guess I have to install a vm [13:05] cjwatson, I'm going to come back to this but while youre here. say I fix rules file how would I submit it? [13:10] fundies: since you already have a PPA, the best thing would be to go through https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage [13:10] (and the next steps it links to) [13:11] ok thanks for the help. I'm off to bed. I'll tinker more when I get up [13:12] np [14:14] slangasek: does https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1750465 need fixing in xenial too? [14:14] Launchpad bug 1750465 in ubuntu-mate-artwork (Ubuntu Artful) "upgrade attempting to process triggers out of order (package plymouth-theme-ubuntu-text 0.9.2-3ubuntu17 failed to install/upgrade: dependency problems - leaving triggers unprocessed)" [Undecided,Confirmed] [14:14] (because I see a similar failure at least when trying a desktop do-release-upgrade in a chroot) [15:19] Laney: LP: #1750465> ah, because of upgrades from xenial to bionic? hmm, it's possible but it doesn't seem to have been reported on that upgrade path yet so xenial's package manager may not be affected [15:19] Launchpad bug 1750465 in ubuntu-mate-artwork (Ubuntu Artful) "upgrade attempting to process triggers out of order (package plymouth-theme-ubuntu-text 0.9.2-3ubuntu17 failed to install/upgrade: dependency problems - leaving triggers unprocessed)" [Undecided,Confirmed] https://launchpad.net/bugs/1750465 [15:20] slangasek: ah, I've closed the chroot already I'm afraid, but https://paste.ubuntu.com/p/dTsCdqPMpY/ [15:24] Hi, I just hit https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889869, is a pull planned or should I file a bug report in ubuntu with sru etc? [15:24] Debian bug 889869 in bash "bash: crash in qemu-user: bash: xmalloc: ... cannot allocate XX bytes (0 bytes allocated)" [Important,Fixed] [15:24] I.e. bash in 18.04 doesn't run in qemu-user chroots/containers [15:31] Laney: ok then yes, I guess we ought to fix it in xenial, thanks :) [15:32] *ffe, not sru... [15:32] alkisg: bugfixes don't need ffe [15:33] alkisg: as it's not a feature :) [15:33] nacc: how can I see the bionic-proposed list, i.e. if it's already in some pull queue? [15:33] alkisg: as to whether the bugfix is going to get cherry-picked, cpaelzer is out this week [15:33] alkisg: rmadison? [15:33] alkisg: or http://pad.lv/u/qemu and see the publishing info [15:33] alkisg: nothing in bionic-proposed currently [15:34] smb: --^ would you happen to know with cpaelzer out? [15:34] nacc: the bug is in bash, not qemu... looking there... [15:36] nacc, I would not know of anything pending but yeah, I'd say if there was something it would show up in rmadison [15:38] alkisg: oh sorry, wrong person then, but same idea :) [15:39] alkisg: it's LP: #1751011 and the Debian bash maintainer claims that qemu needs to be fixed for bionic not bash :( [15:39] Launchpad bug 1751011 in bash (Ubuntu) "bash crashes in qemu-user environments (bionic)" [High,Triaged] https://launchpad.net/bugs/1751011 [15:40] heh [15:40] round and round we go! [15:41] I did add the bug to https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes and hopefully it will be fixed by someone before 18.04 [15:59] Thanks a lot guys, subscribing there... [16:18] coreycb: 0.1.17-0ubuntu1.1 ??? [16:18] in bionic? [16:19] doko: sorry is that bad? [16:20] doko: we do generally do that for n-1 releases [16:20] doko: i can update it if you want [16:23] coreycb: we usually don't do that for the development release [16:23] no need to update [16:24] doko: ok, noted [18:50] kees, mdeslaur, infinity, stgraber: TB in 10, kees as chair? [18:50] ack [18:51] also, either the agenda page or the calendar is a lie [18:51] woop no [18:51] my use of 'date' is a lie [21:24] hi [21:26] can someone help me with building a deb? [21:27] fundies: where are you stuck? [21:29] nacc, so the xenial / bionic package is 11million versions behind. so I grabbed the source release from github. I don't get how do I put the newer source into the other debs build config [21:30] fundies: what are you trying to package? [21:30] nacc, still grpc [21:31] fundies: i lack context ... sorry [21:32] fundies: did you try uupdate and uscan? [21:32] nacc, we talked yesterday :P [21:32] fundies: i remember you trying to use backportpackage, that was it [21:32] fundies: let's just say you weren't the only person i talked to in the last 24 hours? [21:33] nacc, I don't know what those commands are [21:33] fundies: uscan will look at debian/watch and see if there is a new upstream release to update to and download the orig tarball for it [21:33] fundies: uupdate will take that orig tarball and create a new source package directory based off of it, using the current source package as a template [21:34] I run this in the grc-version folder i have from deb-source -x? [21:34] fundies: yes [21:34] no outout [21:35] output* [21:35] ubuntu has grpc 0.11.1 but there is version 1.10 on github [21:35] fundies: uh, bioinic has 1.3.2 ? [21:36] *bionic [21:36] 1.10 is latest :/ [21:37] no bionic is 7 versions behind [21:37] fundies: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875747 [21:37] Debian bug 875747 in libgrpc-dev "libgrpc-dev: Please package latest upstream version" [Wishlist,Open] [21:38] fundies: well, it's in universe, meaning community maintained, and the debian version is at the same upstream level [21:40] fundies: oh i see, the source package doesn't have a debian/watch file :( [21:43] well guess I'll try 1.32 for now [21:55] bleh I need protobuf 3 and backportpackage can't build that either... [21:56] i really hate ubuntu [21:56] feel free to build your deps from source withotu packages if you wish [21:56] fundies: well, it seems like what you should hate is not ubuntu but something else, but hwatever [21:57] sarnold, that's too slow. [21:57] nacc, it's ubuntus tools that are failing me [21:58] fundies: what tools? [21:58] backportpackage [21:58] fundies: what failed with it? [21:58] fundies: it's not magic, it doesn't figure out what dependencies are also needed to be backported [21:59] nacc, it's not even a dependency error [22:00] fundies: then you need to be more verbose than "backportpackage" [22:04] fundies: is there a reason you can't use Ubuntu 17.10 if you need new software? [22:04] jbicha, this is for travis-ci [22:05] I wish they'd use newer ubuntu or arolling ditro [22:05] distro* [22:05] jbicha: I think the complaint is in part that even 18.04 is too far behind upstream for at least one package [22:05] thats one complaint [22:05] i have many :P [22:06] hehe [22:06] fundies: travis uses ancient Ubuntu :( [22:06] yep [22:07] it took a few months after 12.04 LTS was end of life for them to switch to 14.04 LTS [22:07] I wish they would offer arch as an option [22:08] ubuntu is fine for lts but you need to test bleeding edge too [22:09] could you switch from github to gitlab and have your own ci runners? [22:09] too poor [22:10] plus I'd rather not admin a server [22:12] if I add a dependency to my ppa and retrigger an older build on it will it use that dependency automatically? [22:12] If I need to upload a fix for package foo that has a version of e.g. 1.1.1-1fakesync1 then would 1.1.1-1ubuntu1 be appropriate (like in the case of build1) or would 1.1.1-1fakesync1ubuntu1 be appropriate? [22:23] fundies: i believe so, yes [22:23] tsimonq2: i'd expect ubuntu1 would be fine for versioning purposes, but you'd want to check if it's been copied forward, etc. [22:23] tsimonq2: although i'd also expect to see it be fakesync1ubuntu0.1 if you went that way [22:24] nacc: This is in devel. [22:24] tsimonq2: oh ok [22:25] nacc: So I'll go with ubuntu1 then. Thanks. [22:25] tsimonq2: i'd probably wait for at least one other coredev (or so) to respond, but i can't see an obvious issue with it [22:25] nacc: ack [22:34] Dependency wait on lcy01-amd64-020 [22:34] what? [22:36] fundies: Got a link? [22:36] https://launchpad.net/~cheeseboy16/+archive/ubuntu/ppa/+build/14503891 [22:37] Oh, "on lcy01-amd64-020" is irrelevant here. [22:37] Look further, you're missing a dependency on debhelper. [22:37] (Er, you get what I mean.) [22:38] Enabling Backports will probably help, although do that at your own risk. [22:38] Otherwise, the packaging needs to use the debhelper which corresponds to that release. [22:38] So, debhelper 9. [22:38] trusty doesn't have a debhelper 10 backport, so backports will make no useful difference in this case. [22:39] Oh. [22:39] Right. [22:40] sigh [22:45] I'd look for the change in Debian that bumped to debhelper 10 and undo it. [22:46] Failing that, just whack it back to 9 and see what the next thing is that goes wrong :) [22:47] im running low on patience [22:48] https://tracker.debian.org/media/packages/g/gflags/changelog-2.2.1-1 doesn't document any particular *reason* for the change, so just change 10 to 9 in debian/compat and (>= 10) to (>= 9) in debian/control [23:16] fundies: why don't you try using docker to use Ubuntu 17.10? https://docs.travis-ci.com/user/docker/ [23:17] jbicha, I run like 20 tests [23:17] fundies: or to use Arch or whatever [23:17] wuld take forever [23:18] would it really? it sounds like what you're doing now to try to hack 14.04 together is taking a while? :) [23:19] jbicha, this will take me a long time 1x doinf that would take a long time 20x everytime I commit [23:20] can't you run all 20 tests in the same OS image? [23:20] that would also be slow [23:20] travis is parellelized [23:20] ok, keep on doing what you're doing then :) [23:21] you asked for Travis to support newer OS releases and I believe this is Travis' official answer [23:23] jbicha, and it sucks. thats why everyone uses ppas [23:23] fundies: sounds like a problem for travis, though? [23:24] not really. [23:24] travis is the root of me needing ppa but I need help with the ppa not travis [23:24] fundies: and i think, you've been told everything one would need to use the ppa? [23:25] fundies: it's not going to be a 5-second fix [23:25] I;m not sure what youre asking [23:25] fundies: I'm asking if there's something you actually need from the channel right now? [23:26] maybe I should go back to my hacky solution [23:26] I built google everything and put in google-trash.deb [23:26] but when I install it its not installing the headers [23:26] idk why [23:27] fundies: are the headers packaged? [23:27] https://github.com/RemoveRusky/grpc-trusy/releases/download/1.10/google-trash.deb [23:27] yes [23:29] fundies: uh because you botched the packaging? [23:29] fundies: there's no top-level /include path [23:29] fundies: i'm guessing you forgot to have --prefix=/usr in your rules or something [23:29] https://github.com/RemoveRusky/grpc-trusy/blob/master/.travis.yml#L12 [23:29] thats the proccess I used [23:29] fundies: so it *maybe* created /include and put it all in there [23:30] "apt -get" [23:30] heh it still worked [23:30] oh, since there's an 'apt' command now .. I wonder what it does with a '-get' argument. heh. [23:31] fundies: well, i'm not particularly interested in debugging it further than what i told you :) [23:32] nacc, so I want /home/travis/google-trash/usr instead of /home/travis/google-trash ? [23:32] for the CMAKE_INSTALL_PREFIX, yes [23:32] fundies: no, probabl your cmake invocation is wrong [23:32] not for the other occurrences [23:32] fundies: so i guess it depeonds on where you want that string to appear [23:33] fundies: what cjwatson is saying more clearly :) [23:33] well, normally it's actually -DCMAKE_INSTALL_PREFIX=/usr and then make install DESTDIR=/path/to/temporary/location [23:33] the prefix should be the as-installed path [23:34] cjwatson: yeah that looks more normal to me [23:34] so in this case I'd do cmake -DCMAKE_INSTALL_PREFIX=/usr /home/travis/grpc && make && make install DESTDIR=/home/travis/google-trash [23:35] $ sudo apt -get install cmake curl [23:35] E: Command line option ‘g’ [from -get] is not known. [23:35] (in a trusty container) [23:36] thanks cjwatson :) [23:36] they were probably just installed already or something [23:53] tsimonq2: not amused about your mercurial sync. any reason to drop the patches? [23:58] doko: Indeed, now that I take another look at it, it probably wasn't the best idea. I'm sorry, I'll be more careful next time. You're an archive admin; you're welcome to remove it from -proposed, or I can readd the patches in another upload, whatever you'd like to do.