Bug#963946: ITP: libpath-dispatcher-perl -- flexible and extensible dispatcher module
Package: wnpp Severity: wishlist Owner: Andrew Ruthven * Package name: libpath-dispatcher-perl Version : 1.07 Upstream Author : Shawn M Moore * URL : https://metacpan.org/pod/Path::Dispatcher * License : GPL v1+ or Artistic License Programming Lang: Perl Description : flexible and extensible dispatcher module Path::Dispatcher is a Perl module that allows a program to determine which code to execute by matching a path against a list of rules. Dispatch takes a path and returns a list of matches; from there, you can "run" the rules that matched. Developers may also inspect which rules were matched without executing their codeblocks. This package is a dependency on the upcoming Request Tracker 5 release. It has been in Debian in the past but was removed for Buster due to a dependency on a deprecated package[0]. Path::Dispatcher has since been updated to remove that dependency. The Debian Perl Group will maintain this package. Updated packaging for Debian is here: https://salsa.debian.org/perl-team/modules/packages/libpath-dispatcher-perl Cheers, Andrew [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845804
Re: debdocker - A Debian docker-based personal builder
On 6/27/20 06:08, Samo Pogačnik wrote: Hi, I am preparing a packaging support tool similar to pbuilder, except that it uses docker containers instead of chroot environments. The project is available here: https://salsa.debian.org/spog/debdocker The tool is very immature, but already useful to me. I would like to hear any thoughts and comments regarding the tool in general and regarding its user experience. Quick reference (running out of cloned project - no warranties!): 1. Help: $ ./debdocker --help [command] $ man ./share/man/man8/debdocker.8 2. Create initial base and devel docker images for i.e. debian:sid, which uses 'debootstrap' for base image like in 'pbuilder'. It creates base directory and archive in the supplied path (i.e. ../ in the example): $ sudo ./debdocker create debian:sid all ../ http://deb.debian.org/debian 3. Get a source package (i.e. in ../ use 'dget -d...). 4. Build a package, which creates additional (i.e. debian:sid-package_devel) docker image with installed package's build deps (it is reused while working on the same package): $ ./debdocker build debian:sid ../package_*.dsc 5. You can also build extracted (or cloned) sources providing their path instead of the 'dsc_file'. There is also a possibility to enter containers (see the 'enter' command)... 6. Building an initial 'debdocker' debian package is supported in the project. thanks, Samo Hi Samo, Long time ago I wrote something similar from a very simple bash script. Maybe it would be worth it to check it out. Is really simple and short. Let me know if you have any question. I'm happy to help. https://github.com/resnullius/deb-build-pkg
Bug#925530: cloud.debian.org: Debian docker images pointing to github for bug tracking
On 6/28/20 10:58 PM, Lucas Nussbaum wrote: > Well, I think that it would a good thing for Debian to enforce some > consistency on Debian images for clouds and software that require > VM images, at least about where to find information about such images, > and where to report problems. > > And I don't think that pointing to github for our tooling, and for bug > reporting, is really an acceptable solution for something that is > officially endorsed by Debian. Official *Docker* images come from https://github.com/docker-library/official-images It might be possible to pull git repositories from the outside of git hub in there, though, but I doubt it is. At least you'll have to use github pull requests. Of course you are free to run your own registry even under a debian.org domain and provide official Debian images for docker there, but as long as you want to have them in the docker hub, I think the current practice is just fine. And: its an image from DOCKER, maintained by Debian developers - its not an image from DEBIAN. It says 'Docker official images', not 'Debian official images'. To be honest, I fail to understand why this needs discussion at all. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#925530: cloud.debian.org: Debian docker images pointing to github for bug tracking
On 28/06/20 at 10:54 -0700, Ross Vandegrift wrote: > [removing serpent@d.o from CC, he's resigned as delegate] > > Hi Lucas, > > On Sun, Jun 28, 2020 at 05:26:41PM +0200, Lucas Nussbaum wrote: > > One could argue that the Cloud team delegation does not cover Docker > > images. > > Whether it does or not, I've been told that the docker image maintainers > prefer > to keep their current organization and workflow. I'd welcome their > participation in the team, if they were interested. But I don't think they > need to be. Well, I think that it would a good thing for Debian to enforce some consistency on Debian images for clouds and software that require VM images, at least about where to find information about such images, and where to report problems. And I don't think that pointing to github for our tooling, and for bug reporting, is really an acceptable solution for something that is officially endorsed by Debian. Solving this for Docker or Vagrant sounds very similar to solving it for cloud images; so it's probably best if the same people are in charge. > Maybe it could be nice, if the people building those images want to use our > tools and work with us. Some would raise concerns in my mind, but I don't > think it's useful to discuss before someone wants to build e.g. raspberry pi > images in cloud-team. I'm surprised by this. I thought of the delegation as a (soft) hammer to enforce some rules, even when people are not nice and don't want to work with the cloud team (I'm not saying it's the case here). I've seen people saying "oh look, the official Debian images for docker point to github! that's funnny!". If those images are not official, then this should be clarified. If they are, then they should probably conform to standard ways of maintaining stuff in Debian. Lucas
Bug#963930: O: starfighter -- 2D scrolling shooter game
Package: wnpp Severity: normal I intend to orphan the starfighter package. I no longer have time to maintain this package. This game is actively maintained, and there are newer upstream versions of this game that should be packaged: https://github.com/pr-starfighter/starfighter/releases The package description is: After decades of war one company, who had gained powerful supplying both sides with weaponry, steps forwards and crushes both warring factions in one swift movement. Using far superior weaponry and AI craft, the company was completely unstoppable and now no one can stand in their way. Thousands began to perish under the iron fist of the company. The people cried out for a saviour, for someone to light this dark hour... and someone did. . Features of the game: . o 26 missions over 4 star systems o Primary and Secondary Weapons (including a laser cannon and a charge weapon) o A weapon powerup system o Wingmates o Missions with Primary and Secondary Objectives o A Variety of Missions (Protect, Destroy, etc) o Boss battles
Bug#963929: O: rsh-redone -- Reimplementation of rsh and rlogin
Package: wnpp Severity: normal I intend to orphan the rsh-redone package. I no longer have time to maintain this. I am also the upstream author of this; if you want to adopt the package, you are also welcome to take over upstream maintainership. However, since no-one should be using RSH in this day and age anymore, if no one is interested I will request removal of this package. The package description is: Rsh-redone is a reimplementation of the remote shell clients and servers. It is written from the ground up to avoid the bugs found in the standard clients and servers. It also fully supports IPv6. . This package provides rsh and rlogin.
Bug#963925: O: mod-mime-xattr -- Apache2 module to get MIME info from filesystem extended attributes
Package: wnpp Severity: normal I intend to orphan the mod-mime-xattr package. Upstream has stopped maintaining this a long time ago, and there are only few users according to popcon. If there is no interest in it, I will request a removal. The package description is: This is a module for the Apache HTTPD 2.4 which may be used to set a range of MIME properties of files served from a document tree with extended attributes (EAs) as supported by the underlying file system. The following attributes may be used: . - user.mime_type: set the MIME type of a file explicitly. This attribute is compatible with the shared MIME database specification as published by freedesktop.org. - user.charset: set the charset used in a file. - user.mime_encoding: set the MIME encoding of a file (e.g. gzip). - user.apache_handler: set the apache handler of a file explicitly. This is a module for the Apache HTTPD 2.4 which may be used to set a range of MIME properties of files served from a document tree with extended attributes (EAs) as supported by the underlying file system. The following attributes may be used: . - user.mime_type: set the MIME type of a file explicitly. This attribute is compatible with the shared MIME database specification as published by freedesktop.org. - user.charset: set the charset used in a file. - user.mime_encoding: set the MIME encoding of a file (e.g. gzip). - user.apache_handler: set the apache handler of a file explicitly.
Bug#963928: O: omega-rpg -- text-based roguelike game
Package: wnpp Severity: normal I intend to orphan the omega-rpg package. I no longer have time to maintain this package. The package description is: Omega is a complex rogue-style game of dungeon exploration. Unlike other such games, there are a number of ways to "win", depending on various actions taken during play. The ways you can get your name on the high score board include becoming the highest ranked head of a guild, sect, college, etc., as well as gaining the most points figured from possessions and experience. The game (via the oracle) may impose some structure on your exploration, but you need not follow all of the oracle's advice. There *is* a "total winner" status, by the way.
Bug#963926: O: mstch -- Mustache implementation in C++11
Package: wnpp
Severity: normal
I intend to orphan the mstch package.
The package description is:
Mstch is a complete implementation of {{mustache}} templates using
modern C++. It's compliant with specifications v1.1.3, including the
lambda module.
.
Mustache is a logic-less template language. As such, it is very well
suited for programs that are written in a compiled language, such as C
and C++, as they cannot easily evaluate code found in a template.
Mustache does however supports a simple conditional and a loop statement.
.
This package contains the header files and a static library.
Bug#963923: O: libdc1394 -- high level programming interface for IEEE 1394 digital cameras
Package: wnpp Severity: normal I intend to orphan the libdc1394 package. There is occasional upstream activity for this package. At the moment there are no reverse dependencies, but this package replaces libdc1394-22, and the new maintainer should ensure the transition from libdc1394-22 to libdc1394 is completed. The package description is: libdc1394 is a library that is intended to provide a high level programming interface for application developers who wish to control IEEE 1394 based cameras that conform to the 1394-based Digital Camera Specification (found at http://www.1394ta.org/). . This version of libdc1394 supports both the old and new (juju) FireWire stack. It automatically detects which one to use at runtime. . This package contains shared libraries.
Bug#963920: O: fgallery -- static HTML+JavaScript photo album generator
Package: wnpp Severity: normal I intend to orphan the fgallery package. There has been no upstream activity in the last 4 years, but apart from that the package is working as intended. This program generates very nice, mobile-friendly and responsive galleries. The package description is: “fgallery” is a static photo gallery generator with no frills that has a stylish, minimalist look. “fgallery” shows your photos, and nothing else. . There is no server-side processing, only static generation. The resulting gallery can be uploaded anywhere without additional requirements and works with any modern browser. . * Automatically orients pictures without quality loss. * Multi-camera friendly: automatically sorts pictures by time: just throw your (and your friends) photos and movies in a directory. The resulting gallery shows the pictures in seamless shooting order. * Adapts to the current screen size and proportions, switching from horizontal/vertical layout and scaling thumbnails automatically. * Includes original (raw) pictures in a zip file for downloading. * Panoramas can be seen full-size by default.
Bug#963921: O: inputlirc -- Zeroconf LIRC daemon using input event devices
Package: wnpp Severity: normal I intend to orphan the inputlirc package. I'm also the upstream maintainer of this package, if you are interested in maintaining it you are welcome to take over upstream maintainership as well. The package description is: This is a small LIRC-compatible daemon that reads from /dev/input/eventX devices and sends the received keycodes to connecting LIRC clients. Inputlircd needs no configuration, it uses the standardised names for the keycodes as used by the kernel. Many USB remote controls that present HID devices, as well as multimedia keyboards should work out of the box. This is a small LIRC-compatible daemon that reads from /dev/input/eventX devices and sends the received keycodes to connecting LIRC clients. Inputlircd needs no configuration, it uses the standardised names for the keycodes as used by the kernel. Many USB remote controls that present HID devices, as well as multimedia keyboards should work out of the box.
Bug#963917: O: dhis-tools-dns -- Dynamic Host Information System - DNS configuration tools
Package: wnpp Severity: normal I intend to orphan the dhis-tools-dns package. According to popcon, there is very little interest in this package. If no one will adopt it, I will request removal. The package description is: This package includes a set of tools that may be used to manually create DHIS records on a dynamic DNS server.
Bug#963915: O: dhis-mx-sendmail-engine -- Dynamic Host Information System - sendmail MX engine
Package: wnpp Severity: normal I intend to orphan the dhis-mx-sendmail-engine package. According to popcon, there is very little interest in this package. If no one will adopt it, I will request removal. The package description is: This package contains a mail relaying service module to be used with dhisd release 5 or above and the dynamic DNS module. . While the DHIS server dhisd retrieves dynamic IP addresses from clients, this module allows the server to deliver messages that were previously queued for the newly online host.
Bug#963914: O: dhis-dns-engine -- Dynamic Host Information System - DNS engine
Package: wnpp Severity: normal I intend to orphan the dhis-dns-engine package. According to popcon, there is very little interest in this package. If no one will adopt it, I will request removal. The package description is: This package contains a dynamic DNS service module to be used with dhisd release 5 or above. . While the DHIS server dhisd retrieves dynamic IP addresses from clients, this module allows the server to update a dynamic DNS zone based on those retrieved IP addresses.
Bug#963912: O: dhis-client -- Dynamic Host Information System - client
Package: wnpp Severity: normal I intend to orphan the dhis-client package. According to popcon, there is very little interest in this package. If no one will adopt it, I will request removal. The package description is: dhid is the DHIS client daemon. After setting up with a DHIS provider, each machine may run a dhid daemon (in background) in order to update its dynamic IP address within the server.
Bug#963913: O: dhis-server -- Dynamic Host Information System - server
Package: wnpp Severity: normal I intend to orphan the dhis-server package. According to popcon, there is very little interest in this package. If no one will adopt it, I will request removal. The package description is: DHIS is a client-server architecture meant to update databases for systems which are assigned a dynamic IP[v4] address. . By the means of a DHIS client a host which is assigned a dynamic IP address (either from its ISP or from DHCP) is able to communicate with a DHIS server in order to advertise its newly acquired IP address.
Bug#963911: O: coriander -- control IEEE1394 digital camera
Package: wnpp Severity: normal I intend to orphan the coriander package. This is a live camera viewer for Firewire and USB Vision cameras (mainly industrial and scientific cameras, not webcams). It is not being maintained upstream anymore, but it is otherwise functional. The package description is: Coriander is a GUI that lets you view camera images and control all the features of an IEEE-1394 Digital Camera complying with the DC Specifications v1.04 or later (see http://www.1394ta.org).
Bug#963910: O: blobwars -- platform shooting game
Package: wnpp Severity: normal I intend to orphan the blobwars package. This game has no active upstream developers, but it is in a very good state. There are some minor bugs that could be fixed. The package description is: Blob Wars: Metal Blob Solid is a 2D platform game. It is the first in the Blob Wars series. . Since their world was invaded by an alien race, the Blobs have faced a lifetime of war. But now they have a chance to win the war once and for all. . In Blob Wars: Metal Blob Solid, you take on the role of a fearless Blob agent, Bob. Bob's mission is to infiltrate the various enemy bases around the Blobs' homeworld and rescue as many MIAs as possible. But standing in his way are many vicious aliens, other Blobs who have been assimilated and the evil alien leader, Galdov. Blob Wars: Metal Blob Solid is a 2D platform game. It is the first in the Blob Wars series. . Since their world was invaded by an alien race, the Blobs have faced a lifetime of war. But now they have a chance to win the war once and for all. . In Blob Wars: Metal Blob Solid, you take on the role of a fearless Blob agent, Bob. Bob's mission is to infiltrate the various enemy bases around the Blobs' homeworld and rescue as many MIAs as possible. But standing in his way are many vicious aliens, other Blobs who have been assimilated and the evil alien leader, Galdov.
Bug#963909: O: blobandconquer -- 3D platform shooting game
Package: wnpp Severity: normal I intend to orphan the blobandconquer package. Due to the original game having undistributable music, sound and graphics assets, this game is not very interesting to play. The upstream developers are also not maintaining this game anymore. If you wish to take over this package, some effort should be put into replacing all the assets with DFSG-compatible ones. If there is no interest, I will ask for removal of this package. The package description is: Blob Wars episode II: Blob and Conquer is the sequel to Blob Wars: Metal Blob Solid. . With the apparent defeat of Galdov and the reclaiming of the Fire, Time, Space and Reality Crystals the Blobs' battle was only just beginning. Bob had rescued many Blobs and fought many battles, but now he had an ever bigger task ahead of him. The Blobs' homeworld is still littered with the alien forces and Bob once again makes it his task to lead the counter attack. But even without Galdov the aliens are still extremely well organised... Blob Wars episode II: Blob and Conquer is the sequel to Blob Wars: Metal Blob Solid. . With the apparent defeat of Galdov and the reclaiming of the Fire, Time, Space and Reality Crystals the Blobs' battle was only just beginning. Bob had rescued many Blobs and fought many battles, but now he had an ever bigger task ahead of him. The Blobs' homeworld is still littered with the alien forces and Bob once again makes it his task to lead the counter attack. But even without Galdov the aliens are still extremely well organised...
Bug#963896: O: wireless-tools -- Tools for manipulating Linux Wireless Extensions
Package: wnpp Severity: normal I intend to orphan the wireless-tools package. I no longer have time to work on this package. This package implements a library and binary to perform static configuration of wireless network interfaces using the legacy Wireless Extensions of the Linux kernel. Wireless interfaces should now be configured via Netlink, which is what the iw package does, so ideally wireless-tools should be phased out. However, there are still some packages that depend on libiw30, which wireless-tools provides. The package description is: This package contains the Wireless tools, used to manipulate the Linux Wireless Extensions. The Wireless Extension is an interface allowing you to set Wireless LAN specific parameters and get the specific stats.
Bug#963889: O: ifenslave -- configure network interfaces for parallel routing (bonding)
Package: wnpp Severity: normal I intend to orphan the ifenslave package. I no longer have any time to work on it. The package has an important bug that should be fixed. Linux bonding interfaces use a controversial naming scheme (master/slave, and the package name itself reflects this). If you adopt this, I suggest changing the package name to "bonding", and replace the master/slave terminology with parent/child. ifenslave used to be a standalone binary that sent ioctls to the kernel, but nowadays bonding can be configured via the "ip" command from the iproute2 package, and by writing to the /sys/ tree. The package no longer contains the standalone binary, but just provides hooks scripts for ifupdown. The package description is: This is a tool to attach and detach slave network interfaces to a bonding device. A bonding device will act like a normal Ethernet network device to the kernel, but will send out the packets via the slave devices using a simple round-robin scheduler. This allows for simple load-balancing, identical to "channel bonding" or "trunking" techniques used in switches. . The kernel must have support for bonding devices for ifenslave to be useful. This package supports 2.6.x kernels and the recent 3.x.x kernels. This is a tool to attach and detach slave network interfaces to a bonding device. A bonding device will act like a normal Ethernet network device to the kernel, but will send out the packets via the slave devices using a simple round-robin scheduler. This allows for simple load-balancing, identical to "channel bonding" or "trunking" techniques used in switches. . The kernel must have support for bonding devices for ifenslave to be useful. This package supports 2.6.x kernels and the recent 3.x.x kernels.
Bug#925530: cloud.debian.org: Debian docker images pointing to github for bug tracking
[removing serpent@d.o from CC, he's resigned as delegate] Hi Lucas, On Sun, Jun 28, 2020 at 05:26:41PM +0200, Lucas Nussbaum wrote: > One could argue that the Cloud team delegation does not cover Docker > images. Whether it does or not, I've been told that the docker image maintainers prefer to keep their current organization and workflow. I'd welcome their participation in the team, if they were interested. But I don't think they need to be. > But I think that it would be a nice addition to change the delegation to > also include official images for virtualization environments such as > Docker, LXC, Vagrant, as well as official images for SBC such as the > Raspberry Pi (where it's often more convenient to boot a pre-built image > than use the Debian installer). Maybe it could be nice, if the people building those images want to use our tools and work with us. Some would raise concerns in my mind, but I don't think it's useful to discuss before someone wants to build e.g. raspberry pi images in cloud-team. But it's also nice for people to provide images without us, or using different tools. The delegation only covers Debian-official cloud images. And speaking for myself: I don't feel the need to gather all other cloud-related or image-related work under a this team. Ross
Bug#963906: ITP: ruby-aubio -- Ruby bindings for the aubio audio library
Package: wnpp Severity: wishlist Owner: Valentin Vidic * Package name: ruby-aubio Version : 0.3.3 Upstream Author : Xavier Riley * URL : https://github.com/xavriley/ruby-aubio * License : MIT Programming Lang: Ruby Description : Ruby bindings for the aubio audio library Aubio is a tool designed for the extraction of annotations from audio signals. Its features include segmenting a sound file before each of its attacks, performing pitch detection, tapping the beat and producing midi streams from live audio. This library is required as a dependency for the new version of the sonic-pi package. The package will be maintained in the ruby-team group on Salsa.
Re: isc-dhcp-client sends DHCPDISCOVER *before* wpa_supplicant authenticates/associates/connects.
On Sun, 28 Jun 2020 at 12:06:02 +0100, Jaime wrote: > I noticed that my debian wireless clients never get a DHCPOFFER from > their first DHCPDISCOVER ... > So it's clear that dhclient is sending out the first DHCPDISCOVER > *before* wpa_supplicant has authenticated/associated/connected to the > AP. This is a property of whatever larger network management component you are using that controls wpasupplicant and dhclient, which might be NetworkManager, wicd, ifupdown, systemd-networkd (maybe? I'm not sure whether it has wpasupplicant integration), your own code (shell scripts or something), or something else. If you think that component (whatever it is) is doing the wrong thing, please report a bug in it or talk to its maintainers. Debian does not require a specific network management component, although some configurations of Debian have a default (for example, the GNOME desktop recommends NetworkManager and works best with that). Typically people use NetworkManager or wicd on portable devices, systemd-networkd or ifupdown on servers, and either of those on desktops/workstations. smcv
Bug#925530: cloud.debian.org: Debian docker images pointing to github for bug tracking
On Sun, Jun 28, 2020 at 05:26:41PM +0200, Lucas Nussbaum wrote: > > On https://hub.docker.com/_/debian, there's: > > > > > Where to file issues: > > > https://github.com/debuerreotype/docker-debian-artifacts/issues > > This hasn't changed. The Debian official images still point to github > for bug tracking. I would expect the BTS to be used for bug tracking > (and salsa for maintaining the generation tools) Not wanting to speak for paultag or tianon, but I don't think the intent has ever been to present these as "Debian's official images for Docker." In fact, the language used is "Docker Official Images". These are "Docker's official Debian images". The difference may be subtle, but is significant. > One could argue that the Cloud team delegation does not cover Docker > images. The delegation says: > > > With the Debian Trademark Team, establish policies and procedures > > for the Debian Cloud Team regarding "Official Debian Cloud > > Images" for both open and proprietary platforms. > > The current version of those policies is, AFAIK, > https://wiki.debian.org/Teams/DPL/OfficialImages > > But I think that it would be a nice addition to change the delegation to > also include official images for virtualization environments such as > Docker, LXC, Vagrant, as well as official images for SBC such as the > Raspberry Pi (where it's often more convenient to boot a pre-built image > than use the Debian installer). This proposal increasingly diverges from any common definition of "cloud". noah signature.asc Description: PGP signature
Bug#963891: O: ifupdown -- high level tools to configure network interfaces
Package: wnpp Severity: normal I intend to orphan the ifupdown package. I no longer have time to work on this package. If you are interested in taking over this package, please make it team-maintained. ifupdown is Debian's own native network configuration tool, and is more than 20 years old. A core principle of ifupdown is that it runs only when an interface is brought up or down; there is no daemon running in the background that can react to eventsr, although are udev hooks so that ifupdown is run whenever an interface is being created by the kernel. ifupdown also offloads a lot of work to its own hook scripts, and to daemons it starts (such as DHCP client daemons and wpa_supplicant). Despite all this, it can manage quite complex network setups, with only a very minimal binary (88 kB on amd64), making it interesting for low-resource environments. The package description is: This package provides the tools ifup and ifdown which may be used to configure (or, respectively, deconfigure) network interfaces based on interface definitions in the file /etc/network/interfaces.
Bug#963901: O: glm -- C++ library for OpenGL GLSL type-based mathematics
Package: wnpp Severity: normal I intend to orphan the glm package. I no longer have time to maintain this package. GLM is used by quite a lot of applications that render 3D graphics using OpenGL and Vulkan, and might be used outside that as well due to its excellent implementation of vector and matrix operations of up to 4(x4) components. Since it is a header-only library, there only are build-dependencies, which means its use isn't reflected by the popcon statistics. This package is in very good shape with no open bugs, in great part due to upstream being very responsive to bug reports that are forwarded to them. The package description is: OpenGL Mathematics (GLM) is a header only C++ mathematics library for graphics software based on the OpenGL Shading Language (GLSL) specification. . GLM provides classes and functions designed and implemented with the same naming conventions and functionalities as GLSL, so that when a programmer knows GLSL, he knows GLM as well, which makes it really easy to use. . This project isn't limited to GLSL features. An extension system, based on the GLSL extension conventions, provides extended capabilities: matrix transformations, quaternions, half-based types, random numbers, et cetera. . This library works perfectly together with OpenGL but it also ensures interoperability with other third party libraries and SDKs. It is a good candidate for software rendering (such as raytracing, rasterisation), image processing, physic simulations and any context that requires a simple and convenient mathematics library.
Re: NMU for Imagemagick?
Jonathan Carter schrieb: > Hi > > Imagemagick in Debian is extremely outdated (6.9.10.23 vs 7.0.10-21), > causing some FTBFS on packages that depend on it. > > I know this package is notorious for needing security updates, and not > sure if there might be a good reason for it to be stuck on it's current > version, so any objection if I look into making an NMU upload for this > package? It doesn't need a one time NMU, but an additional 1-3 active maintainers. Failing that, we should rather drop it for bullseye. Cheers, Moritz
Bug#925530: cloud.debian.org: Debian docker images pointing to github for bug tracking
[Note: re-sending to the correct bug address... ] (Cced: docker images maintainers ; cloud team delegates) Hi, As this was reassigned to 'general', it's probably time to do a status update. First, I would like to acknowledge the work done by those maintaining those images, and thank them for that. However ... On 26/03/19 at 12:25 +0100, Lucas Nussbaum wrote: > On https://hub.docker.com/_/debian, there's: > > > Where to file issues: > > https://github.com/debuerreotype/docker-debian-artifacts/issues This hasn't changed. The Debian official images still point to github for bug tracking. I would expect the BTS to be used for bug tracking (and salsa for maintaining the generation tools) One could argue that the Cloud team delegation does not cover Docker images. The delegation says: > With the Debian Trademark Team, establish policies and procedures > for the Debian Cloud Team regarding "Official Debian Cloud > Images" for both open and proprietary platforms. The current version of those policies is, AFAIK, https://wiki.debian.org/Teams/DPL/OfficialImages But I think that it would be a nice addition to change the delegation to also include official images for virtualization environments such as Docker, LXC, Vagrant, as well as official images for SBC such as the Raspberry Pi (where it's often more convenient to boot a pre-built image than use the Debian installer). Lucas
Re: DEP-14: renaming master to main?
Hello! Just my 2 cents: I hope Debian would not rush to any changes here. Lets just stay neutral for now. The subject seems very US-centric and there is a risk that it is creating division among people forcing them to take sides on issues that previously were not political at all. Here is some background of what philosophical meaning the term had in git: https://public-inbox.org/git/20200618152300.cw7teo2jmxyfsl2l@chatter.i7.local/ > This is actually an important philosophical point with software like > git. There is no such thing as master.kernel.org for the very specific > reason that we position kernel.org to be merely a convenient place where > to get a *copy* of Linux. The "master copy" of the mainline tree exists > only in one place -- on Linus's computer. Let's wait and see if upstream Git changes the default, then others will naturally follow next time they run 'git init'. So far upstream git has removed a couple of mentions of slavs: - https://github.com/git/git/commit/f33b5bddaf7ac1535c6c37fde168597e252872b3 - https://github.com/git/git/commit/08dc26061f3ff9ee79e6cfda88f0c825b8730e54 Python had a similar discussion in 2018 and they concluded that the term 'master' does not have any political undertone when used in git master, postmaster or hostmaster: https://bugs.python.org/issue34605
Re: debdocker - A Debian docker-based personal builder
Hi everybody I can field any questions on DUE to save people having to spend time on researching differences - I've summarized some of them for reference below to provide some context about DUE's scope as a build tool, and to assist in comparing potential options. I can see some functional overlap here, but haven't done a deep dive yet. I'd expect I'll be answering questions similar to Samo's - but probably in a different thread as I don't want to hijack the focus of this one. *TL:DR* - I don't see DUE replacing existing build tools. - Debian packages are an important subset of what DUE can build, but its scope is to make non-Debianized builds easy as well. - I expect its user base would be developers looking for easy deployment of different build environments. - Interesting parallel evolution in the common features of the existing Docker build tools. - Ideally, any software project with a complicated build environment has a DUE template to create that in a container, lowering the bar for project participation. *L* Having quickly looked at debdocker and the other docker based build tools I'm struck by the areas of noticeable functional overlap between all of the tools, indicating that there's an unmet need there. The authors of Debspawn in particular seem to be thinking along the same lines as I am. However, two years ago when I'd started working on what would become DUE I'd had no luck finding build tools that did the sort of things that I was looking for , although as a build tools engineer for a Debian derivative my requirements include a lot of what would be considered edge cases. While DUE makes building packages easy I don't see it replacing the tools that are already used, like sbuild and pbuilder So - what does it bring to the party, then? A number of things, but I'll focus on what, as a developer, I think are the two biggest "value adds" *1 - Convenient Builds, regardless of project (as long as it can build in Debian)* It tries to bring the convenience of building Debian packages - apt get source - install dependencies - build - done! ...to code that isn't Debianized by supporting preconfigured build environments for those programs. - Use it to build the desired container ( pick the Debian version, architecture, and build environment configuration to use via --help ) - check out source, - build source with container (it'll handle the dependencies, etc ) - done! So while Debian packages are an incredibly useful subset of what it can build, they're only one of several (as of now) supported build environments. As an example of non-Debianized code, Open Network Install Environment* ( https://github.com/opencomputeproject/onie) is basically a bootloader for network switches, but currently it just builds in Stretch and has a bunch of build dependencies, and one of them has to be pulled out of GitHub. A template directory in DUE handles all the environmental configuration so everybody working on the project can have identical build environments, regardless of where they are. Anybody curious about the project can try it out with DUE in three steps, and easily toss it if they have no interest. If DUE gets accepted into Debian, I'd hope for a use case where developers for any open source project could provide a DUE compatible template to generate their build environments, and host that along with code so that anybody who wanted to work on their project would apt install DUE, drop the template in, then build the image and be ready to go...but I'm getting ahead of myself here. *2 - Comfortable debug* Trying to debug software from the inside of a typical Docker container is irritating for a number of reasons, but they boil down to: you don't have access to everything you'd like. You're root or some other account. None of your configuration files are around. Files have to be copied in/out of the container to preserve changes if modified: everything is difficult because there's an extra step involved. With DUE any Docker image it creates gets a set of utilities embedded in it, providing convenience (like creating an account in the container that matches the user's on the host system, mounting their home directory for access to config files in addition to source , etc. ) creating a much more comfortable environment for extended debugging/development, etc. I know these sound like small things, and they are...but they get incredibly irritating over time, and having them 'just handled' for any build is _really_ nice. There's more here, but the above pretty much covers the role I think DUE would be playing - and all of that goes beyond the scope of this thread. Thanks! -Alex *Disclosure, I'm the ONIE project lead so I've got the most to gain by lowering the bar for participation. On Sun, Jun 28, 2020 at 3:06 AM Samo Pogačnik wrote: > On Sun, 28 Jun 2020 09:27:09 +0200, Geert Stappers wrote: > > On Sun, Jun 28, 2020 at 08:29:22AM +0
Re: isc-dhcp-client sends DHCPDISCOVER *before* wpa_supplicant authenticates/associates/connects.
On Sun, 28 Jun 2020, Jaime wrote: Given that this is guaranteed to fail, isn't it worth "not doing"? Is there anyway that I can get dhclient to wait for a successful connection *before* sending out any DHCPDISCOVERs? (In the wired world, it doesn't make sense to issue a DHCPDISCOVER before plugging the cable in.) NetworkManager should be at least one such way. When the funciton supplicant_iface_state_cb is called with state NM_SUPPLICANT_INTERFACE_STATE_COMPLETED it will call nm_device_activate_schedule_stage3_ip_config_start that will end up starting dhclient only when wpa_supplicant has done its job. At least last time I tried using ifupdown for wifi I hit all sorts of odd race conditions that probably still exist: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587634
Bug#963874: ITP: ruby-rubame -- simple Ruby websocket game server
Package: wnpp Severity: wishlist Owner: Valentin Vidic * Package name: ruby-rubame Version : 0.0.2 Upstream Author : Mark Saward * URL : https://github.com/saward/Rubame * License : MIT Programming Lang: Ruby Description : simple Ruby websocket game server Rubame makes use of WebSocket Ruby to handle the websocket protocol and the standard Ruby sockets libraries for the actual network connections. This library is required as a dependency for the new version of the sonic-pi package. The package will be maintained in the ruby-team group on Salsa.
Re: NMU for Imagemagick?
On Sat, Jun 27, 2020 at 02:51:32PM +0200, Jonathan Carter wrote: > so any objection if I look into making an NMU upload for this > package? You are asking here, but you didn't report on whether you tried to contact: 1) the maintainer (and here I'm referring to Bastien Roucariès) 2) the security team before trying to write to d-d@… -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
isc-dhcp-client sends DHCPDISCOVER *before* wpa_supplicant authenticates/associates/connects.
Hi all. I noticed that my debian wireless clients never get a DHCPOFFER from their first DHCPDISCOVER, and looking at the log shows why: journalctl output (very much shortened/redacted): 09:34:30 sudo[4373]: COMMAND=/usr/sbin/ifup wlp4s0 09:34:30 wpa_supplicant[4384]: Successfully initialized wpa_supplicant 09:34:30 dhclient[4395]: Internet Systems Consortium DHCP Client 4.4.1 09:34:30 dhclient[4395]: Copyright 2004-2018 Internet Systems Consortium. 09:34:30 dhclient[4395]: All rights reserved. 09:34:30 dhclient[4395]: For info, please visit https://www.isc.org/... 09:34:30 dhclient[4395]: 09:34:30 dhclient[4395]: Listening on LPF/wlp4s0/ab:cd:ab:cd:ab:cd 09:34:30 dhclient[4395]: Sending on LPF/wlp4s0/ab:cd:ab:cd:ab:cd 09:34:30 dhclient[4395]: Sending on Socket/fallback 09:34:30 dhclient[4395]: DHCPDISCOVER on wlp4s0 to 255.255.255.255... 09:34:31 kernel: wlp4s0: authenticate with 12:34:12:34:12:34 09:34:31 wpa_supplicant[4385]: wlp4s0: SME: Trying to authenticate... 09:34:31 kernel: wlp4s0: send auth to 12:34:12:34:12:34 (try 1/3) 09:34:31 kernel: wlp4s0: authenticated 09:34:31 wpa_supplicant[4385]: wlp4s0: Trying to associate with ... 09:34:31 kernel: wlp4s0: associate with 12:34:12:34:12:34 (try 1/3) 09:34:31 kernel: wlp4s0: RX AssocResp from 12:34:12:34:12:34... 09:34:31 kernel: wlp4s0: associated 09:34:31 wpa_supplicant[4385]: wlp4s0: Associated with 12:34:12:34:12:34 09:34:31 wpa_supplicant[4385]: wlp4s0: CTRL-EVENT-SUBNET-STATUS-UPDATE... 09:34:31 wpa_supplicant[4385]: wlp4s0: WPA: Key negotiation completed... 09:34:31 wpa_supplicant[4385]: wlp4s0: CTRL-EVENT-CONNECTED... 09:34:34 dhclient[4395]: DHCPDISCOVER on wlp4s0 to 255.255.255.255... 09:34:34 dhclient[4395]: DHCPOFFER of 192.168.0.6 from 192.168.0.1 09:34:34 dhclient[4395]: DHCPREQUEST for 192.168.0.6 on wlp4s0... 09:34:34 dhclient[4395]: DHCPACK of 192.168.0.6 from 192.168.0.1 So it's clear that dhclient is sending out the first DHCPDISCOVER *before* wpa_supplicant has authenticated/associated/connected to the AP. Given that this is guaranteed to fail, isn't it worth "not doing"? Is there anyway that I can get dhclient to wait for a successful connection *before* sending out any DHCPDISCOVERs? (In the wired world, it doesn't make sense to issue a DHCPDISCOVER before plugging the cable in.) (FWIW, I sent this same question to debian-user 18 months ago, but I didn't get anywhere so I thought I'd try again here). TIA, Jaime
Re: debdocker - A Debian docker-based personal builder
On Sun, 28 Jun 2020 09:27:09 +0200, Geert Stappers wrote: > On Sun, Jun 28, 2020 at 08:29:22AM +0300, Tzafrir Cohen wrote: > > On 27/06/2020 14:52, Mo Zhou wrote: > > > Hi Samo, > > > > > > I'm insterested in its differences compared to the following existing > > > docker-based builders: > > > > > > > 1. debocker https://people.debian.org/~tomasz/debocker.html > > > 2. whalebuilder https://www.uhoreg.ca/programming/debian/whalebuilder > > > > > > And there is a systemd-nspawn-based builder too: > > > 3. debspawn https://github.com/lkorigin/debspawn > > > > There is also the recent ITP of due: > > https://bugs.debian.org/961371 > > that is a docker builder (Debian packages, or more generic) > > > > Qouting that Intent To Package, ITP: > > * Package name: due > Programming Lang: Bash > Description : Wrapper tool to create and run Docker container > software build environments. > > Dedicated User Environment (DUE) is a framework for creating preconfigured > build/development > environments in Docker containers. It serves two primary purposes: > > 1 - Maintains configurations for creating Docker images for any build > environment, using > any architecture of any Debian based release it can find an image for. > For example, the Open Network Install Environment > ( https://github.com/opencomputeproject/onie) > currently builds on Debian 8 and 9, but requires some Backports packages, > and a program that > isn't packaged for Debian. DUE maintains a configuration to get all of that > added when the > Docker image is created so ONIE can 'just build'. Apart from not requiring > the end user to > have to configure the build environment, it also allows all developers to use > the same build > environment when debugging - regardless of where they happen to be. > > 2 - It goes beyond 'just using a Dockerfile' by using a launcher application > that supplies > runtime configuration to Docker for the Docker images it has created. Apart > from reducing > typing and being smart about the containers that it runs (ex: containers > building Debian > packages mount the host directory _above_ the build directory so the resulting > .debs aren't > stored in the container), DUE preserves the user's identity in the container > by creating an account > for them with their user ID, and mounting their home directory so they can > access their .config files. > This creates a less intrusive development environment when the user is in a > build/test/debug > cycle. > > While the above are the most important features DUE provides, there are a lot > more ways > it makes using different development configurations easier, which are > documented in > the Readme.md (https://github.com/CumulusNetworks/DUE/blob/master/README.md) > > The ITP for 'due' expresses exactly my sentiments in the Q&A section question, if there are other packages providing similar functionality. 'debdocker' is simply my modest result of that sentiment and i see no harm offering it to others. regards, Samo
Re: debdocker - A Debian docker-based personal builder
On Sun, Jun 28, 2020 at 08:29:22AM +0300, Tzafrir Cohen wrote: > On 27/06/2020 14:52, Mo Zhou wrote: > > Hi Samo, > > > > I'm insterested in its differences compared to the following existing > > docker-based builders: > > > > 1. debocker https://people.debian.org/~tomasz/debocker.html > > 2. whalebuilder https://www.uhoreg.ca/programming/debian/whalebuilder > > > > And there is a systemd-nspawn-based builder too: > > 3. debspawn https://github.com/lkorigin/debspawn > > There is also the recent ITP of due: > https://bugs.debian.org/961371 > that is a docker builder (Debian packages, or more generic) > Qouting that Intent To Package, ITP: * Package name: due Programming Lang: Bash Description : Wrapper tool to create and run Docker container software build environments. Dedicated User Environment (DUE) is a framework for creating preconfigured build/development environments in Docker containers. It serves two primary purposes: 1 - Maintains configurations for creating Docker images for any build environment, using any architecture of any Debian based release it can find an image for. For example, the Open Network Install Environment (https://github.com/opencomputeproject/onie) currently builds on Debian 8 and 9, but requires some Backports packages, and a program that isn't packaged for Debian. DUE maintains a configuration to get all of that added when the Docker image is created so ONIE can 'just build'. Apart from not requiring the end user to have to configure the build environment, it also allows all developers to use the same build environment when debugging - regardless of where they happen to be. 2 - It goes beyond 'just using a Dockerfile' by using a launcher application that supplies runtime configuration to Docker for the Docker images it has created. Apart from reducing typing and being smart about the containers that it runs (ex: containers building Debian packages mount the host directory _above_ the build directory so the resulting .debs aren't stored in the container), DUE preserves the user's identity in the container by creating an account for them with their user ID, and mounting their home directory so they can access their .config files. This creates a less intrusive development environment when the user is in a build/test/debug cycle. While the above are the most important features DUE provides, there are a lot more ways it makes using different development configurations easier, which are documented in the Readme.md (https://github.com/CumulusNetworks/DUE/blob/master/README.md) Regards Geert Stappers -- Silence is hard to parse
