Re: Standardizing the layout of git packaging repositories
I would like to point out some considerations. A winning approach for me is: * don't assume that if I maintain packages in git, upstream is also developing using git. * don't assume that upstream is making releases. Maybe they don't make tarballs, even tags. Maybe they do, but they are very wrong (for example, bad versioning). * don't assume tarballs contains exactly the same as the git repo source. * don't try to have a standard to fit all upstream projects and/or DDs likes. Having a way to generate the upstream tarball in the own pkg git repo is a nice way to speed the packaging workflow. I guess the DEP can include the pristine-tar case and others as well, for example using git archive. This seems the weakest point at the moment. I think some of the key points in the standarization is about the style and good practices, for example: * commit messages with single line title + full description. No more than 80 characters per line. * signed-off-by lines and friends in commit messages, as in the Linux Kernel. * package should be able to build between commits. This is, the repo remains in a consistent state from commit to commit. * tagging layout. * when and how to update the changelog, using git-dch, etc.. IMHO, if Debian can provide a good standard (at least regarding style and good practices), we are all winning. regards. -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOkSjBjyMJj7r5X4LVWR=jbPtfQzww2e=6pgd2hdv1ljexz...@mail.gmail.com
Bug#677415: ITP: clustersync -- Tool for replicating and syncing config files
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: clustersync Version : 0.4 Upstream Author : Arturo Borrero Gonzalez * URL : https://github.com/aborero/clustersync * License : GPL Programming Lang: Bash Description : Tool for replicating and syncing config files This is a tool based on Rsync that helps syncing and replicating config files and other data between nodes of a cluster, where you expect to have the same configuration in several machines. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120613202713.6321.58686.reportbug@nostromo
Bug#726978: ITP: libgit2 -- The git linkable library
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: libgit2 Version : 0.19.0 Upstream Author : The libgit2 contributors * URL : http://libgit2.github.com/ * License : GPL2 Programming Lang: C Description : The git linkable library libgit2 is a portable, pure C implementation of the Git core methods provided as a re-entrant linkable library with a solid API, allowing you to write native speed custom Git applications in any language with bindings. libgit2 is already very usable and is being used in production for many applications including the GitHub.com site. The library provides: * SHA conversions, formatting and shortening * abstracted ODB backend system * commit, tag, tree and blob parsing, editing, and write-back * tree traversal * revision walking * index file (staging area) manipulation * reference management (including packed references) * config file management * high level repository management * thread safety and reentrancy * descriptive and detailed error messages * ...and more (over 175 different API calls) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131021074955.4276.86757.report...@r2d2.cica.es
Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)
On 22 October 2013 15:43, Ondřej Surý wrote: > Hi, > > there are now couple of quality DNS servers and most of their > maintainers have agreed that it might be useful to have a virtual > package that we can add to Provides: so it's easy to pick one DNS server > if one needs it. > > The proposed names are: > > authoritative-name-server - authoritative domain name server > recursive-name-server - recursive domain name server > I think is a good idea. Some packages may suggest using a caching name server (thats my case). I would suggest: caching-name-server -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOkSjBgEtawuahomt+k9dnd_q2yvqjmyobrgcs-yxreh...@mail.gmail.com
Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)
On 22 October 2013 20:16, Octavio Alvarez wrote: > On 22/10/13 09:18, Arturo Borrero Gonzalez wrote: >> >> I would suggest: caching-name-server > > > *-dns-server would be better, as it is specific enough to avoid name > collision in the future. Good point. Thanks. -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOkSjBifXZZasbJ07jEqCuDQC3LCFPBjX=QcscKYUj_=r+t...@mail.gmail.com
Re: Debian HA team MIA?
On 6 November 2013 17:22, Michael Meskes wrote: > > I was just pointed to > http://qa.debian.org/developer.php?login=debian-ha-maintain...@lists.alioth.debian.org > and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714210 both of which > bring > up the question whether the team still exists and is actively working on the > packages. If new manpower is needed in the team I'm ready :) Let me know. -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caoksjbja+ycremyiusexoqjo-khhk3prip-4nue-qxewgo3...@mail.gmail.com
Bug#703318: ITP: fw-admin -- Dual stack firewall
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: fw-admin Version : 1.0 Upstream Author : Arturo Borrero Gonzalez * URL : https://github.com/aborrero/fw-admin * License : GPL-3 Programming Lang: bash Description : Dual stack firewall Dual Stack (IPv4 and IPv6) firewall. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130318125448.8986.6476.report...@r2d2.cica.es
Bug#704510: ITP: nfacct -- command line tool to create/retrieve/delete netfilter accounting objects
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: nfacct Version : 1.0.1 Upstream Author : Pablo Neira Ayuso - Netfilter * URL : http://netfilter.org/projects/nfacct/ * License : GPL Programming Lang: C Description : command line tool to create/retrieve/delete netfilter accounting objects Dear Debian comunity: I would like to package and mantain nfacct. Main Features * listing the objects of the nfacct table in plain text/XML * atomically get and reset objects of the nfacct table * adding new objects to the nfacct table * deleting objects from the nfacct table nfacct requires libnetfilter_acct, libmnl and a kernel that features the nfnetlink_acct subsystem. For officially released kernels, this means 3.3. This is interesting for the Debian server land, allowing us to combine with ulogd to achieve such things: https://home.regit.org/2012/12/visualize-netfilter-accounting-in-graphite/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402081233.4677.41696.report...@r2d2.cica.es
Bug#704518: ITP: libnetfilter-acct -- Netfilter userspace library for accouting infrastructure
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: libnetfilter-acct Version : 1.0.2 Upstream Author : Pablo Neira Ayuso * URL : http://netfilter.org/projects/libnetfilter_acct/index.html * License : GPL Programming Lang: C Description : Netfilter userspace library for accouting infrastructure libnetfilter_acct is the userspace library providing interface to extended accounting infrastructure, used by nfacct. Main Features * creating accounting objects * retrieving accounting objects (and atomically set to zero) * deleting accounting objects For the nfnetlink_acct subsystem. libnetfilter_acct requires libmnl and a kernel that includes the nfnetlink_acct subsystem (i.e. 3.3 or later). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402091438.6478.18609.report...@r2d2.cica.es
Bug#708096: ITP: libiptables-nftables -- Compatibility layer of iptables over nftables
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: libiptables-nftables Version : 1.0.0 Upstream Author : Pablo Neira Ayuso * URL : http://git.netfilter.org/iptables-nftables/ * License : GPL 2 Programming Lang: C Description : Compatibility layer of iptables over nftables This library allows you to run standar iptables/ip6tables over nftables kernel infrastructure, avoiding breaking iptables rulesets and firewall scripts. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130513075659.4531.43979.report...@r2d2.cica.es
Bug#708102: ITP: libnftables -- userspace library used by nftables
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: libnftables Version : 1.0 Upstream Author : Pablo Neira Ayuso * URL : http://git.netfilter.org/libnftables/ * License : GPL2 Programming Lang: C Description : userspace library used by nftables libnftables is a library to interact with nftables kernel subsystem. For comunicating with kernel, it uses libmnl (Netlink). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130513074047.4452.23717.report...@r2d2.cica.es
Re: Bug#730180: ITP: teampass -- WEB based password manager
On 22 November 2013 10:55, Carlos Alvarez wrote: > Package: wnpp > Severity: wishlist > Owner: Carlos Alvarez > > * Package name: teampass > Version : 2.2.0 > Upstream Author : Nils Laumaillé > * URL : http://www.teampass.net > * License : GNU AFFERO GPL3 > Programming Lang: PHP, JavaScript > Description : WEB based password manager Good to know about this, teampass is a handy tool. Thanks for your effort. Let me know if you need some help. I can't sponsor you, but can give some advices about the packaging. regards. -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOkSjBi0oC+=TLAec7ji=tp+v4k2w3uhpltkytb9a_h+yyr...@mail.gmail.com
Bug#736146: ITP: libnftnl -- nftables low-level userspace library
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: libnftnl Version : 0.1 Upstream Author : Pablo Neira Ayuso * URL : http://www.netfilter.org * License : GPL-2+ Programming Lang: C Description : nftables low-level userspace library libnftables was renamed upstream to libnftnl. Previous ITP of libnftables: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708102 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140120100145.5170.41346.report...@r2d2.cica.es
Bug#737602: ITP: rpmlint -- RPM package checker
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: rpmlint Version : 1.5 Upstream Author : Ville Skyttä * URL : http://sourceforge.net/p/rpmlint/ * License : GPL-2 Programming Lang: Python Description : RPM package checker rpmlint is a tool for checking common errors in rpm packages. rpmlint can be used to test individual packages before uploading or to check an entire distribution. By default all applicable checks are performed but specific checks can be performed by using command line parameters. rpmlint can check binary rpms (files and installed ones), source rpms, and plain specfiles, but all checks do not apply to all argument types. For best check coverage, run rpmlint on source rpms instead of plain specfiles, and installed binary rpms instead of uninstalled binary rpm files. The idea for rpmlint is from the lintian tool of the Debian project. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140204082722.4209.17045.report...@r2d2.cica.es
Bug#742110: ITP: gestioip -- Web-based IP address management software
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: gestioip Version : 3.0 Upstream Author : Marc Uebel * URL : http://www.gestioip.net * License : GPL-3 Programming Lang: Perl Description : Web-based IP address management software GestioIP is an automated, web based IPv4/IPv6 address management (IPAM) software. It features powerful network discovery functions and offers search and filter functions for both networks and host, permitting Internet Search Engine equivalent expressions. This lets you find the information that administrators frequently need easily and quickly. GestioIP also incorporates an automated VLAN management system. Visit www.gestioip.net for more information. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140319100948.21028.88343.report...@r2d2.cica.es
Re: Why Debian
On 12 April 2014 18:16, Alberto Salvia Novella wrote: > Why you choose to develop in Debian over any other distribution? > For me, Debian is the best distro. That's my main reason. Also: * I use Debian for all (from netbooks, laptops, desktop, to high-demand servers). * There is a big community. * The technical level is high. Is challenging. I want to keep that and I want to contribute and be a part of it. * Debian project as a FLOSS project is serious. I like important things to be serious and meticulous. * I like the 'Debian style' and policy. Many aspects: FHS, packages management, etc.. * Here, there are some great hackers I want to learn from. * There isn't one big company making decision based on 'the market'. I'm neither DD nor DM, but I do develop. -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOkSjBjJZSdVePdL-d+QtujkFEC8DfE3xui+o=txlp+lh5b...@mail.gmail.com
Bug#747297: ITP: neopi -- web shell code detection
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: neopi Version : 0.1 Upstream Author : Ben Hagen * URL : https://github.com/Neohapsis/NeoPI * License : GPL-3 Programming Lang: Python Description : web shell code detection NeoPI is a Python script that uses a variety of statistical methods to detect obfuscated and encrypted content within text/script files. The intended purpose of NeoPI is to aid in the detection of hidden web shell code. The development focus of NeoPI was creating a tool that could be used in conjunction with other established detection methods such as Linux Malware Detect or traditional signature/keyword based searches. NeoPI recursively scans through the file system from a base directory and will rank files based on the results of a number of tests. It also presents a “general” score derived from file rankings within the individual tests. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140507083425.13866.97054.report...@r2d2.cica.es
Re: Nftables in jessie?
On 8 May 2014 19:16, Frank Bauer wrote: > Hi, > > Jessie currently contains linux 3.13, which includes the successor of > iptables - nftables. > Unfortunately, the userspace tools (nftables) are still missing even in > sid/experimental. > As Vincent Bernat said, is in NEW. Has been in NEW for a month or so. > Is there a general plan to support nftables in jessie? As the release > managers reminded > us recently, the freeze will be here in no time. I believe it is essential > for users to be able > to test this new technology in jessie before fully switching to it in > jessie+1. > Unfortunately, there isn't a 'general plan'. I mean, the package will be uploaded and maintained. But no talk happened about what means having nftables in Debian. I think the following points may be interesting: * in which state/shape is the nftables framework? * what about the iptables and the compat layer? The next upstream release of iptables will, by default, use the nf_tables kernel subsystem. * what about a standard firewall service (like other distros do). iptables also lacks of it. * Some bugs happened in the Debian kernel package, and the kernel currently in Jessie comes without nf_tables enabled [0]. Thanks for your interest Frank. I would like to hear suggestions, comments and ideas. regards. [0] #742763 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742763 -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caoksjbiaqgbrxkxswg0_ky3+iorg-4r3op69joav2jzrhop...@mail.gmail.com
Re: systemd-fsck?
On 9 May 2014 18:22, Russ Allbery wrote: > > I think we need some sort of critical debconf prompt here for the jessie > release, [...] I fully agree with this. regards. -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caoksjbhtvvtw85b3pkihsna-mn7dcl8e4k3c+stmcjdrom6...@mail.gmail.com
Re: systemd-fsck?
On 9 May 2014 19:42, Svante Signell wrote: > On Fri, 2014-05-09 at 19:04 +0200, Arturo Borrero Gonzalez wrote: >> On 9 May 2014 18:22, Russ Allbery wrote: >> > >> > I think we need some sort of critical debconf prompt here for the jessie >> > release, [...] >> >> I fully agree with this. > > bug #747535 > Thanks Svante. I will keep and eye on the bug. regards. -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOkSjBhfz81hR3DmoOinPGxC-QP5AKgVrMoT4qTv+3G1x�3...@mail.gmail.com
Re: Nftables in jessie?
On 12 May 2014 14:56, Ben Hutchings wrote: >> >> I think the following points may be interesting: >> * in which state/shape is the nftables framework? >> * what about the iptables and the compat layer? The next upstream >> release of iptables will, by default, use the nf_tables kernel >> subsystem. > > What about it? Is there a problem? > No, just pointing it out. >> * what about a standard firewall service (like other distros do). >> iptables also lacks of it. > > I think there should be a standard host firewall that supports simple > high-level configuration and is installed by default (whether it blocks > anything would have to be a debconf question). > I think there is no an easy (direct) choice. The nftables syntax is kind of higher level than iptables. Readable keywords vs classic switches. > For firewall routers, I don't think we need to pick a default. > >> * Some bugs happened in the Debian kernel package, and the kernel >> currently in Jessie comes without nf_tables enabled [0]. > [...] > > Well it's fixed in unstable and will be fixed in jessie RSN. > Ok, thanks. -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOkSjBjO+XcmF_d2xHt=8jhar4s6z2hjwwsq1c1hpnfysso...@mail.gmail.com
Re: Nftables in jessie?
On 8 May 2014 19:16, Frank Bauer wrote: > Unfortunately, the userspace tools (nftables) are still missing even in > sid/experimental. Just to let you know: nftables is now on Debian [0]. Comments are welcome :) [0] http://packages.qa.debian.org/n/nftables.html -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caoksjbir+zdhmowpe2l7apofsduut1exjyx1734shdtsmcw...@mail.gmail.com
Re: Nftables in jessie?
On 25 May 2014 14:15, Frank Bauer wrote: [...] > There should be some simple guide in the manpage or README.Debian > regarding the extra setup of the logging subsystem. > Upstream knows the issue and plan to fix it soon. The next upstream release may happen in a couple of weeks. > As there are some config examples in /etc/nftables, I would appreciate > to have subdirectories conf-available and conf-enabled (like Lighttpd > or Apache) and a systemd unit to load these at boot time. > Well, this is good for a future roadmap, when we start thinking of nftables replacing iptables. This is not the moment yet, IMHO. thanks for your comments! best regards. -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOkSjBiNQ3C1B4e1mB6O4Py_r2fziaZVF=zr-1mqpjth0a7...@mail.gmail.com
enforced systemd services (was: Misc Developer News (#37))
On 25 November 2014 at 02:22, Paul Wise wrote: > > Making packages secure with systemd service files > - > > Packagers of Debian software, who are needing to create systemd service > files would benefit from learning from Lennart Poettering's recent > presentation (video[12], slides[13]) detailing various security features you > can enable in your package's service files. Many of these features are > simple to add, and would greatly enhance the overall security of Debian. > > -- Joe Hill > > [12] > http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm > [13] http://0pointer.net/public/systemd-nluug-2014.pdf > This seems pretty interesting. Is there a Debian-specific policy on how to apply these directives? -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caoksjbifytdnatwsaxu+ss-_cgbr+og5hwfoc0pphgmmcp8...@mail.gmail.com
Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range
On 9 December 2014 at 19:12, Anthony F McInerney wrote: > Those have been the fixes for the usual networking problems that have > crept up in jessie. > I concur with Henrique Holschuh's advice, fix the address range. > I think in some environments changing the addressing layout is not that simple. @Maciej, could you post all the network-related config of your failing machine? I mean: routing, addresses, firewalling, sysctl, IPv6 and all. Also, I see your kernel is 3.17.4MK. Is a custom kernel? -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caoksjbhognf-wezwmdwo4e5gxf0cp7g3hbt+itu148xgu6p...@mail.gmail.com
Bug#784643: ITP: liquidprompt -- adaptative prompt for bash & zsh
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: liquidprompt Version : 1.9 Upstream Author : Nojhan * URL : https://github.com/nojhan/liquidprompt * License : AGPL-3 Programming Lang: shell Description : adaptative prompt for bash & zsh Liquid Prompt gives you a nicely displayed prompt with useful information when you need it. It shows you what you need when you need it. You will notice what changes when it changes, saving time and frustration. You can even use it with your favorite shell – bash or zsh. I would require sponsor for this package. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150507121638.3911.67305.report...@deathstar.cica.es
Bug#798356: ITP: libnftables -- high-level library for nftables framework
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: libnftables Version : 0.0.1 Upstream Author : Pablo Neira Ayuso * URL : http://www.netfilter.org * License : GPL Programming Lang: C Description : high-level library for nftables framework libnftables is high-level library for the nftables framework. A bit of background: at first, the current libnftnl (low-level library for the nftables framework) was called libnftables. But just before libnftables was released, the Netfilter folks renamed it to libnftnl, so the name libnftables was keep reserved for this high-level library. As announced by the Netfilter folks, the release of libnftables is about to happen.
default firewall utility changes for Debian 11 bullseye
Hi there, as you may know, Debian 10 buster includes the iptables-nft utility by default, which is an iptables flavor that uses the nf_tables kernel subsystem. Is intended to help people migrate from iptables to nftables. For the next release cycle I propose we move this default event further. As of this email, iptables [0] is Priority: important and nftables [1] is Priority: optional in both buster and bullseye. The important value means the package gets installed by default in every Debian install. Also, I believe the days of using a low level tool for directly configuring the firewall may be gone, at least for desktop use cases. It seems the industry more or less agreed on using firewalld [2] as a wrapper for the system firewall. There are plenty of system services that integrate with firewalld anyway [3]. By the way, firewalld is using (or should be using) nftables by default at this point. This email contains 2 changes/proposals for Debian 11 bullseye: 1) switch priority values for iptables/nftables, i.e, make nftables Priority: important and iptables Priority: optional 2) introduce firewalld as the default firewalling wrapper in Debian, at least in desktop related tasksel tasks. For changes in 2) I'm looking forward to have consensus, and will need others to do changes themselves. I can do changes in 1) myself, and will probably do very soon. regards [0] https://tracker.debian.org/pkg/iptables [1] https://tracker.debian.org/pkg/nftables [2] https://tracker.debian.org/pkg/firewalld [3] disclaimer: I don't use firewalld myself
Re: default firewall utility changes for Debian 11 bullseye
On 7/16/19 11:57 AM, Raphael Hertzog wrote: > Hi, > > I'm replying to your questions but I have also other questions related to > this fresh transition... > > On Tue, 16 Jul 2019, Arturo Borrero Gonzalez wrote: >> as you may know, Debian 10 buster includes the iptables-nft utility by >> default, >> which is an iptables flavor that uses the nf_tables kernel subsystem. >> Is intended to help people migrate from iptables to nftables. > > It is intended that /proc/net/ip_tables_names and > /proc/net/ip6_tables_names is always empty when you use iptables-nft and > thus nf_tables under the hood? > > This is breaking fwbuilder at least: > https://github.com/fwbuilder/fwbuilder/issues/88 > yes, nf_tables does not expose that data into /proc/, it uses a netlink API which is a better way of interacting with it. >> Also, I believe the days of using a low level tool for directly configuring >> the >> firewall may be gone, at least for desktop use cases. It seems the industry >> more >> or less agreed on using firewalld [2] as a wrapper for the system firewall. > > What would/should Debian recommend to configure the firewall on the server > case ? > > I was recommending creating firewall rules with fwbuilder up to now (see > https://debian-handbook.info/browse/stable/sect.firewall-packet-filtering.html) The reset_iptables() functions you mentioned in the above issue don't even replace the rules in an atomic fashion, which is not a good way to work with firewall rules, specially for wrappers. firewalld can be useful in server usecases as well. Here is libvirt using firewalld (and nftables): https://libvirt.org/firewall.html#fw-firewalld-and-virtual-network-driver This is all to say that firewalld may be way better that fwbuilder as a general recommendation.
Re: default firewall utility changes for Debian 11 bullseye
Ok, after a couple of weeks, lets try to summarize: On 7/16/19 11:07 AM, Arturo Borrero Gonzalez wrote: > > This email contains 2 changes/proposals for Debian 11 bullseye: > > 1) switch priority values for iptables/nftables, i.e, make nftables Priority: > important and iptables Priority: optional > Nobody seems to disagree with this point. So I will be doing this soon. > 2) introduce firewalld as the default firewalling wrapper in Debian, at least > in > desktop related tasksel tasks. > There are some mixed feelings about this. However I couldn't find any strong opinion against either. What I would do regarding this is (just a suggestion): * raise priority of firewalld * document in-wiki what defaults are, and how to move away from them * include some documentation bits in other firewalling wrappers on how to deal with this default, i.e what needs to be changed in the system for ufw to work without interferences (disable firewalld?) I don't maintain/control firewalld/ufw so I can't do these changes myself and will leave to Cyril/Michael/Jaime handle the situation for new bullseye install as they see fit.
Re: default firewall utility changes for Debian 11 bullseye
On 7/31/19 7:20 AM, Adam Borowski wrote: > A port blocker just sabotages user's requests, requiring every configuration > action to be done twice. > Perhaps you are mixing shipping a software by default vs having a default blocking firewall ruleset in the system. Moreover, you are assuming a default firewall would block what? outgoing connections? incoming connections? The argument sounds very weak anyway. > An user who actually has a complex host setup needs basic skills to do so, > and those skills are more involved than installing a package would be. I think facilitating complex setups to under-skilled users is actually the key to be successful as an operating system.
Help with the nftables package: the embedded python module
Hi there, the nftables source package contains a python module (the python binding for libnftables). Source code: https://salsa.debian.org/pkg-netfilter-team/pkg-nftables Recently, and because python & setuptools deprecation issues, the python side of package that has been working for ages, is now broken. nftables upstream has removed integration with autotools [1] (suggested by me), so we distro developers (me) should find the best way to install the package (autotools wont do it anymore), which apparently is the python way [0] WTH. I have tested a number of approaches to replace the old simple method, while producing the exact same content in the resulting debian binary package: /usr/lib/python3/dist-packages/nftables/__init__.py /usr/lib/python3/dist-packages/nftables/nftables.py /usr/lib/python3/dist-packages/nftables/schema.json /usr/lib/python3/dist-packages/nftables-0.1-py3.11.egg-info The approaches I tried include: * using pybuild, which is regarded pretty much everywhere as a magic thing, but gets confused with the --with options passed to the autotools ./configure.sh script via dh_auto_configure in d/rules * running `python3 -m build` in d/rules to generate the PKG-INFO file to later move it via dh_install to nftables-0.1-py3.11.egg-info. This is not elegant because the embedded version in the file path. * pip install: one of the referenced methods to handle python's setuptools deprecation [0]is to use pip. But I'm reluctant to run pip (also, couldn't get it to produce the same content for the deb file) I would appreciate additional suggestions and hints. Patches welcome. regards. PS: I'm on vacations, so I may be slow to respond to this email. [0] See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html << move away from a model where there is one, single authoritative way to do things and towards fostering an environment that allows people to develop different tools that work for their workflow. Thanks to all the standards work that's gone on, there has been a profusion of new packaging projects arising, and you should look to see which ones fit your needs.>> [1] https://salsa.debian.org/pkg-netfilter-team/pkg-nftables/-/blob/master/debian/patches/0001-py.patch
Re: Help with the nftables package: the embedded python module
On Sun, Jul 30, 2023, 21:39 Jeremy Sowden wrote: > On 2023-07-28, at 18:59:45 +0200, Timo Röhling wrote: > > * Arturo Borrero Gonzalez [2023-07-28 18:38]: > > > I would appreciate additional suggestions and hints. Patches welcome. > > > > If you have bad interactions between the Python and non-Python parts > > of your package, you can try and build them independently, i.e., > > > > override_dh_auto_build: > > dh_auto_build --package=python3-nftables --sourcedirectory=py > --buildsystem=pybuild > > dh_auto_build --remaining-packages > > > > and similar for the other dh_auto_* commands. I did something like > > that for tinyobjloader and it worked quite nicely. > > Thanks for the pointer, Timo. This does seem to do the trick. > > Arturo, I'll push the changes to Salsa. > > J. > Thanks, Timo and Jeremy. >
Bug#945570: ITP: prometheus-openstack-exporter -- Prometheus exporter for openstack
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: prometheus-openstack-exporter Version : 0.1.4 Upstream Author : Jacek Nykis , Laurent Sesques , Paul Collins * URL : https://github.com/CanonicalLtd/prometheus-openstack-exporter * License : GPLv3 Programming Lang: Python Description : Prometheus exporter for openstack This package contains a small python service that reads several Openstack APIs such as nova, cinder, neutron, swift, etc and produces metrics suitable for scraping by a prometheus server.
Re: Pimp your shell - Debian developer tips?
On 5/27/20 9:06 PM, Otto Kekäläinen wrote: > Hello! > > Do we have Debian devs here who have pimped their shell heavily with custom > prompts, colors, command line fonts, shell window title hacks, perhaps using > zsh > etc? Have you written blogs about you experiences, can you share some good > reads > (with screenshots) of what you have done? > > I've read a bit on zsh and powerline and the like, but I am annoyed that all > those blog posts are quite superficial and do not mention security, > interoperability or performance aspects. Frankly any blog post that recommends > cloning random repos or even worse, running wget | sh something gives me > chills. > > Some above average posts are > https://linuxhint.com/install_zsh_shell_ubuntu_1804/ > and https://www.hildeberto.com/2018/02/oh-my-zsh.html > > I'd very much want to read about some more knowledgeable experiences. > > > Tips? > Take a look at liquidprompt(1). Is what I use everywhere! regards.
Re: Announcing the new "pkg-rpm" team
Thanks Thomas, Just created a wiki page: https://wiki.debian.org/Teams/pkg-rpm regards -- Arturo Borrero González
Re: Is missing SysV-init support a bug?
On 26 August 2016 at 00:11, Sven Hartge wrote: > Hi all! > > I just saw the new conntrack-tools (1:1.4.4-2) package in Sid, which > has as a change > > * [917beed] conntrackd: get rid of the sysvinit support > > and I wondered, if this is a bug (and at what severity) or not. > > While I run all my personal computers on systemd (on Sid) and nearly all > servers at work have been switched to systemd during the Wheezy->Jessie > upgrade, there will still be people left running the classic SysV-Init > and as far as I know it has not been deprecated/removed for Stretch. > So leaving them out in the cold like this seems wrong to me. > Hi! here the author of that changelog line. The rationale for the change was: * the default init system in debian is systemd * I don't have any sysvinit system to keep sysvinit files under any kind of maintenance * sysvinit conntrackd script is really poor, to reliably use conntrackd as a systemd daemon you should use systemd * conntrackd & systemd are very good integrated (using libsystemd) * systemd is starting to drop support for some sysvinit mechanisms [0] * it's time to let sysvinit die So, obviously from my point of view, lack of sysvinit support is not a bug. The conntrackd software is a very specific daemon which is usually run in a very concrete scenario. In most of these scenarios, you will need the software to be started and stopped *reliably*, ordering other system services with it *reliably* (for example, at system boot). Right now, conntrackd is integrated with libsystemd so the daemon reports startup & shutdown reliably to systemd (also includes watchdog support). If you are about to build a firewall cluster and you choose between sysvinit and systemd, no serious implementation would use sysvinit, so I think the sysvinit support here is simply irrelevant. [0] https://sources.debian.net/src/systemd/231-4/debian/systemd.NEWS/ -- Arturo Borrero González
Re: Is missing SysV-init support a bug?
Hi, I've just received several (different) opinions both in public and in private. I will think about this issue during the weekend. regards. -- Arturo Borrero González
Re: Lots and lots of tiny node.js packages [and 1 more messages]
On 3 November 2016 at 18:50, Ian Jackson wrote: > > Thanks, Russ, for a very good answer to my question. > > Can we keep it somewhere ? > just created this: https://wiki.debian.org/TinyPackages feel free to add more content.
about build flavours
Hi, we are trying to create a build flavour for the suricata package [0], which we would like to link to hyperscan, which uses SSSE3. I've read several docs in our debian wiki regarding build flavours, but I couldn't find any proper document which describes best practices. Currently, our main idea is to create a suricata-hyperscan package which includes the dependency to hyperscan, and the binary is build linked to the library. We distribute two /usr/bin/suricata binaries in two binary packages: * suricata, without hyperscan * suricata-hyperscan, with hyperscan Then, we conflict the packages with each other and dpkg-divert the /usr/bin/suricata file in suricata-hyperscan. I don't know if there is another approach which could be more recommended for this situation. Please, share your comments. best regards. [0] #846143 https://bugs.debian.org/846143
Re: about build flavours
On 30 November 2016 at 11:09, Paul Wise wrote: > On Wed, Nov 30, 2016 at 6:01 PM, Sascha Steinbiss wrote: > >> Yes, the libhyperscan package alerts the user at pre-install time if >> SSE3 is not supported on the target system. That's one of the reasons >> why I think there should still be a version of suricata that works >> without Hyperscan. > > Sounds like they are doing it wrong. The detection should happen at > runtime not pre-install time. > I don't think hyperscan currently is able to detect SSE3 support at runtime. Do you think that the warning at install-time is not enough?
Re: about build flavours
On 30 November 2016 at 11:33, Paul Wise wrote: > On Wed, 2016-11-30 at 11:11 +0100, Arturo Borrero Gonzalez wrote: > >> I don't think hyperscan currently is able to detect SSE3 support at runtime. > > Sounds like a bug. > >> Do you think that the warning at install-time is not enough? > > Sounds like a reasonable workaround for the bug. > CC'ing Matthew, who is upstream developer at Intel. Perhaps he could share some comments on this topic. @Matthew, we are wondering whether hyperscan is able to detect SSE3 support at runtime in a given machine. We are planning to integrate hyperscan with other packages (such as suricata) and we are evaluating possible alternatives regarding this integration. (please, keep debian-devel in CC) regards
Re: The end of OpenStack packages in Debian?
On 15 February 2017 at 13:42, Thomas Goirand wrote: > > All this to say that, unless someone wants to hire me for it (which > would be the best outcome, but I fear this wont happen), or if someone > steps in (this seems unlikely at this point), both the packaging-deb and > the faith of OpenStack packages in Debian are currently compromised. > Very sad news indeed. But hopefully, someone will notice this is not good for openstack either and will restart funding the effort. Big players, I'm staring at you.
Re: Default page view for salsa repositories
On 18 January 2018 at 11:15, Alex Mestiashvili wrote: > Hi All, > > while browsing through salsa.debian.org packages I got a feeling that > displaying upstream's Readme by default is not exactly relevant to > Debian packages. I guess it would make more sense do display > d/Readme.source if available or d/changelog instead. > Or even something more advanced like tracker.debian.org for a package... > A repository owner should be able to override this setting of course. > +1
Bug#891669: ITP: nftlb -- nftables load balancer
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: nftlb Version : 0.1 Upstream Author : Laura Garcia * URL : https://github.com/zevenet/nftlb * License : AGPL-3 Programming Lang: C Description : nftables load balancer nftlb stands for nftables load balancer, the next generation linux firewall that replaces iptables, is adapted to behave as a complete load balancer and traffic distributor. nftlb is provided with a JSON API, so you can use your preferred health checker to enable/disable backends or virtual services and automate processed with it. The nftables framework used for load balancing can outperform [0] typical LVS deployments by 10x. More info at: https://www.zevenet.com/knowledge-base/nftlb/what-is-nftlb/ [0] https://www.zevenet.com/blog/nftables-load-balancing-10x-faster-lvs/
Re: [alioth deprecation] Please remove your unused and/or migrated repositories
On 27 April 2018 at 08:55, Alexander Wirt wrote: > Hi, > > please remove your old, unused repos on alioth, so that we don't have to > archive them. > > For darcs, bzr and mecurial do this until 2018-05-09 for all other VCS until > 2018-05-16. > Hey! Could you please provide some hints of what buttons to press in order to delete the repos? thanks
Re: [alioth deprecation] Please remove your unused and/or migrated repositories
On 27 April 2018 at 11:07, Alexander Wirt wrote: > On Fri, 27 Apr 2018, Arturo Borrero Gonzalez wrote: > >> On 27 April 2018 at 08:55, Alexander Wirt wrote: >> > Hi, >> > >> > please remove your old, unused repos on alioth, so that we don't have to >> > archive them. >> > >> > For darcs, bzr and mecurial do this until 2018-05-09 for all other VCS >> > until >> > 2018-05-16. >> > >> >> Hey! >> >> Could you please provide some hints of what buttons to press in order >> to delete the repos? > No buttons - and exact details depend on how you created the repo and the > type of repo. Just remove them from disk (rm). > My first try was from the alioth web panel. I could only deselect the code repo plugin in the 'Tools' section. If we should jump into a machine and `rm -rf` something, please share concrete details so we don't nuke something else by mistake :-P I'm not familiar with the alioth backstage, sorry for that.
Re: autopkgtest results influencing migration from unstable to testing
On 3 May 2018 at 11:21, Colin Watson wrote: > > (I echo Simon's thanks for doing this, though!) > Yeah, thanks for this! I would say, yeah, please wait a couple of stable releases before going full blocker. I (and others) may not have the time to polish our autopkgtest tests. If we end with less autopkgtests tests because of this, then the result of this push would be the opposite of what we intended :-P
Re: What's a safe way to have extensions in chromium in Debian?
On 22 March 2017 at 12:03, Enrico Zini wrote: > Hi, > > now we have extensions disabled in Chromium by default. If I did my > homeworks correctly, that prevents Chromium from phoning home by > default, and prevents a previous scenario where extensions could be > installed but not upgraded, becoming security issues over time. > > Now, suppose I need an extension, what is the proper way to have it in > Debian, so that it gets upgraded when needed? With that proper way, what > amount of phoning home is going to happen? > > Since this looks like it's going to be a major issue with stretch, can I > have some authoritative wiki page / FAQ entry that tells me how I can > deal with it cleanly, and that I can easily send to confused people? > There are some really important extensions, like adblock and privacy badger by the EFF [0]. The lack of them is really annoying. [0] https://www.eff.org/privacybadger
Re: Moving away from (unsupportable) FusionForge on Alioth
On 14 May 2017 at 11:58, lumin wrote: > On the other hand, I fancy modern platforms such > as Gitlab, as a user. And wondering when Debian > will update its homepage (www.d.o) to a modern > design[1]. > > [1] This is off-thread, but some of my young > friends just gave up trying Debian at the > first glance at our homepage. > off-thread, yes. But please spawn another thread to talk about this real issue. Our users are really complaining about our look&feel in the web and we should address it.
Re: website maintenance
On 15 May 2017 at 12:12, Geert Stappers wrote: > > >> Our users are really complaining about our look&feel in the web >> and we should address it. > > "we should do so many things" > Thing I say about it: Please do. > Of course, that's my view too. Unfortunately, I don't have the web abilities (web technologies, design, UX, whatever) that this task requires. Someone have suggested to invest a bit of our money into some paid work. I believe this idea is something worth exploring too.
Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
On 15 May 2017 at 13:30, Paul Wise wrote: > TBH if I was confronted with the new LXDE web design with CSS turned > on, I would probably just close the page. The old page is way more > informative and less heavy on the marketing. > Hi Paul, I believe that what we are actually looking for is a bit of improvement in the marketing side. Modern and fancy things. The LXDE example is good on that.
Re: Proposed change of offensive packages to -offensive
On 21 November 2017 at 14:01, Ian Jackson wrote: > We have an (AFAICT informal) convention that packages with offensive > content, or content in questionable taste, should have names ending in > -off. This abbreviation is unnecessary, and increases the chances > that someone will install such a thing by mistake. > > (If cowsay-off had been called cowsay-offensive, #882085 would > probably have been discovered rather sooner and in a rather better > way.) > > I would like to suggest that we rename all such packages to > "foo-offensive" for buster. (Also, the highest dependency on such a > package from a non-"-offensive" package should be Suggests.) > > AFAICT 3 packages are affected: fortunes (and its translations), > cowsay, and purity. > I agree. Not involved in any of the packages, but I guess that whatever agreement we make it is worth documenting elsewhere apart of the mailing list archive. Wiki? policy?
Debian Stretch new user report (vs Linux Mint)
Hi, Please take this email as another call to keep the hard work in improving our operating system and user experience, specially for new users. Several times I've detected that we lack reports from final users using our system, so here is another case. Recently a friend of mine tried his first take at Linux in his laptop/desktop. He tried Linux Mint in the laptop machine which worked out of the box: wifi, external usb hardware, etc. He then tried Debian Stretch in the desktop machine. He has been sending me feedback of what happened, and the issues so far were: * no support for the wifi interface of the dekstop machine (this was expected, fixed by installing non-free package by hand, since no network) * no support for RW on NTFS drives, only RO. This wasn't fixed even by installing ntfs-3g [0]. Both issues together were enough for my friend to directly move to Linux Mint in both machines, which is not fine, but anyway he is now using Linux since he didn't came back to Windows, which is great :-) I didn't have the time to investigate the NTFS issue myself, sorry :-( No debate intended, just information, a simple real-world case. This was somehow an advanced user, enough for installing the operating system by himself, but not enough to know the deep internals of Debian/Linux. best regards. [0] https://wiki.debian.org/NTFS
Re: Debian Stretch new user report (vs Linux Mint)
On 1 December 2017 at 12:23, Michael Biebl wrote: > Am 01.12.2017 um 07:34 schrieb Paul Wise: >> On Fri, Dec 1, 2017 at 1:36 AM, Arturo Borrero Gonzalez wrote: >> >>> * no support for the wifi interface of the dekstop machine (this was >>> expected, fixed by installing non-free package by hand, since no >>> network) >> >> It would have been best for him to download the ISO with non-free >> firmware embedded, do you know how he made the decision to download >> the ISO without non-free firmware? >> What others say is true. It's not easy to find the download link, even for me as DD. But this is something that we have already detected: our main website needs work. We just need someone doing the work. >>> * no support for RW on NTFS drives, only RO. This wasn't fixed even by >>> installing ntfs-3g [0]. >>> I didn't have the time to investigate the NTFS issue myself, sorry :-( >> >> Sounds like you need to get him to file a bug against ntfs-3g and >> against whichever meta-package or other component should be installing >> ntfs-3g. For the latter, perhaps gnome-software/PackageKit needs some >> sort of filesystem detector that installs relevant packages. I was in >> the same position recently with the Apple HFS+ filesystem. >> > > udisks2 already recommends ntfs-3g. Most major desktops should use and > install udisks2. Which desktop environment did your user install and did > he maybe choose to not install recommends? > > I don't really know, I would say gnome. We would have to check every desktop stack and review how things are for both NTFS and HFS+. BTW filling bugs is ideal, but is something a new user [to linux ecosystem] won't do (or unlikely). I'm worried about this topic, I would love to lower the barrier for new users. You can read related blog post I've written before about this [0][1]. The main website, www.debian.org, is the first point of contact for many people. Identify the right download is hard, even if the information is well organized, see for example the ubuntu page [2]. Other thing is the branding topic. I would like to promote usage of Debian testing for standard desktop/laptop users in personal environments (not for business machines) but the 'testing' word scares people. I don't have a valid candidate :-( But we should really point to stable to specific users rather than all by default. [0] http://ral-arturo.org/2017/05/11/debian-myths.html [1] http://ral-arturo.org/2017/01/17/debian-puzzle.html [2] https://www.ubuntu.com/download
Re: ISO download difficult (was: Debian Stretch new user report (vs Linux Mint))
On 1 December 2017 at 14:39, W. Martin Borgert wrote: > Quoting Paul Wise : >> >> It would have been best for him to download the ISO with non-free >> firmware embedded, do you know how he made the decision to download >> the ISO without non-free firmware? > > > Every time I need a Debian ISO, it takes me minutes to find it. > I didn't even know, that there were an ISO with non-free firmware. > > There should be a beautiful ISO download page, e.g. > https://www.debian.org/download[s]/ > with all architectures and supported releases, similar to > https://www.ubuntu.com/download > or > https://linuxmint.com/download.php I couldn't agree more. You all know the big amount of combinations we have: suite - arch - ISO size/flavour - freeness suite: stable , testing, whatever arch: amd64, i386, arm, mips, whatever size/flavour: DVD, CD-ROM, USB, netinst, whatever freeness: including or not non-free, whatever There doesn't seem to be a single page to find all these links. And that should be easy to fix by anyone with the time, knowledge and the will to do so.
Re: salsa.debian.org (git.debian.org replacement) going into beta
On 26 December 2017 at 10:22, Alexander Wirt wrote: > On Tue, 26 Dec 2017, Jonathan Dowland wrote: > >> On Tue, Dec 26, 2017 at 08:16:41AM +0100, Alexander Wirt wrote: >> > On Mon, 25 Dec 2017, Marco d'Itri wrote: >> > > I am not looking forward to update all Vcs-Git and Vcs-Browser headers >> > > currently referencing anonscm.debian.org. >> > Unfortunately that is something that has to be done. At least unless >> > someone >> > wants to write some kind of redirection map. >> >> I'm not too concerned about the work, however, I thought the whole point >> of "anonscm.debian.org" was exactly to be a portable name. > that doesn't make urls magically working and we can't do a hard switch > between those hostnames. > And regarding team mailing lists, Would you please remind us what is the proposed replacement?
Re: salsa.debian.org (git.debian.org replacement) going into beta
On 26 December 2017 at 11:03, Alexander Wirt wrote: > On Tue, 26 Dec 2017, Arturo Borrero Gonzalez wrote: > >> On 26 December 2017 at 10:22, Alexander Wirt wrote: >> > On Tue, 26 Dec 2017, Jonathan Dowland wrote: >> > >> >> On Tue, Dec 26, 2017 at 08:16:41AM +0100, Alexander Wirt wrote: >> >> > On Mon, 25 Dec 2017, Marco d'Itri wrote: >> >> > > I am not looking forward to update all Vcs-Git and Vcs-Browser headers >> >> > > currently referencing anonscm.debian.org. >> >> > Unfortunately that is something that has to be done. At least unless >> >> > someone >> >> > wants to write some kind of redirection map. >> >> >> >> I'm not too concerned about the work, however, I thought the whole point >> >> of "anonscm.debian.org" was exactly to be a portable name. >> > that doesn't make urls magically working and we can't do a hard switch >> > between those hostnames. >> > >> >> And regarding team mailing lists, Would you please remind us what is >> the proposed replacement? > For important (!) lists, lists.debian.org. For commit lists, use gitlab > notifications. Everything else is no in my hand. > I was specifically thinking about a mailing list for the Maintainer: field. We would like to keep a single point of contact for users and for bug reports. I'm not sure if that qualifies for what you have in mind for l.d.o.
Re: salsa.debian.org (git.debian.org replacement) going into beta
On 26 December 2017 at 12:28, Alexander Wirt wrote: > On Tue, 26 Dec 2017, Arturo Borrero Gonzalez wrote: >> >> I was specifically thinking about a mailing list for the Maintainer: field. >> We would like to keep a single point of contact for users and for bug >> reports. >> >> I'm not sure if that qualifies for what you have in mind for l.d.o. > That would be the tracker feature, mentioned several times in the list > thread. It doesn't make sense to just run a mailinglist for something that > really is an alias. > Yeah, I'm don't need a mailing list, just the alias. But still, do you have any docs regarding this? This should be clearly documented somewhere, since we should update all d/control files in packages. I would like the change to make sense. Please, share any detailed info you may have :-) it would be really appreciated.
Re: Team naming policy on salsa.debian.org
On 26 December 2017 at 13:12, Jonathan McDowell wrote: > On Mon, Dec 25, 2017 at 11:45:37AM +0100, Alexander Wirt wrote: > >> Teams >> - >> >> For larger projects you can also create a group to host your projects. >> To avoid clashes with usernames (that share the same namespace as >> groups) we are requiring groups to have a '-team' suffix to their >> name. Groups can be created using the same self-service portal >> https://signup.salsa.debian.org. For larger, already-established >> teams it is also possible to ask us to create the group with a name >> not conforming to the normal team namespace. Examples are teams like >> *debian-qa*. Please create an issue in the support[1] project. > > Is there a policy here? I'm seeing a mix of formats rather than any > consistency. For example for keyring-maint should we request > debian-keyring as a group, or just use keyring-team? DSA and ftp-master > have gone for the latter (dsa-team + ftp-team) but I'd assumed the > former was more appropriate for an official Debian entity. > > Likewise for pkg-electronics I was expecting pkg-electronics-team (to > match, e.g., pkg-suricata-team) but I see things like libvirt-team as > well so the pkg- prefix doesn't seem to be consistently used/unused. > Following with your example (pkg-suricata-team) I prefer to make it explicit for people outside debian that this is about packaging. So I usually put the 'pkg' string also in individual repos, i.e.: pkg-suricata-team/pkg-suricata.git I had problems in the past with misleading repo names, and it cost nothing to have the pkg string everywhere and be explicit. Newcomers usually like this as well, things are not obvious for them.
Re: Suggestion for the DontBreakDebian wiki page section "Dont 'make install'"
El 20 oct. 2015 5:15 p. m., "Francisco José Fernández Naranjo" < fjfnara...@gmail.com> escribió: > > I was considering myself adding a quick note to the section, but I am > not an English native speaker and I am concerned with the quality of > my contribution. In fact, your english level seems good enough to me :-)
iptables 1.6.0-2 in unstable
Hi, [TL;DR: please test the package] the latests upstream version of iptables (1.6.0) just landed in unstable. It should be in debian testing in a few days, no blocks are expected. This is a major release of iptables, last one was in 2013. Among other things, this release includes the 'iptables-nftables-compat' binary package which contains some tools to help in the transition from iptables to nftables. However, users are not expected to migrate from iptables to nftables right now. This mail is about requesting review and testing of the bare iptables tools (iptables, ip6tables, and the like). We would like to avoid to the maximum extend corner case regressions and problems of any kind. In the past, people found issues when migrating from older kernels to newer ones. There are mainly 2 kind of people who might be really interested in this review&testing: * maintainers of iptables-based packages (i.e, wrappers) * users of iptables (i.e, firewalls) Please file bugs as needed. Thanks, best regards. -- Arturo Borrero González
Re: Bug#815675: ITP: ftpbackup -- Script to backups your data from a Debian system to a ftp space
On 23 February 2016 at 20:52, Jose-Luis Rivas wrote: > On 23/02/16, 08:37am, Nikolaus Rath wrote: >> >> I'm actually rather shocked that a Debian Developer would consider >> letting this into the archive. Carl, I hope you just filed the ITP >> before having looked at the program? >> > > He wrote it. > > L6: # Copyright © 2013-2016 Carl Chenet > You are all late, the package seems to be in NEW already [0]. I understand that the temptation to package own scripts/pet projects is strong, I've felt it many times. [0] https://ftp-master.debian.org/new/ftpbackup_0.3-1.html -- Arturo Borrero González
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On 8 June 2016 at 10:08, Lars Wirzenius wrote: > On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote: >> I am also not very keen on using a system with a "open core / enterprise" >> model. For such a crucial service I would really prefer a real open source >> system. But maybe I am alone with that oppinion. > > You're not alone. The open core approach of Gitlab worries me greatly. > > (I'm just a random Debian developer. I no particular say in this.) > +1 -- Arturo Borrero González
Re: Announcing new pkg-security team
On 17 June 2016 at 11:06, Gianfranco Costamagna wrote: > > If you have a pet security tool you want to see packaged/sponsored in Debian, > feel free to join the team, and ask for sponsorhip! > Hi, I'm involved in a couple of related packages [0][1] which I would be very happy to integrate in this new team. thanks for the initiative. [0] https://tracker.debian.org/pkg/thc-ipv6 [1] https://tracker.debian.org/pkg/neopi -- Arturo Borrero González
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On 22 June 2016 at 10:42, Holger Levsen wrote: > On Wed, Jun 22, 2016 at 08:13:40AM +, Eliran Mesika wrote: >> As I wrote earlier, we're open to making certain features available upon >> request. In the specific case of the feature that was discussed - could you >> please elaborate what is missing and what functionality is available on the >> Enterprise edition that you'd like to be made public? We want to better >> understand the use-case and the requirements to respond to this request. > > I'm obviously not Alex but I also object using a software for Debian's > own infrastructure which is split into a free and an enterprise version. > > It's not about a specific patch. > > Free gitlab and we can talk again. > > It's not that there are no free alternatives. > +1 -- Arturo Borrero González
