[00:18] The error you're seeing is because that PPA hasn't had anything published to it, which is a direct result of the rejection you were getting due to "unstable" in debian/changelog, which I thought I already told you as clearly as I could how to fix [00:19] Launchpad will produce a signed InRelease file by itself once it actually has something to publish to that PPA [01:41] cjwatson do you know of a good ppa url from any one person repo i can add to my software center to see the difference between what is displayed for it vs the main repos that have appstream /and other supported formats for icons/screenshots [01:42] just kind of want to see how it displays for the main repo because i am never going to figure out how i modify the changelog exactly your explaining it fine i just dont know how to edit it properly cjwatson [01:42] all the ppa i find are linked to gnome and other major project and thus display screenshots/icons ...etc [01:43] so i just like to see a ppa would likely display like [01:44] the only ppa i know of are ppa from major software so ... [01:46] even when i try some of this random ppa i find like [01:46] E:The repository 'http://ppa.launchpad.net/gwibber-daily/ppa/ubuntu bionic Release' does not have a Release file. [01:46] i get an error in refreshing /using it in software center. [01:47] So it complete dog shit the way launchpad makes it so difficult to upload/host software on there site [01:47] in my opinion currently that is [01:52] ya another random ppa i add to my software center and bam [01:52] :The repository 'http://ppa.launchpad.net/ubuntu-wine/ppa/ubuntu bionic Release' does not have a Release file. [01:52] so where are all these ppa that actually work [01:54] seriously ppa should be easy for people to create and use with out the security issue. [01:54] Heck people can choose to add the ppa or not so there never affected with anything but the default main repos if they choose to [01:55] but why the heck is ppa just so hard to create and seems to be so hard for people to maintain as well based on all the error of adding random ppa [01:56] My next question is if one developed finished software is there away to just zip it up and say here guys just deal with it put it in your main repos [01:57] I am done with the bullshit you take care of the monkey shit package repo / maintaining it aspect [01:57] that how i kind of feel [01:58] you think they make it easy to have regular ppa creation/maintaining for anybody to do ... more easily setup [01:58] wtf [02:01] another one :The repository 'http://ppa.launchpad.net/thedsweb/easyphoto/ubuntu bionic Release' does not have a Release file. [02:01] dog shit failed [02:03] even if you do a search for ppa [02:03] https://launchpad.net/ubuntu/+ppas?name_filter=photo [02:04] you get a shit ton of them that error out in trying to add them to the software center or apt-get program so much dog shit. [02:04] Amazing how many people can overcomplicated deploying software [02:06] Amazing i actually found a few ppa that actually worked === pieq_ is now known as pieq === cpaelzer_ is now known as cpaelzer [07:43] mm well tell us how you really feel [07:44] LocutusOfBorg: you must have assimilated lots of launchpad wisdom [07:45] a ppa i am working on has a few packages for disco 1904 and im trying to upload a focal package, it's just rebranded base-files. do i need to do something to the ppa to accept focal packages or is it with my packaging, i.e changes file and when i dput to the ppa my sources.changes [08:09] :) [08:31] LocutusOfBorg: if you happen to know, did you see my question [08:31] btw my nick may have been a certain LT Commander that served under your command in a p;revious life [08:56] I don't get the question [08:56] ah sorry [08:56] you want to upload stuff for focal, you can do it [08:56] for disco you can't anymore [08:56] i have a ppa, ppa"vinux/ppa [08:56] dput ppa:vinux/ppa-ppa file_source.changes [08:56] i am wanting to upload packages to it for focal, can i do that just with dput if i build the package for focal [08:57] or should i create a new ppa [08:57] Fudge: I answered your question yesterday [08:57] RikMills: oh sorry i didnt get a hilight [08:57] "[12:28] Fudge: if the 1st changelog line has focal instead of disco when you build the source to upload, launchpad will build it for focal in the ppa" [08:57] that's what i thought [08:58] but i was getting an error cant upload for this version or some rubbish [08:58] Fudge, if the same version already appeared in the archive, you can't "reupload" [08:58] so just mangle the version with some "ppa1" suffix [08:59] yes, could be version issue [08:59] not distro target [08:59] shouldnt be that, this is new version... [09:00] might help to have the error message verbatim [09:02] Fudge, what is the version? [09:02] sorry ill try to grab it [09:02] it's a bit tricky for me using gnome terminal to capture output using gnome-orca,, iill try using typescript [09:02] you have to avoid usage of "all previous used versions" [09:02] https://launchpad.net/ubuntu/+source/base-files/+publishinghistory [09:02] it might have appeared for some time and not on stable release [09:04] ok for some reason i didnt get a source.changes only got one for my arch [09:04] but ehre is the paste [09:04] https://paste.ubuntu.com/p/72ZypfmyWD/ [09:13] some reason> you forgot the -S option [09:13] dput ... *_amd64.changes will be rejected [09:14] you need to use the -S option to debuild when building the source package [09:17] (had enough of all the abuse in scrollback) [09:19] yay that guy was a tool [09:20] when I use just debuild -S as it shoudl work for me I get a builddep error https://paste.ubuntu.com/p/FwkysH7cFd/ [09:21] this always used to work for me and im trying to get back to maintaining this distro with an easy package lol, thank you cjwatson [09:21] this is the one themuso used to do the tech work for us on, the vision impaired distro [09:22] Fudge: in general the dpkg toolchain assumes that build-deps also need to be satisfied when running the clean target, and you don't have dh-systemd installed. You could install it; or in this case it's unlikely it's actually needed, so override it with debuild -S -d [09:23] wow now it works [09:24] thank you :D [09:26] i tried to swap to sbuild but know pbuilder-dist better [09:27] and there it goes it uploads :D === ddstreet_away is now known as ddstreet === hggdh_ is now known as hggdh === ijohnson is now known as ijohnson|lunch [19:51] How do I create a git repository on launchpad? [19:54] Hi, realtime-neil. Please, visit your profile's "git code" page at http://code.launchpad.net/~/+git and follow the instructions at the top of the page on how to push to a new git repository. [19:54] Alternatively, you can create a new project at https://launchpad.net/projects/+new, and configure code hosting details there. [19:55] pappacena: thanks === ijohnson|lunch is now known as ijohnson [20:58] i think i know the answer to this, but anyway: do all the builders in launchpad have the same amount of RAM allocated (across architectures)? [21:34] Anyone else running into Launchpad errors like this? My key has always been working and isn't expired. [21:34] File /srv/launchpad.net/ppa-queue/incoming/upload-ftp-20201207-211750-026396/~benjaoming/lcrs/pydhcplib_0.6.2-3ubuntu1_source.changes is signed with an expired key [21:34] I re-submitted my key to keyserver.ubuntu.com (same exact key) and it now works. [22:29] mwhudson: Currently 8G across the board, yes (er, possibly with the exception of riscv64, I forget) [22:30] cjwatson: and same number of cores on each arch? [22:30] the moral equivalent of "make -j" is ooming for rustc on arm64 but not other arches [22:30] mwhudson: IIRC 4 cores everywhere. Build procenv in an appropriately-configured PPA and find out :) [22:30] ha [22:31] The pool for each architecture is homogeneous [22:31] yes 4 [22:31] hmm [22:32] Moral equivalent of make -j (forkbomb) rather than make -j$(num-cores)? [22:32] i guess something arm64-specific has gotten worse then [22:32] oh [22:32] make -k $(num-cores) yes [22:32] -j! [22:33] rustbuild -j1 is working it seems but has been going for 24 hours now: https://launchpad.net/~mwhudson/+archive/ubuntu/rust-1.47/+build/20372061 [23:31] can anyone tell me what I did wrong to get this failed upload? https://launchpad.net/~realtime-robotics/+archive/ubuntu/test0006/+build/20379060 [23:36] realtime-neil: I see the version 4.16.18-rt12-1~ubuntu18.04.1 in two places but 4.16.18-rt12-1 in a third. Grep through your source package for each and work out why they're out of sync - kernel packaging does some weird stuff that's unlike most other packages and I'm not wholly familiar with it [23:41] cjwatson: it's git-build-recipe doing that --- it's appending "~ubuntu18.04.1" to the version string. How do I stop it from doing that? [23:42] You can't (well, unless you're running it locally, in which case you can remove the --append-version argument) [23:43] git-build-recipe isn't really intended for packaging as complex as the kernel packaging. It may be that the kernel packaging requires work to play nicely with it. [23:44] But it should just be a matter of tracking down what else is hardcoding the version number in addition to debian/changelog. [23:44] What do people usually do in this situation? Is this me writing a bad recipe or is it me writing a bad debian/changelog? [23:45] I think it's a quirk of kernel packaging, perhaps the way the debian/ directory is symlinked or copied or something? [23:45] I don't have enough network here to download the source package and have a look [23:46] it does this weird dance where it implements the `clean` target by moving the debian/ directory out of the way and then back during the build [23:47] I could try dput, but I'm guessing that it would be similarly wrong [23:48] dput would at least give you the opportunity to make the source package actually consistent before uploading it. [23:49] Or you could work out how to remove that weird dance for the purposes of the recipe. [23:51] that's some decent advice, thanks for your time [23:52] NP, sorry I don't know kernel packaging better (well actually I'm not really keen to go and import that into my skull, but you know what I mean ...). #ubuntu-kernel might be able to give more specialist advice if needed, although they probably won't know much about git-build-recipe. [23:53] But the only really interesting thing git-build-recipe is doing here is prepending an entry to debian/changelog. [23:53] that's probably exactly what's getting lost during the build [23:54] I do have to wonder whether that complex and unusual stuff in the kernel packaging is a relic of some former time that could be dispensed with. [23:54] As in across the board, rather than just by you. [23:54] But I bet it has accreted some associated tooling or something ... [23:55] the kernel team has seen fit to fix that ... their packaging, their debian/rules file in particular, is _really_ big. [23:55] I wouldn't be shocked if no one person understands the whole thing all the way through [23:56] I don't mean debian/rules being big - that's not unusual for a complex package. I mean the split between debian/ and debian.master/. [23:56] yeah, I couldn't grok that [23:57] Which is *very* odd and breaks stuff like this. [23:58] It's clearly part of some export operation that scrapes things from one branch to another, but I first saw it two days ago, and it's all alien to me. [23:59] It's possible that launchpad-buildd could fix this by passing -nc to dpkg-buildpackage to avoid the clean target, but it's very hard to tell whether that would break something else (without e.g. scraping all recipes on Launchpad and building them all either way round, which is a bit much for me just at the moment)