[00:39] <amosbird> hello, why do I get Error, was given host, but we don't know about it. when doing dput ppa:amosbird/ppa <source.changes>
[00:50] <amosbird> what's pdebuild?
[00:51] <sarnold>  pdebuild is a wrapper for Debian Developers, to allow running
[00:51] <sarnold>  pbuilder just like "debuild", as a normal user.
[00:51] <sarnold> from apt-cache show pbuilder
[00:59] <Unit193> So, you'd run `pdebuild` in the packaging dir rather than dpkg-buildpackage -sa -S -d -tc && sudo pbuilder build ../*.dsc
[01:10] <amosbird> ok, what's debuild?
[01:10] <amosbird> is it better than pdebuild?
[01:11] <sarnold> debuild does a build just "on your machine", with whatever packages you've got installed
[01:11] <sarnold> pdebuild uses pbuilder to give some reproducable build, similar to sbuild
[01:17] <amosbird> ok.
[01:18] <amosbird> So I have a bunch of local deb files. I'd like to quickly spin up a local repo serving those files for machines in the same LAN. what's the easiest way to achieve this?
[01:21] <sarnold> apt-utils apt-ftparchive works okay
[01:21] <sarnold> aptly if you want Something Better (I've not used this one myself, but it sure looks neat)
[01:22] <Unit193> mini-dinstall if you want something super cheap and easy. :>
[02:00] <infinity> dpkg-scanpackages is the easiest if you literally just have a directory with some debs.
[02:00] <infinity> Other stuff is massive overkill.
[02:04] <amosbird> infinity: hmm, dpkg-scanpackages can setup a repo for all machines in the same LAN?
[02:05] <infinity> amosbird: I mean, it can generate a Packages file. :P
[02:05] <amosbird> not sure what that means
[02:05] <amosbird> https://www.aptly.info/ does look nice
[02:05] <infinity> amosbird: The "repo for all machine in the LAN" is left to you to decide how to serve.  http (apache, etc), smb, nfs, whatever.
[02:06] <infinity> aptly is ridiculous overkill (and broken in many fun ways) if you really have "a bunch of local debs" rather than something much larger.
[02:06] <infinity> Of course, another cheap and easy way to go is build everything in a PPA, mirror the PPA locally, and serve that via apache.
[02:07] <amosbird> infinity: hmm, that means I need to serve apache
[02:07] <amosbird> is there a tool that can just do  ./serve <local_deb_dir> ?
[02:07] <amosbird> and I'm good to go
[02:08] <infinity> No.
[02:08] <infinity> Creating repositories and serving them are two distinct concepts.
[02:08] <infinity> Because it's just a flat directory structure, there's no point writing a tool so serve it, when any httpd will do.
[02:09] <amosbird> but it shouldn't forbid a easy use case
[02:09] <infinity> s/so serve/to serve/
[02:09] <amosbird> I don't understand
[02:09] <infinity> A repository of debs, at the simplest, is a single directory with debs and a Packages file.  More complex, a tree with pool, dists, etc.  Either way, it's just a directory structure.
[02:10] <infinity> Creating that locally and serving it are two different things.
[02:10] <infinity> Serving it via any simple httpd takes seconds to set up, so why would someone write a different one to do the same thing?
[02:10] <amosbird> infinity: ok. after using httpd to serve that directory, how can clients use that?
[02:10] <infinity> ...
[02:11] <amosbird> yeah, centos user here
[02:11] <infinity> And this handholding has gone way beyond the help that #ubuntu-devel doesn't provide.
[02:11] <amosbird> ok
[02:11] <infinity> You don't have to serve it from an Ubuntu system. :P
[02:11] <infinity> If you have CentOS servers with apache on them, you win.
[02:12] <amosbird> ...
[02:12] <infinity> (or, apt-get install apache2, put your debs and Packages files in /var/www or whatever the default dir is, and go to town)
[02:12] <amosbird> ok
[02:12] <amosbird> any one liner I can use to add that http server as an apt repo?
[02:13] <infinity> I'm not sure what you mean.
[02:13] <infinity> You mean on the client machines?
[02:13] <infinity> It'll depend on where you serve from relative to the root of the machine.
[02:13] <amosbird> "You mean on the client machines?"  yes
[02:14] <amosbird> suppose I put those debs and Packages files in /var/www
[02:14] <infinity> But adding something like "deb http://my.server.local/ ./" to sources.list on a client, assuming /var/www if where you put your debs, will do the trick.
[02:14] <infinity> After you dpkg-scanpackages . > Packages in said root.
[02:14] <amosbird> ah, I see what's going on now
[02:14] <amosbird> lemme try thta
[02:16] <amosbird> infinity: btw, my workflow has one additional jump
[02:17] <amosbird> so my dev box generates deb files, I'll push them into a box serve the repo, then clients pull the packages from that serving box.
[02:17] <mwhudson> rbalint, cpaelzer__: is the usd-importer stuck again?
[02:17] <amosbird> my question is, do I need to rerun dpkg-scanpackages after updating the old debs?
[02:18] <amosbird> or can I just rsync them over
[02:19] <infinity> dpkg-scanpackages generates the Packages file, so you need to re-scan any time you add new ones.
[02:20] <infinity> Also, that sources.list line should be "deb [trusted=yes] http://my.server.local/ ./" because it won't be signed (which is fine assuming it's a local network you trust)
[02:34] <amosbird> "so you need to re-scan any time you add new ones." If I don't add new ones, but replace old ones?
[02:52] <amosbird> can I use apt-add-repository command instead of deb command?
[02:56] <amosbird> oh...
[02:56] <amosbird> E: The repository 'http://10.138.0.2:33992 ./ Release' does not have a Release file.
[03:00] <infinity> Does apt really require Release files now?  That would be silly.
[03:00] <infinity> trusted=yes shouldn't need one.
[03:00] <infinity> Did you use that?
[03:01] <Unit193> Apt maintainer actually was talking about dropping support for Release(,.gpg) and requiring InRelease, last I knew.
[03:01] <amosbird> infinity: I do
[03:02] <amosbird> Ign:4 http://10.138.0.2:33992 ./ InRelease
[03:02] <amosbird> Err:5 http://10.138.0.2:33992 ./ Release
[03:02] <amosbird>   404  Not Found [IP: 10.138.0.2 33992]
[03:02] <amosbird> there is an InRelease request too
[03:03] <infinity> amosbird: What's your sources.list line?
[03:05] <amosbird> weird, it's  deb http://10.138.0.2:33992/ ./
[03:05] <amosbird> but I surely did sudo apt-add-repository 'deb [trusted=yes] http://10.138.0.2:33992/ ./'
[03:05] <infinity> apt-add-repository isn't really a useful tool for this.
[03:06] <infinity> You could as easily have said "echo 'deb [trusted=yes] http://10.138.0.2:33992/ ./' > /etc/apt/sources.list.d/my.list" for the same effect.
[03:06] <infinity> Without wondering what the tool was doing.
[03:06] <infinity> Oh, and as to your other question, "replacing" files in the repo *is* updating them. :P
[03:07] <infinity> Unless they're identical, your Packages file would be wrong (it contains sizes and hashes)
[03:07] <amosbird> ah, I see, so I need to update the Packages file too
[03:07] <infinity> But it's also generally poor form to replace a package with the same version.
[03:08] <amosbird> btw, how can I make sure the update process won't break any in-progress apt install?
[03:08] <amosbird> if any
[03:08] <infinity> apt locks.  You can't run it twice.
[03:08] <amosbird> so I first do apt locks, then pull in the updates, then apt unlocks?
[03:09] <infinity> No, I mean apt locks itself. :P
[03:09] <infinity> You can't run two at the same time.
[03:09] <amosbird> but the update process is just scp
[03:09] <infinity> Oh, you mean updating the repo.
[03:09] <amosbird> yes
[03:10] <amosbird> "apt-add-repository isn't really a useful tool for this."   what's  the right tool then?  echo seems ... not appropriate
[03:11] <infinity> So, if you're pushing new versions (instead of trying to overwrite versions, which is evil and scary and undefined), then you push new debs, dpkg-scanpackages > Packages.new && gzip -c Packages.new > Packages.gz && mv Packages.new Packages, then remove the old versions $later.
[03:11] <infinity> Why is echo inappropriate?
[03:11] <infinity> One doesn't need a fancy tool to put a line in a text file.
[03:11] <amosbird> infinity: ok
[03:11] <amosbird> so I need to relying the filesystems atomic mv
[03:11] <infinity> apt-add-repository was designed for the specific use-case of setting up hard-to-remember PPA URLs and fetching the signing keys for them.
[03:11] <amosbird> ah, ok
[03:12] <infinity> You know your URL, and you have no key.  So... meh?
[03:13] <infinity> Basically, the only way to break an in-progress update (if you update Packages atomically) is to remove the old debs while someone's still trying to download them.
[03:13] <infinity> And, really, that's not world-ending.  The client just needs to apt-get update to get the new Packages file, and carry on with life getting shiny new debs instead.
[03:14] <amosbird> btw
[03:15] <amosbird> after a new Packages file uploaded, do clients need to run apt update? Or is apt install <package> just enough?
[03:15] <infinity> Anyhow, if you have tons of packages you want to do this sort of thing with, something like mini-dinstall will help with building the repos and deleting old versions, etc.
[03:15] <infinity> It's just serious overkill if your repository is a few source packages and their binaries.
[03:15] <infinity> apt update fetches the new Packages file, yes.  That's literally its only function.
[03:16] <amosbird> infinity: so I have to do a apt update first
[03:16] <infinity> A bit confusing that yum conflated update and upgrade into one command.  That hurt my brain the first time I used it.
[03:16] <amosbird> .......
[03:16] <infinity> And I assume the same brain hurtiness happens the other direction.
[03:19] <amosbird> heh, dpkg-scanpackages doesn't allow selecting debs
[03:20] <amosbird> but all debs in the directory
[03:21] <infinity> Right.
[03:21] <infinity> And apt-ftparchive in its simple mode does the same.
[03:21] <infinity> You can use apt-ftparchive in the complex and super confusing mode we do for the primary archive, which takes config files and lets you feed in package lists, but again, massive overkill unless you're managing a huge repository.
[03:22] <amosbird> ok
[03:22] <infinity> But only you know your limit for simple tooling versus complex infrastructure.
[03:23] <infinity> I'd recommend mini-dinstall when things get too complex.
[03:23] <infinity> Or, if none of your packages are secret/proprietary, it really is dirt simple to just let LP PPAs handle it, and then mirror the PPA structure locally so your clients don't all have to hit a remote.
[03:37] <amosbird> https://github.com/yandex/ClickHouse/blob/master/debian
[03:38] <amosbird> so the /debian folder looks like this. How can I make debuild exclude clickhouse-common-static-dbg and clickhouse-test?
[03:49] <amosbird> infinity: hi, how can I apt update this repo only ?   deb [trusted=yes] http://10.138.0.2:33992/ ./
=== cpaelzer__ is now known as cpaelzer
[06:44] <cpaelzer> mwhudson: yes I was missing imports of tonight
[06:44] <cpaelzer> I'll check if it has died
[06:45] <cpaelzer> and you probably meant rbasak instead of rbalint :-)
[06:47] <cpaelzer> hmm, it wasn't aborted - but maybe stuck
[06:47] <cpaelzer> Examining publishes in ubuntu since 2019-09-22 05:08:13 is quite old
[06:49] <cpaelzer> yeah something made it stuck on a futex and a socket it seems
[06:50] <cpaelzer> mwhudson: thanks for the ping, I restarted the importer ...
[06:55] <LocutusOfBorg> Unit193, hello, what happened to filezilla upload?
[06:55] <LocutusOfBorg> filezilla is now rc buggy
[06:58] <LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941193
[06:58] <ubottu> Debian bug 941193 in libfilezilla0 "filezilla: Crash on startup: undefined symbol: _ZTIN2fz6threadE" [Grave,Open]
[06:58] <LocutusOfBorg> also libfilezilla
[06:58] <LocutusOfBorg> Adri2000, ^^
[07:35] <seb128> vorlon, hey, do you plan to send debdiff back to Debian for those pylint changes?
[08:04] <cpaelzer> mwhudson: FYI the git importer has fully catched up now
[08:35] <Adri2000> LocutusOfBorg: hello, yes just saw that :(
[08:49] <Unit193> LocutusOfBorg: Hmm?
[08:52] <LocutusOfBorg> Unit193, you sponsored it, right?
[08:52] <LocutusOfBorg> :)
[08:55] <Unit193> I didn't do a filezilla upload though.
[08:55] <Adri2000> LocutusOfBorg: I'm asking upstream if they plan to fix the bug in libfilezilla itself... also I can't get filezilla to build with wxwidgets gtk3 (./configure fails, saying gtk3 is missing), so I'm asking upstream about that as well
[08:56] <Adri2000> I wanted to find a solution for the wxwidgets gtk3 build before uploading filezilla, that's why
[08:56] <Unit193> What error exactly, if I may?
[08:58] <Adri2000> checking for gtk+-3.0... no
[08:58] <Adri2000> configure: error: gtk+-3.0 was not found, even though the used version of wxWidgets depends on it. Are you missing the gtk+3.0 development files?
[08:58] <Adri2000> I just changed the build-dep from libwxgtk3.0-dev to libwxgtk3.0-gtk3-dev, as suggested in the bug report
[08:59] <Adri2000> so either I'm missing something, or the ./configure is buggy
[08:59] <Unit193> https://launchpadlibrarian.net/441494360/filezilla_3.39.0-2_3.39.0-2aegir1~19.04.diff.gz that's what I did.
[09:00] <Adri2000> oops, libgtk2.0, that was obvious :s sorry I didn't even see you did it in ubuntu!
[09:01] <Unit193> Not Ubuntu, a silly PPA. :P
[09:01] <Adri2000> ah :)
[09:01] <Adri2000> ok let me fix that and I'll ping you again to upload in debian... :)
[09:06] <Unit193> LocutusOfBorg: Symbols would really help avoid that bug.
[09:23] <cpaelzer> rafaeldtinoco: would the cluser-solutions need all to be updated to know about this new features?
[09:23] <cpaelzer> or do you from your testing think that the admin could to that
[09:23] <cpaelzer> what I'm wondering is if e.g. some cluster solutions set up those virtual ips/devices themselve dynamically
[09:24] <cpaelzer> then an admin can't do that, which means all those cluster pkgs would need to know how/where to drop netplan config
[09:24] <cpaelzer> hence I'm asking about that in regard to your HA testing so far
[09:24] <cpaelzer> could this work with "just" systemd/netplan changes or will all those packages need updates as well?
[09:25] <rafaeldtinoco> cpaelzer: my thought is that .. if clusters are putting virtual aliases to interfaces, those should contain the "keep configuration" systemd-networkd flag (discussed in LP: #1815101)
[09:25] <ubottu> Launchpad bug 1815101 in systemd (Ubuntu Eoan) "[master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)" [Medium,In progress] https://launchpad.net/bugs/1815101
[09:26] <rafaeldtinoco> cpaelzer: so, usually HA clusters will have private interconnects and public nics, you have to set that flag in those receiving VIPs.
[09:26] <rafaeldtinoco> for keepalived, haproxy, ipvs, the same thing
[09:27] <cpaelzer> backporting to 237 and modifying all those packages might be complex, but at least going forward that solution LGTM
[09:28] <rafaeldtinoco> network:
[09:28] <rafaeldtinoco>     version: 2
[09:28] <rafaeldtinoco>     renderer: networkd
[09:28] <rafaeldtinoco>     ethernets:
[09:28] <rafaeldtinoco>         eth1:
[09:28] <rafaeldtinoco>             dhcp4: no
[09:28] <rafaeldtinoco>             dhcp6: no
[09:28] <rafaeldtinoco>             addresses: [10.0.1.2/24]
[09:28] <rafaeldtinoco>             keepaliases: true
[09:28] <rafaeldtinoco> cpaelzer: netplan could be configured with something like this ^
[09:28] <rafaeldtinoco> and we would explain what keepaliases mean (or any other word)
[09:28] <cpaelzer> once you did some doability checks and experiments on it be sure to pull in cyphermox for his opinion on the netplan portion of it
[09:29] <rafaeldtinoco> +1
[09:29] <rafaeldtinoco> thx for reviewing this, i'd appreciate constant review in next comments to come
[09:29] <rafaeldtinoco> =)
[09:29] <cpaelzer> rafaeldtinoco: the value is more fine grained
[09:29] <cpaelzer> rafaeldtinoco: so if exposing in netplan expose the full set of values maybe
[09:29] <rafaeldtinoco> ok
[09:29] <rafaeldtinoco> makes sense
[09:29] <cpaelzer> static/dhcp/dhcp-on-stop ...
[09:30] <cpaelzer> I've read the commits now and I don't have a better idea how to resolve this - which means between the two of us it is the best idea we have so I won#t stop you on it
[09:30] <cpaelzer> :-)
[09:30] <cpaelzer> rafaeldtinoco: what about the "older" CriticalConnection attribute?
[09:31] <cpaelzer> could that be available in earlier systemd?
[09:31] <cpaelzer> https://github.com/systemd/systemd/commit/c98d78d32abba6aadbe89eece7acf0742f59047c
[09:31] <rafaeldtinoco> https://github.com/systemd/systemd/issues/12050
[09:31] <rafaeldtinoco> it does not prevent the issue
[09:31] <rafaeldtinoco> thus the need to create a new feature
[09:32] <cpaelzer> ok, thanks for checking that already
[09:32] <rafaeldtinoco> sure!
[09:33] <cpaelzer> rafaeldtinoco: -- topic switch -- did you see the  KVM acpi issue was resovled by just not passing acpi to the guest?
[09:33] <cpaelzer> sometimes trivial solutions are the best
[09:33] <rafaeldtinoco> cpaelzer: err, i knew that would "solve" the issue
[09:33] <rafaeldtinoco> but he wanted to shutdown through acpi
[09:34] <rafaeldtinoco> i thought about checking why acpid was working in previous qemu version
[09:34] <rafaeldtinoco> likely acpi tables from the new qemu broke older kernels
[09:34] <rafaeldtinoco> (thats what I had in mind)
[09:34] <rafaeldtinoco> but I saw your comment on modes
[09:34] <rafaeldtinoco> I wasn't aware of that
[09:34] <rafaeldtinoco> hopefully without acpi there is some other way for shutting down
[09:34] <cpaelzer> TBH he should go on with the non crashing case and resolve the shutdown in one of the "too many ways" to do it
[09:34] <rafaeldtinoco> guest being rhel does not give big incentive to continue =(
[09:34] <cpaelzer> anyway lets see what the bgu brings up, it seems ok for now
[09:35] <rafaeldtinoco> yep
[09:35] <cpaelzer> we are not a service-portal :-)
[09:35] <rafaeldtinoco> yep, its tricky to define where to stop
[09:35] <rafaeldtinoco> im learning =)
[10:59] <xnox> bdmurray:  infinity: but also that grub-installer upload didn't fix server iso. I don't know if more things are needed in grub-installer, or something else is broke.
=== paride2 is now known as paride
[11:47] <LocutusOfBorg> seb128, can you please also merge gst-plugins-bad1.0?
[11:47] <seb128> LocutusOfBorg, I would share my corrently open editor if that was easier :p
[11:47] <seb128> on it atm
[11:47] <seb128> currently
[11:48] <seb128> also there are a few from Debian where syncpackage tells me launchpad didn't pick the new version yet
[11:48] <seb128> which I will also sync
[11:52] <LocutusOfBorg> yes they have been uploaded half an hour ago, thanks for caring
[11:54] <LocutusOfBorg> on the gst-plugins-good1.0 merge some changelog entries have been lost... not sure if I made a mistake when updating git
[11:56] <LocutusOfBorg> http://launchpadlibrarian.net/444275983/gst-plugins-good1.0_1.16.0-3ubuntu2_1.16.1-1ubuntu1.diff.gz
[11:56] <LocutusOfBorg> looks like the changelog wasn't updated correctly?
[11:57] <seb128> LocutusOfBorg, what do you mean?
[11:57] <seb128> what changelog? how not correctly?
[11:57] <LocutusOfBorg> lots of entries disappeared
[11:57] <LocutusOfBorg> look at the diff on the queue...
[11:57] <seb128> debian/changelog?
[11:57] <LocutusOfBorg> yes
[11:58] <seb128> that's how I do merges
[11:58] <seb128> I don't keep the old entries
[11:58] <seb128> imagine we synced and added back some delta we dropped by error if that helps you :p)
[11:59] <LocutusOfBorg> actually I was going to do the same on some other package, just I never saw people doing it
[11:59] <LocutusOfBorg> lots of packages have more delta in changelog than everything else
[11:59] <seb128> right, well for desktop packages I tend to do it this way
[11:59] <seb128> the vcs and launchpad have the uploads history anyway
[12:00] <LocutusOfBorg> ok so the ubuntu/1.16.1-1ubuntu1 tagged differs from the uploaded package because of this pruning, right?
[12:01] <LocutusOfBorg> oh looks like git is updated
[12:01] <LocutusOfBorg> thanks, I'll do this on my merges from now on
[12:02] <seb128> np!
[12:04] <Laney> how can you do that with git? a debian/changelog merge driver which takes the 'theirs' side?
[12:58] <tumbleweed> 14
[12:58] <tumbleweed> with a /
[13:14] <rafaeldtinoco> cpaelzer: I remember seeing some discussions regarding rolling back the last systemd version in -proposed (242-6ubuntu1).
[13:14] <rafaeldtinoco> u know anything about it ? wondering which version I should backport the feature to
[13:14] <cpaelzer> rafaeldtinoco: it already changed from 243 to 242
[13:14] <cpaelzer> rbalint: will know
[13:15] <cpaelzer> ^^
=== ricab is now known as ricab|lunch
=== ricab|lunch is now known as ricab
=== dannf` is now known as dannf
[17:23] <bdmurray> xnox: I'm not seeing any indication that bug 1779767 is fixed in Eoan
[17:23] <ubottu> bug 1779767 in cron (Ubuntu) "Default cron PATH does not include /snap/bin" [Medium,Confirmed] https://launchpad.net/bugs/1779767
[20:57] <mwhudson> cpaelzer: thanks