Bug#932485: ITP: libextutils-hascompiler-perl -- Perl Module checking the presence of a compiler
Package: wnpp Owner: Clément Hermann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libextutils-hascompiler-perl Version : 0.021 Upstream Author : Leon Timmermans * URL : https://metacpan.org/release/ExtUtils-HasCompiler * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl Module checking the presence of a compiler ExtUtils::HasCompiler tries to check if the current system is capable of compiling, linking and loading an XS module. This module is mainly packaged to avoid patching the build system of modules using it at build time. Notice: this is an early release, interface stability isn't guaranteed yet. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#932494: ITP: libextutils-hascompiler-perl -- Perl Module checking the presence of a compiler
Package: wnpp Owner: Clément Hermann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libextutils-hascompiler-perl Version : 0.021 Upstream Author : Leon Timmermans * URL : https://metacpan.org/release/ExtUtils-HasCompiler * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl Module checking the presence of a compiler ExtUtils::HasCompiler tries to check if the current system is capable of compiling, linking and loading an XS module. This module is mainly packaged to avoid patching the build system of modules using it at build time. Notice: this is an early release, interface stability isn't guaranteed yet. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#932495: ITP: libextutils-makemaker-dist-zilla-develop-perl -- Perl module creating bare-bones Makefile.PL files for use with dzil
Package: wnpp Owner: Clément Hermann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libextutils-makemaker-dist-zilla-develop-perl Version : 0.03 Upstream Author : Jesse Luehrs * URL : https://metacpan.org/release/ExtUtils-MakeMaker-Dist-Zilla-Develop * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl module creating bare-bones Makefile.PL files for use with dzil Dist::Zilla makes developing modules much easier by generating all kinds of boilerplate files, saving authors from having to write them by hand, but in some cases this can make developing more inconvenient. The most prominent example of this is with Makefile.PL files - although the majority of distributions can be hacked on just by editing the files in a source control checkout and using prove for testing, for some this isn't sufficient. In particular, distributions which use an auto-generated test suite and distributions which use XS both need special handling at build time before they will function, and with Dist::Zilla, this means running dzil build and rebuilding after every change. This is tedious! ExtUtils::MakeMaker::Dist::Zilla::Develop provides an alternative. Create a minimal Makefile.PL in source control which handles just enough functionality for basic development (it can be as minimal as just what is in the /SYNOPSIS, but can also contain commands to generate your test suite, for example), and tell Dist::Zilla to replace it with a real Makefile.PL when you're actually ready to build a real distribution. To do this, make sure you're still using the MakeMaker|Dist::Zilla::Plugin::MakeMaker plugin, either directly or through a pluginbundle like @Basic|Dist::Zilla::PluginBundle::Basic, and add the exclude_filename = Makefile.PL option to your dist.ini where you use [GatherDir]. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
Le September 12, 2019 4:52:47 PM UTC, Adam Borowski a écrit : >On Tue, Sep 10, 2019 at 07:46:57PM +0200, Marco d'Itri wrote: >> On Sep 09, Adam Borowski wrote: >> >> > With DoH: >> > * the target server knows about you (duh!) >> > * the ISP can read the destination of every connection >> > [reading the IP header, reading SNI header] >> > * the ISP can block such connections >> > [blocking actual connection] >> Well, no. They cannot without significantly more expensive hardware >to >> do DPI and a *totally different* legislative framework. >> (Source: I have been dealing with government-mandated censorship in >> Italy for ~15 years, both at technical and policy levels.) > >I don't understand how blocking by IP would be any more expensive than >blocking by DNS. It's _cheaper_: you read a field in the IP header >instead >of doing it in a higher level DNS server. I don't think it is, actually. Disregarding the legal framework part, only looking at the technical aspect of things, when you do it with DNS, you just have to create a local version of the zone that has be censored and distribute it normally on your resolvers, for instance. Anyway you do a high level modification in a high level service. Request will go through your DNS infrastructure the way it's intended to. However, reading IP headers on routers to block a particular destination is not how network are designed to operate. It's not as cheap a function you'd think, because it means either being able on the customer router, or close to it, and those aren't usually designed to filter that way, or you make sure all traffic pass by a filtering router at some point - which means dedicated hardware with the traffic load involved. This is usually complicated in a large ISP context: networks are huge and evolved over time ; and they weren't designed for censorship to begin with, there was this thing called Net Neutrality... ;) Cheers, -- nodens
Re: Epoch version for golang-github-gomodule-redigo-dev?
(And that should have been sent from my @d.o email address, but the setup I have in place for that is apparently broken, sorry 😉) On 26/11/2020 14:19, Clément Hermann wrote: > On 26/11/2020 09:31, Paul Gevers wrote: >> Hi Michael, >> >> On 26-11-2020 08:57, Michael Prokop wrote: >>> AFAICS we could: >>> >>> 1) use 2.0.0+really1.8.3 pattern for our Debian package version >> >> As it seems not unreasonable to expect the upstream version to go past >> 2.0.0 in the not infinite future, this is the approach I would take. >> Because you ask here, it suggests to me that doing this has some pain >> for the packaging that you didn't elaborate on. Why do you even raise >> the question here on debian-devel and don't just do this established way >> of fixing these kind of temporarily versioning issues in Debian? > > Well, I was the one suggesting Michael start a discussion on > debian-devel about it, so I thought I'd chime in. > > > My reasonning is +really seems to me to be a workaround when we > have to change the version number for Debian only reason - with no fault > of upstream. An example of this was the lack of transition in the last > freeze with a bunch of Go packages that were updated in unstable when > they shouldn't have, and had to be reverted. > > Actually, I even suggested to use +upstream instead, but I > don't know if that'd be allowed (as in understandable, clearer that > +really and as such, useful). > > Also, we don't know if it's temporary, as Holger pointed out. > > An epoch might be overkill here, but also seems more appropriate to me > since we have to work around upstream decision in this case. And since > the Policy states it needs to be discussed first here, I suggested to do > just that. > > I do agreee that the best and most logical thing would be for upstream > to start using 3.0, as Simon pointed out. Michael, did you bring this > issue upstream ? Would you suggest this option to them ? If they're > willing to do that in a reasonable timeframe, we could go the +really > route and wait until 3.0 is available upstream. Otherwise, we can go for > an epoch if we reach consensus here. > > Thanks to everyone participating, by the way! > > Cheers, >
Re: Epoch version for golang-github-gomodule-redigo-dev?
On 26/11/2020 09:31, Paul Gevers wrote: > Hi Michael, > > On 26-11-2020 08:57, Michael Prokop wrote: >> AFAICS we could: >> >> 1) use 2.0.0+really1.8.3 pattern for our Debian package version > > As it seems not unreasonable to expect the upstream version to go past > 2.0.0 in the not infinite future, this is the approach I would take. > Because you ask here, it suggests to me that doing this has some pain > for the packaging that you didn't elaborate on. Why do you even raise > the question here on debian-devel and don't just do this established way > of fixing these kind of temporarily versioning issues in Debian? Well, I was the one suggesting Michael start a discussion on debian-devel about it, so I thought I'd chime in. My reasonning is +really seems to me to be a workaround when we have to change the version number for Debian only reason - with no fault of upstream. An example of this was the lack of transition in the last freeze with a bunch of Go packages that were updated in unstable when they shouldn't have, and had to be reverted. Actually, I even suggested to use +upstream instead, but I don't know if that'd be allowed (as in understandable, clearer that +really and as such, useful). Also, we don't know if it's temporary, as Holger pointed out. An epoch might be overkill here, but also seems more appropriate to me since we have to work around upstream decision in this case. And since the Policy states it needs to be discussed first here, I suggested to do just that. I do agreee that the best and most logical thing would be for upstream to start using 3.0, as Simon pointed out. Michael, did you bring this issue upstream ? Would you suggest this option to them ? If they're willing to do that in a reasonable timeframe, we could go the +really route and wait until 3.0 is available upstream. Otherwise, we can go for an epoch if we reach consensus here. Thanks to everyone participating, by the way! Cheers, -- nodens
Jack client in PipeWire [was: Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio]
Hi, Le 29/09/2022 à 05:02, Sam Hartman a écrit : * If you do need jackd for real because pipewire's jack isn't quite good enough, pipewire's jack client didn't work at all last time I used it. So you may be forced to shut down wireplumber and pipewire and start up pulseaudio. FWIW, I did manage to get a jack client in pipewire by setting ["alsa.jack-device"] = true in the alsa_monitor.properties block of .config/wireplumber/main.lua.d/50-alsa-config.lua It creates a jack_client device that you can set on or off. In my case I did that because some librtaudio apps misbehave with the current pipewire jack emulation (VCV Rack in this case) if you don't force the sample rate/size and using native jack makes it better (since native jack doesn't allow live change of sample rate anyway). HTH, -- nodens -- nodens
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
Le 29/09/2022 à 00:30, Lisandro Damián Nicanor Pérez Meyer a écrit : Hi, On Tue, 13 Sept 2022 at 13:39, Antoine Beaupré wrote: [snip] I also have the feeling that pipewire has already gone beyond what pulseaudio is capable of in terms of Bluetooth support, but I might be mistaken on that. Well, with pulseaudio I always needed to run the following each time I log into KDE in order to be able to pair with my devices: $ cat bin/restart_bluetooth.sh #!/bin/sh pulseaudio -k start-pulseaudio-x11 sudo service bluetooth restart I have tried pipewire and I have the same issue, but this time restarting pipewire-pulse doesn't helps. Of course the root cause of this might be even deeper that that, but so far that's the only way I could make my BT devices to pair on my laptop :-/ Try maybe restarting wireplumber instead (or as well)? It's involved in BT while pipewire-pulse isn't. -- nodens
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On September 29, 2022 12:26:03 PM UTC, Emanuele Rocca wrote: >Hi, > >On 2022-09-08 05:58, Dylan Aïssi wrote: >> I have been asked several times regarding when Debian will switch its default >> sound server from PulseAudio to PipeWire without having an official answer. >> Thus, I suppose it's the right time to start a discussion about that. > >PipeWire seems to be working just fine as a drop-in replacement for me >on sid, so personally I don't have any objections to the sound server >switch. > >My concern is about the availability of clients for controlling things >like volume and which output device to use. In an effort to try and >reducing the variety of sound-related stuff installed on my machines >[1], I've removed everything vaguely resembling "pulseaudio", except for >what would have caused the removal of tons of stuff. I am now left with: > >libpulse-mainloop-glib0:amd64 >libpulse0:amd64 >pipewire-pulse > >Sound still works fine, but how to do things like changing volume, >toggling mute, choosing between HDMI and headphones, ...? I understand >that one can still use pavucontrol, but that would essentially mean >bringing back parts of pulseaudio (at least libpulsedsp, pavucontrol, >and pulseaudio-utils). > >If it's true that pavucontrol (or similar) is still required, I think it >would be a bit confusing to make the switch from pulseaudio to pipewire >and still have functional dependencies on pulseaudio around. You don't need to remove pulseaudio client stuff. It will work fine with pipewire (I do use pavucontrol for instance, despite having switched a while ago). Only the pulseaudio daemon needs to be at least stopped. Cheers, -- nodens
Re: Upcoming shift to Ayatana (App)Indicator(s)
On 29/03/2018 15:11, Mike Gabriel wrote: > [stuff] Thanks for this summary and your work on this. > ### Ayatana AppIndicator API > > The Ayatana AppIndicator API is just one way of talking to an SNI DBus > service. The implementation is done in the shared lib > 'libayatana-appindicator'. This library provides an easy to implement > API that allows GTK-2/3 applications to create an indicator icon in a > panel with an indicator renderer added. > > In the application, the developer creates a generic menu structure and > defines one or more icons for the system tray (more than one icon: only > one icon is shown (plus some text, if needed), but that icon may changed > based on the applet's status). This generic menu is sent to a DBus > interface (org.kde.StatusNotifier). Sometimes, people say, that such > applications have SNI support (StatusNotifier Interface support). > > The Ayatana Indicators project offers Ayatana AppIndicator to GTK-3 > developers (and GTK-2, but well...). Canonical implemented bindings for > Python2, Perl, GIR, Mono/CLI and we continue to support these as long as > it makes sense. That sounds interesting. I maintain openpgp-applet [0] (both upstream and in debian, which is in perl / gtk3 and currently uses the old fashion systray. However, I did a quick search, and I couldn't find the bindings for perl you speak about, be it on CPAN or Launchpad. I probably missed it, could you share a link ? > The nice part of Ayatana AppIndicator shared library is: if a desktop > shell does not offer the SNI service, then it tries to fall back to the > xembed-way of adding system tray icons to your panel / status bar. > > In Debian, we will start sending out patches too SNI supporting > applications soon, that make the shift from Ubuntu AppIndicator (badly > maintained in Debian) to Ayatana AppIndicator. The cool part of this is, > you can convert your GTK-3 application from Ubuntu AppIndicator to > Ayatana AppIndicator and use it on top of any(!) SNI implementation, be > it an applet based on Ubuntu Indicators, based on Ayatana Indicators or > some other implementation, like the vala-sntray-applet or SNI support in > KDE. I remember reading somewhere that a limitation is that you can only use one type of click (no way to behave differently on right-click / left-click), so I guess in some cases the switch means also a new UI, right ? Cheers, [0] https://tracker.debian.org/openpgp-applet, and https://openpgp-applet-team.pages.debian.net for the upstream project -- nodens
Re: Hi, I am blind
Hi, (assuming you mean "Debian" and not "Devian" here, but that doesn't change much in this case anyway). On 14/04/2018 08:56, adri Orjales Vidal wrote: > Hello, I am blind and I need to use a screen reader so I can use my pc. I am > tired to use windows, and I wanted to start using Devian, but here I saw that > the screen reader Orca is kilometers away from NVDA, non visual desktop > access, wich is a windows screen reader very fast. NVDA is open source, and > it is developed over python Sadly, that doesn't mean it can easily work on a Linux system. There is an issue upstream where they stated that they wouldn't work on this for now: https://github.com/nvaccess/nvda/issues/6104 > I think that if you are able to add it in Devian I will be the happiest man > in the world!! > If it is not possible, please you should update Orca, the screen readers are > more useful when are low level of system development, so you must change the > way to make it really useful I'm not sure what you mean by "low level of system development". In the last stable version, you only get orca 3.22, but that's they way stable work. You can get a more recent version by using testing (buster) but that's not recommanded for everyone. There are no backports available currently (https://backports.debian.org/, that would get you 3.28), and I'm not sure how feasible it would be to backport it without backporting all of GNOME. That said, have you checked https://www.debian.org/devel/debian-accessibility/ ? Cheers, -- nodens
Collation discrepencies between locales [was: Re: Bits from the release team: full steam ahead towards buster]
On 19/04/2018 22:45, Holger Levsen wrote: > I now wondered if it's not only en_GB.utf8 which is "different", but also > the NZ and US variants sort like that (and so differently than C)... not > sure if en_FR.utf8 exist, but using it, it sorts differently / like C ;) > > (probably because it doesnt exist, thus the default, C, is used.) Indeed, it doesn't exist. At least , for fr_* locale, it seems to be consistent both in the different charsets available (e.g. fr_FR and fr_FR.UTF-8) and country (fr_BE, fr_CA, fr_CH, fr_FR and fr_LU). Actually I thought the localization had been made consistently with the apparition of unicode locales, that is, fr_* locale would all give the same result regardless of the charset (but older fr_FR for instance might give a different order than before the apparition of the unicode variant). I may be wrong - one would probably have to check the code in GNU libc to be sure. However, Note that the generation of locale matters: at first I thought fr_FR and fr_BE where behaving differently, but after uncommenting all fr_* locales in /etc/locale.gen, everything became consistent. Cheers, -- nodens
AppArmor in Debian BoF (was: Let's enable AppArmor by default (why not?))
Hi, A year ago, intrigeri proposed an experiment: let's enable AppArmor by default in testing/sid. Here is an extract from the proposal (you can find the full proposal and the thread at [0]): > tl;dr: I hereby propose we enable AppArmor by default in testing/sid, > and decide one year later if we want to keep it this way in the > Buster release. > > My goals when initiating this discussion are: > > - Get a rough idea of what amount of effort the Debian project is >happy (and able) to invest into such proactive security measures. > > - Learn about any relevant social & technical concerns I am not >aware of. > > I don't expect we'll make a decision based on this very proposal: > I expect the proposal will need to be refined, or abandoned, to take > into account what we will learn during this preliminary discussion. > > Why do we need AppArmor? > > > AppArmor is a Mandatory Access Control framework implemented as > a Linux Security Module (LSM), user space utilities, and a quite > simple language to define policy. > > AppArmor confines programs according to a set of rules that specify > what operations a given program can access, e.g. it can prevent > exploited server software from accessing data it does not own and > executing arbitrary code. This proactive approach helps protect the > system against some known and unknown vulnerabilities. > > Various actors are actively exploiting software. Random users are > victimized every day, and specific populations are specifically > targeted, e.g. government opponents, human rights defenders, system > administrators, software developers and distributors, as revealed by > the Snowden leaks. > > Every month we learn about many new attack vectors made possible by > programming errors. We fix them after the fact, which is great but > a bit too late: users may already have been exploited. Most operating > systems have adopted proactive approaches to mitigate the impact of > such problems. > > In Debian, great efforts are in progress: hardening binaries makes it > harder to write successful exploits, and making our packages build > reproducibly will make it harder to introduce vulnerabilities at the > binary level. > > Still, Debian is far from being best in class on this front: we have > no widespread mechanism for sandboxing desktop applications. We can > surely do better. The great news is that there is one low-hanging > fruit waiting to be picked, and it's what this proposal is about :) > > A proposal > == > > 1. Enable AppArmor by default in testing/sid as soon as feasible in >the Buster cycle. > >I can think of several possible ways to do it but for now I'd >rather focus on the "do we want to do it at all" conversation. > >If curious some options are listed on the wiki: >https://wiki.debian.org/AppArmor/Progress#Enabling_AppArmor_by_default.3F >Feel free to discuss them on . > >And anyway, you can already opt-in for AppArmor on your system today: >https://wiki.debian.org/AppArmor/HowToUse :) > > > 2. During a year, watch out for AppArmor related issues and address >them in a prompt manner. > >Note that the best way to address them quickly enough is sometimes >to simply disable the problematic AppArmor profile: it's cheap, >doesn't require advanced AppArmor skills, and IMO a smaller >AppArmor policy enabled by default is more useful than a broader >but less robust one that only a couple thousand users benefit from. > > 3. A year after AppArmor was enabled by default: evaluate how it went >and decide if Buster should be shipped with AppArmor enabled by >default or not. > >I commit to do an analysis using BTS data to help make this >decision. If we need formal success criteria and a clearly defined >team who'll make the call, I'm happy to think about it. But here >again I'd rather focus on the general idea than on implementation >details at this point. So, this is just a heads up for people attending Debconf18 in Hsinchu: there is a BoF this afternoon [1] were we would like *you* to share your feelings about it, be they positive or negative, and share skills, tips and tricks. Please, come and join us in room Xueshan (雪山) at 16:00 if you're interested: we're very excited about it! [0] https://lists.debian.org/debian-devel/2017/08/msg00090.html [1] https://debconf18.debconf.org/talks/32-apparmor-in-debian-lets-share-feelings-technical-feedback-and-skills/ Cheers, -- nodens
Re: AppArmor in Debian BoF (was: Let's enable AppArmor by default (why not?))
On 29/07/2018 11:03, Clément Hermann wrote: > So, this is just a heads up for people attending Debconf18 in Hsinchu: > there is a BoF this afternoon [1] were we would like *you* to share your > feelings about it, be they positive or negative, and share skills, tips > and tricks. > > > Please, come and join us in room Xueshan (雪山) at 16:00 if you're > interested: we're very excited about it! And I've been bitten by the slightly moving schedule (it's alive!): it's actually at 16:30: https://debconf18.debconf.org/talks/32-apparmor-in-debian-lets-share-feelings-technical-feedback-and-skills/ Cheers! -- nodens
Re: Looking for maintainers for our project
Hi, On 07/11/2017 09:38, Thomas Goirand wrote: > On 11/06/2017 09:56 AM, b...@coldsource.net wrote: >> Hi everyone, >> >> I work for UFC - Que Choisir (a French consumer association) and we just >> released (GPL3) version 2.0 of our job scheduler evQueue. >> >> Here is the website : http://www.evqueue.net/ >> >> We are providing debian packages (debian 8 and 9) but would like to know >> if it is possible to get some help to provide these packages directly in >> the debian repository. >> >> Thanks for any help ! >> >> Thibault > > Hi, > > Your best hope is probably to maintain it yourself directly in Debian. > For doing so, just prepare the package, upload it to > https://mentors.debian.net/ then search someone to sponsor the upload of > the package in Debian. Details are explained there. > You should also file a WNPP bug (RFP at least, ITP if you give it a go yourself). This is part of the details explained at mentors anyway ;) Cheers, -- nodens
Bug#883488: ITP: golang-gopkg-lxc-go-lxc.v2 -- Go bindings for liblxc
Package: wnpp Severity: wishlist Owner: =?utf-8?q?Cl=C3=A9ment_Hermann?= * Package name: golang-gopkg-lxc-go-lxc.v2 Version : 0.0~git20171109.99ba61b-1 Upstream Author : LXC - Linux Containers * URL : https://github.com/lxc/go-lxc * License : LGPL-2.1 with redistribution exception Programming Lang: Go Description : Go bindings for liblxc go-lxc implements Go bindings for the LXC C API (liblxc). This package is a dependancy for LXD. It will be maintained under pkg-go team umbrella.
Bug#804258: ITP: igb -- dkms source for the igb network driver
Package: wnpp Severity: wishlist Owner: "Clément Hermann" * Package name: igb Version : 5.3.3.2 Upstream Author : Intel Corporation * URL : http://sourceforge.net/projects/e1000/ * License : GPL-2 Programming Lang: C Description : dkms source for the igb network driver igb is the Linux device driver released for Intel 82575/6, 82580, I350, and I210/211-based network interfaces. . This driver uses the same base as the igb module included in the Linux kernel, with added features such as advanced multiqueue control (RSS), interrupts throttle management, Large Receive Offload (LRO) and Low Latency Interrupts (LLI). . Only use this driver if you need these specific features. . Installation of the igb-dkms package will disable the in-kernel igb module. To re-enable igb, the igb-dkms package must be purged. . This package provides the dkms source code for the igb kernel modules. Kernel source or headers are required to compile these modules. I'm already uploader for openpgp-applet, but as it is sponsored by the perl pkg team, I'll need a new sponsor for this one (little sense in asking perl maintainer to sponsor a kernel driver). I'd be happy to co-maintain this package if some people are interested. I mainly use debian and preferably intel NIC for servers at work (and also did so at my previous job), so I'm motivated for the long-term maintenance of this package. Also, once it's in the archive and has migrated to testing, I intend to backport it at least for jessie (possibly wheezy as well). Cheers ! -- Clément Hermann (nodens)
