Re: Why keep upstream sources in Git at salsa.d.o?
Alexis Murzeau wrote: > Le 13/08/2019 à 01:17, Daniel Leidert a écrit : >> Am Montag, den 12.08.2019, 19:53 +0200 schrieb Marc Haber: [...] >>> I haven't heard that a debian/ only repository layout is possible with >>> git-buildpackage before today. >> Works nicely. I keep a file debian/gbp.conf usually with the content [...] > I'm curious about keeping only debian/ in git. > How to build such git repository ? > I've tried one of yours but failed like this: [...] > I guess I'm missing either a part of git history or just the orig > tarball, but what's the normal way to get it ? > (maybe there is a doc or wiki somewhere about this ?) Looking at the manpage I think you'll need to give gbp a pointer to where the upstream tarball is available. --git-tarball-dir=DIRECTORY cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
On Tue, Aug 13, 2019 at 06:30:51PM +0100, Simon McVittie wrote: > > >> >Maybe /etc/machine-id should be part of the "API" of a Debian system in > > >> >general (systemd or not)? > > > > So /etc/machine-id should be in Policy? > > Probably yes, if that proposal has consensus, although a prerequisite > for it being in Policy would be to have an implementation of making it > exist even on systems with neither systemd nor dbus installed (Policy > is meant to document what's true, not what we hope will become true). That's just a matter of having sysvinit (and other non-systemd init systems) have an init script which runs as soon as the root file system is remounted read/write to initialize /etc/machine-id if it doesn't exist or if it is a zero-length file, right? - Ted
Re: Why keep upstream sources in Git at salsa.d.o?
Le 13/08/2019 à 01:17, Daniel Leidert a écrit : > Am Montag, den 12.08.2019, 19:53 +0200 schrieb Marc Haber: >> On Sun, 11 Aug 2019 15:03:51 +0200, Daniel Leidert >> wrote: >>> Am Sonntag, den 11.08.2019, 01:55 +0800 schrieb Drew Parsons: Upstreams are starting to use git lfs in their git repos. In some cases the git-lfs references files are retained in the source tarball, not replacing the reference with the actual files. This happens for instance with github repos (I gather it happens because the tarball is generated with 'git archive' [1]). An example is the mesh files [2] in pygalmesh 0.4.0 [3]. >>> >>> What I really don't understand is, why we duplicate upstream files (now >>> even >>> really large files) on salsa.d.o. The debian/-only approach (or "overlay" >>> layout in git-buildpackage) works fine. Salsa CI also works just fine. >> >> When I started with mantaining my packages in git, that layout way not >> yet available. Actually, this was my major beef against git since I >> had been using this approach happily with svn und svn-buildpackage for >> years. >> >> I haven't heard that a debian/ only repository layout is possible with >> git-buildpackage before today. > > Works nicely. I keep a file debian/gbp.conf usually with the content > >> [DEFAULT] >> pristine-tar = false >> debian-branch = master # or debian/sid >> verbose = true >> >> [buildpackage] >> overlay = true > > in Git for others; and I use debian/.gitattributes with this content: > >> .gitattributes export-ignore >> salsa-ci.yml export-ignore >> gbp.conf export-ignore > > to keep the Debian package clean. > > The default salsa-ci.yml works very well with this too. We use this layout for > most of our packages in the debichem team. As far as I heard, the KDE team > uses > it too. > > `gbp pq` doesn't work with this layout. > > Regards, Daniel > Hi, I'm curious about keeping only debian/ in git. How to build such git repository ? I've tried one of yours but failed like this: ``` $ gbp clone https://salsa.debian.org/ruby-team/ruby-html-proofer gbp:info: Cloning from 'https://salsa.debian.org/ruby-team/ruby-html-proofer' $ cd ruby-html-proofer/ $ gbp buildpackage "--git-builder=sbuild -v -As -d unstable" \ > --git-export-dir=../build-area gbp:error: upstream/3.11.1 is not a valid treeish ``` I guess I'm missing either a part of git history or just the orig tarball, but what's the normal way to get it ? (maybe there is a doc or wiki somewhere about this ?) -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Re: functions of libxmlsec1.so
On Tue, Aug 13, 2019 at 07:55:15PM +, Tiago Tarifa Munhoz wrote: > Hi guys! > Forgive me for any mistake in English. > > I have only 2 questions: > 1- Why does libxmlsec1.so not have these built-in functions in Debian? > xmlSecCryptoDLLoadLibrary, xmlSecCryptoAppInit, xmlSecCryptoInit, > xmlSecCryptoShutdown, xmlSecCryptoAppShutdown, xmlSecCryptoAppKeyLoadMemory, > xmlSecCryptoShutdown, xmlSecCryptoAppShutdown, xmlSecCryptoAppKeyLoadMemory, > xmlSecCryptoAppDefaultKeysMngrInit, xmlSecCryptoAppKeysMngrCertLoadMemory, > xmlSecCryptoAppKeyLoadMemory > If I compile from Debian source code or use another Gnu / Linux like Gentoo > or OpenSuSE, these functions are there. > > 2- Is Debian interested in adding these functions someday? Please read the package description and look at libxmlsec1-openssl and related packages. -- WBR, wRAR signature.asc Description: PGP signature
functions of libxmlsec1.so
Hi guys! Forgive me for any mistake in English. I have only 2 questions: 1- Why does libxmlsec1.so not have these built-in functions in Debian? xmlSecCryptoDLLoadLibrary, xmlSecCryptoAppInit, xmlSecCryptoInit, xmlSecCryptoShutdown, xmlSecCryptoAppShutdown, xmlSecCryptoAppKeyLoadMemory, xmlSecCryptoShutdown, xmlSecCryptoAppShutdown, xmlSecCryptoAppKeyLoadMemory, xmlSecCryptoAppDefaultKeysMngrInit, xmlSecCryptoAppKeysMngrCertLoadMemory, xmlSecCryptoAppKeyLoadMemory If I compile from Debian source code or use another Gnu / Linux like Gentoo or OpenSuSE, these functions are there. 2- Is Debian interested in adding these functions someday?
Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
On Tue, 13 Aug 2019 at 14:22:31 +0200, Marc Haber wrote: > On Tue, 13 Aug 2019 12:01:13 +0100, Simon McVittie > wrote: > >(systemd cannot create a mount point that doesn't exist yet on a read-only > >file system, which is why a zero-byte file is preferred. > > but you can bind-mount over a file? I wasn't aware of that. Yes, you can bind-mount a directory over another directory, or a non-directory non-symlink over another non-directory non-symlink. (Symlinks get dereferenced before they're used as the source or destination of a bind-mount.) bubblewrap and other container-runners often use this when setting up containers - for example if you have a Flatpak app installed, try something like flatpak run --command=mount org.gnome.Recipes and you'll see that the container's /etc is a mixture of read-only bind-mounts from the host system and read-only bind-mounts from the runtime, some of which are individual files. > >> >Maybe /etc/machine-id should be part of the "API" of a Debian system in > >> >general (systemd or not)? > > So /etc/machine-id should be in Policy? Probably yes, if that proposal has consensus, although a prerequisite for it being in Policy would be to have an implementation of making it exist even on systems with neither systemd nor dbus installed (Policy is meant to document what's true, not what we hope will become true). smcv
Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
On Tue, 13 Aug 2019 12:01:13 +0100, Simon McVittie wrote: >(systemd cannot create a mount point that doesn't exist yet on a read-only >file system, which is why a zero-byte file is preferred. but you can bind-mount over a file? I wasn't aware of that. >If you use systemd as init, install dbus, delete or empty /etc/machine-id, >delete /var/lib/dbus/machine-id and reboot, then systemd will recreate >/etc/machine-id very early in the boot process. Less early but still early >in the boot process (before units with DefaultDependencies=yes, analogous >to rcS in sysvinit), systemd-tmpfiles will make /var/lib/dbus/machine-id >a symlink as directed by /usr/lib/tmpfiles.d/dbus.conf. By the time >ordinary system services start, it is already a symlink. Might this be >what happened on your test systems? Probably, yes. >> >Maybe /etc/machine-id should be part of the "API" of a Debian system in >> >general (systemd or not)? >> >> please elaborate on that. > >There are some properties that we guarantee every Debian system will have, >even though they cannot be guaranteed on every GNU or Linux system. For >example, Policy guarantees that /var/run is always a symlink to /run on >Debian systems (even though they are distinct directories on e.g. >Slackware[1], and as a result upstream projects like dbus can't rely on >/var/run being equivalent to /run). Similarly, we guarantee that all >Debian systems will have the base-passwd users and groups, with their >canonical numeric values. So /etc/machine-id should be in Policy? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
> "Simon" == Simon McVittie writes: Simon> If you use systemd as init, install dbus, delete or empty Simon> /etc/machine-id, delete /var/lib/dbus/machine-id and reboot, It is my experience that deleting /etc/machine-id doesn't actually work (even if I delete the dbus machine id too). It may well be that a zero-byte file works; I didn't know to try that. But my experience parallels someone earlier on the list that deleting machine-id does not actually work.
Re: salsa.debian.org partially down
On Tue, 13 Aug 2019, Hector Oron wrote: > Hello, > > Missatge de Bastian Blank del dia dt., 13 d’ag. > 2019 a les 11:51: > > > > Hi folks > > > > salsa.debian.org is partially down for now. Especially everything that > > concerns Salsa CI. > > > > Someone decided to inject a few thousand CI jobs using Salsa CI > > yesterday evening. Since then the system is not longer at 50% load, but > > at a 100%. It turns out that the configured amount of concurrency in CI > > builds can't be handled by the current available system resources. > > > > This now affects all user access to salsa.debian.org. So we disabled > > access to all the Salsa CI stuff for now, which will make everything > > using it fail. > > > > We have to discuss first how we can go forward. > > Those are very bad news. I hope that can be recovered soon. If you > need more resources to be able to handle more jobs or longer timeouts, > please let DPL know so more resources can be added. It is already recovered. We will investigate where we can extend the ressources. But some misusages (like requesting >1300 merge requests via API on a big project, that in consequence run >1300 ci jobs, that...) can't be solved regardless on how many resources we add. Alex
Re: salsa.debian.org partially down
Hello, Missatge de Bastian Blank del dia dt., 13 d’ag. 2019 a les 11:51: > > Hi folks > > salsa.debian.org is partially down for now. Especially everything that > concerns Salsa CI. > > Someone decided to inject a few thousand CI jobs using Salsa CI > yesterday evening. Since then the system is not longer at 50% load, but > at a 100%. It turns out that the configured amount of concurrency in CI > builds can't be handled by the current available system resources. > > This now affects all user access to salsa.debian.org. So we disabled > access to all the Salsa CI stuff for now, which will make everything > using it fail. > > We have to discuss first how we can go forward. Those are very bad news. I hope that can be recovered soon. If you need more resources to be able to handle more jobs or longer timeouts, please let DPL know so more resources can be added. Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
On Tue, 13 Aug 2019 at 11:50:27 +0200, Marc Haber wrote: > On Thu, 8 Aug 2019 22:44:19 +0100, Simon McVittie > wrote: > >Making /etc/machine-id a 0-byte file is considered to be the canonical > >way to clear it, rather than actually deleting it, because if systemd is > >running on a completely read-only root filesystem, it has code to create > >a machine ID on a tmpfs and bind-mount it over the top of the empty file. > > And what will systemd do when it encounters a zero-sized > /etc/machine-id on a writable filesystem? Replace it with a new machine ID, the same as if it didn't exist at all: After the machine ID is established, systemd(1) will attempt to save it to /etc/machine-id. If this fails, it will attempt to bind-mount a temporary file over /etc/machine-id. It is an error if the file system is read-only and does not contain a (possibly empty) /etc/machine-id file. — machine-id(5) (systemd cannot create a mount point that doesn't exist yet on a read-only file system, which is why a zero-byte file is preferred.) > >If you are doing cloning, stateless systems or similar activities, > >and you know you will have a valid /etc/machine-id (you either use > >systemd or have taken other steps to have one), then you can make > >/var/lib/dbus/machine-id a symlink to /etc/machine-id (dbus comes with a > >systemd-tmpfiles file to do this). This is not done by default in Debian, > >or by `dbus-uuidgen --ensure`, for historical reasons > > Interesting, I see this on a number of my test systems without having > been active in this regard myself. If you use systemd as init, install dbus, delete or empty /etc/machine-id, delete /var/lib/dbus/machine-id and reboot, then systemd will recreate /etc/machine-id very early in the boot process. Less early but still early in the boot process (before units with DefaultDependencies=yes, analogous to rcS in sysvinit), systemd-tmpfiles will make /var/lib/dbus/machine-id a symlink as directed by /usr/lib/tmpfiles.d/dbus.conf. By the time ordinary system services start, it is already a symlink. Might this be what happened on your test systems? I'm fairly sure that dbus-uuidgen (which is run in dbus.postinst, and from /etc/init.d/dbus on non-systemd systems) always makes /var/lib/dbus/machine-id a regular file rather than a symlink, but if you already had dbus installed before you reset the machine ID, and you did not subsequently boot with a non-systemd init, then dbus-uuidgen wouldn't have been run. If /var/lib/dbus/machine-id is already a symlink to a file with contents in the right format, dbus-uuidgen won't replace it. > >Maybe /etc/machine-id should be part of the "API" of a Debian system in > >general (systemd or not)? > > please elaborate on that. There are some properties that we guarantee every Debian system will have, even though they cannot be guaranteed on every GNU or Linux system. For example, Policy guarantees that /var/run is always a symlink to /run on Debian systems (even though they are distinct directories on e.g. Slackware[1], and as a result upstream projects like dbus can't rely on /var/run being equivalent to /run). Similarly, we guarantee that all Debian systems will have the base-passwd users and groups, with their canonical numeric values. Some of those properties either originated in systemd and were adopted in Debian for even non-systemd systems (for example /usr/lib/os-release in base-files, which originated in systemd as a replacement for lsb_release and distro-specific facilities like /etc/debian_version), or originated in Debian or some other distro and have been adopted by systemd as one of its "API" guarantees on all distros that use it (for example systemd picked up Debian's /etc/hostname, /etc/timezone and /etc/sysctl.d). In both cases this is done on the basis that regardless of origin, they are good ideas that should be spread further, and giving application and library maintainers more "API" guarantees from the OS makes their jobs easier. What I'm suggesting is that maybe a systemd-style /etc/machine-id should be one of those properties that we guarantee, instead of relying on dbus (which is an IPC system that has very little to do with uniquely identifying a machine) to provide the closest thing that is guaranteed on non-systemd-booted machines. Because systemd does not delete /etc/machine-id even when purged (that would be counterproductive for its intended purpose, and would break stored state that refers to it), it is present on all systems that either boot with systemd or have switched from systemd to sysvinit. The only Debian systems that will not already have /etc/machine-id are those that were installed before systemd became the default (wheezy or older) or as a minimal debootstrap with no init system at all (jessie or newer), may have subsequently been upgraded to newer suites, but have never run systemd.postinst or booted with systemd. smcv [1] I think this is an unwise
Bug#934681: ITP: tartube -- A GUI front-end for youtube-dl
Package: wnpp Severity: wishlist Owner: Félix Sipma * Package name: tartube Version : 1.0.0 Upstream Author : A S Lewis * URL : https://github.com/axcore/tartube * License : GPL-3 Programming Lang: Python Description : A GUI front-end for youtube-dl Tartube is a GUI front-end for youtube-dl, partly based on youtube-dl-gui and written in Python 3 / Gtk 3. - You can download individual videos, and even whole channels and playlists, from YouTube and hundreds of other sites - You can fetch information about those videos, channels and playlists, without actually downloading anything - Tartube will organise your videos into convenient folders - Certain popular websites manipulate search results, repeatedly unsubscribe people from their favourite channels and/or deliberately conceal videos that they don't like. Tartube won't do any of those things - Tartube can, in some circumstances, see videos that are region-blocked and/or age-restricted I will need a sponsor to upload it. signature.asc Description: PGP signature
Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
On Thu, 8 Aug 2019 22:44:19 +0100, Simon McVittie wrote: >Making /etc/machine-id a 0-byte file is considered to be the canonical >way to clear it, rather than actually deleting it, because if systemd is >running on a completely read-only root filesystem, it has code to create >a machine ID on a tmpfs and bind-mount it over the top of the empty file. And what will systemd do when it encounters a zero-sized /etc/machine-id on a writable filesystem? >If you are doing cloning, stateless systems or similar activities, >and you know you will have a valid /etc/machine-id (you either use >systemd or have taken other steps to have one), then you can make >/var/lib/dbus/machine-id a symlink to /etc/machine-id (dbus comes with a >systemd-tmpfiles file to do this). This is not done by default in Debian, >or by `dbus-uuidgen --ensure`, for historical reasons; maybe it should be, >but to be confident that it was a correct change I'd have to think about >the ways in which it might go wrong on non-systemd systems (with either >a non-systemd init like sysvinit, or no init at all like minimal chroots). Interesting, I see this on a number of my test systems without having been active in this regard myself. >Maybe /etc/machine-id should be part of the "API" of a Debian system in >general (systemd or not)? please elaborate on that. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Generating new IDs for cloning
On Thu, 8 Aug 2019 22:59:05 +0100, Simon McVittie wrote: >On Thu, 08 Aug 2019 at 08:37:16 -0400, Marvin Renich wrote: >> Does anyone know what applications use this file for what purpose? Is >> this a systemd-ism? > >It originated as /var/lib/dbus/machine-id in D-Bus, and systemd picked it >up and generalized it into something non-D-Bus-specific. It isn't really >particularly specific to either D-Bus or systemd: they both provide it >as a piece of generically useful functionality for anything else that >wants it. Asking which applications use it is a bit like asking which >applications use gethostname(2): you are not going to get an exhaustive >list unless you use something like codesearch. > >It's intended as an opaque, non-human-meaningful, persistent unique >identifier for a machine (or more precisely an OS installation), used as >a lookup key in state/configuration storage in the same sorts of places >you might be tempted to use a hostname. > >Being opaque and non-human-meaningful is important for some of the >places where it's useful, because if a string is human-meaningful (like a >hostname), then people will sometimes want to change it, and when they do, >anything that was recording machine-specific state with the hostname as >unique identifer will no longer be able to associate the machine-specific >state with the machine, effectively resulting in data loss. > >One example of the machine ID being used to identify hardware devices >is that GNOME stores screen layout configuration keyed by machine ID, >so that if you have an NFS-shared home directory or similar, it won't try >to use your laptop's monitor layout on your desktop (or keep overwriting >one layout with the other). > >One example of the machine ID being used to identify an OS installation is >that if you use the systemd-boot EFI bootloader on a dual- or multi-boot >Linux system (e.g. Debian and Fedora sharing a disk), systemd-boot stores >each OS installation's kernel(s) in a directory named after the machine >ID, so that they won't collide. I have worked that information into the wiki page https://wiki.debian.org/MachineId and appreciate your input. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bug#934671: ITP: libanyevent-websocket-client-perl -- WebSocket client for AnyEvent
Package: wnpp Owner: Xavier Guimard Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libanyevent-websocket-client-perl Version : 0.53 Upstream Author : Graham Ollis * URL : https://metacpan.org/release/AnyEvent-WebSocket-Client * License : Artistic or GPL-1+ Programming Lang: Perl Description : WebSocket client for AnyEvent AnyEvent::WebSocket provides an interface to interact with a web server that provides services via the WebSocket protocol in an AnyEvent context. It uses Protocol::WebSocket rather than reinventing the wheel. You could use AnyEvent and Protocol::WebSocket directly if you wanted finer grain control, but if that is not necessary then this class may save you some time. The recommended API was added to the AnyEvent::WebSocket::Connection class with version 0.12, so it is recommended that you include that version when using this module. The older version of the API has since been deprecated and removed. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#934670: ITP: libprotocol-websocket-perl -- Perl library that implements WebSocket protocol
Package: wnpp Owner: Xavier Guimard Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libprotocol-websocket-perl Version : 0.26 Upstream Author : Viacheslav Tykhanovskyi C. * URL : https://metacpan.org/release/Protocol-WebSocket * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl library that implements WebSocket protocol Client/server WebSocket message and frame parser/constructor. Protocol::WebSocket does not provide a WebSocket server or client, but is made for using in http servers or clients to provide WebSocket support. Protocol::WebSocket supports the following WebSocket protocol versions: * draft-ietf-hybi-17 (latest) * draft-ietf-hybi-10 * draft-ietf-hybi-00 (with HAProxy support) * draft-hixie-75 By default the latest version is used. The WebSocket version is detected automatically on the server side. On the client side you have set a version attribute to an appropriate value. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#934669: ITP: libanyevent-connector-perl -- tcp_connect with transparent proxy handling
Package: wnpp Owner: Xavier Guimard Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libanyevent-connector-perl Version : 0.03 Upstream Author : Toshio Ito * URL : https://metacpan.org/release/AnyEvent-Connector * License : Artistic or GPL-1+ Programming Lang: Perl Description : tcp_connect with transparent proxy handling AnyEvent::Connector object has tcp_connect method compatible with that from AnyEvent::Socket, and it handles proxy settings transparently. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#934668: ITP: liburi-ws-perl -- WebSocket support for URI package
Package: wnpp Owner: Xavier Guimard Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: liburi-ws-perl Version : 0.03 Upstream Author : Graham Ollis * URL : https://metacpan.org/release/URI-ws * License : Artistic or GPL-1+ Programming Lang: Perl Description : WebSocket support for URI package After URI::ws is installed, the URI package provides the same set of methods for secure WebSocket URIs as it does for insecure WebSocket URIs. For insecure (unencrypted) WebSockets. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
