Contributing without your real name
I had a discussion with someone who wants to contribute to Debian, but doesn't want to publish their real name in fear of getting doxed. I never really thought of this, and I'm not sure how much one can contribute to Debian without posting some kind of real name (sorry if that is already answered somewhere). I'm aware that for sponsored work the name doesn't really matter, but can one become a DM or even a DD? Regards, Stephan
Re: Contributing without your real name
Hey Stephan On 2021/02/25 11:48, Stephan Lachnit wrote: > I never really thought of this, and I'm not sure how much one can > contribute to Debian without posting some kind of real name > (sorry if that is already answered somewhere). > > I'm aware that for sponsored work the name doesn't really matter, > but can one become a DM or even a DD? They would have to share their real name with DAM, and some DDs might want to see their ID when keysigning, but it is entirely possible to work in the public in Debian under a pseudonym. I think this is probably something that needs a paragraph in the nm guide. -Jonathan
Re: New service: https://debuginfod.debian.net
On Wed, Feb 24, 2021 at 4:03 AM Sergio Durigan Junior wrote: > > Hello there, > > I would like to announce a new service that I have just configured for > Debian: https://debuginfod.debian.net. Thanks a lot for this. I used it last night to check a coredump for a ppc64el package and it worked flawlessly. Well almost flawlessly. It had a timeout while pulling one of the debug packages but pulled the missing one when I retried. Really awesome. -- Regards Sudip
Bug#983509: ITP: python-svgelements -- high fidelity SVG parsing and geometric rendering Python library
Package: wnpp Severity: wishlist Owner: Romain Porte X-Debbugs-Cc: debian-devel@lists.debian.org, deb...@microjoe.org * Package name: python-svgelements Version : 1.4.3 Upstream Author : tatarize * URL : https://github.com/meerk40t/svgelements * License : Expat Programming Lang: python Description : high fidelity SVG parsing and geometric rendering Python library The goal is to successfully and correctly process SVG for use with any scripts that may need or want to use SVG files as geometric data. This is both facilitated by, and results in, very useful elements within the SVG spec: Path, Matrix, Angle, Length, Color, Point and other SVG and CSS Elements. The SVG spec defines a variety of elements which generally interoperate. In order to have a robust experience with SVGs one must be able to correctly deal with the parsing and interactions of these elements. This project began as part of meerK40t which does SVG loading of files for laser cutting. It attempts to more fully map out the SVG specification, objects, and paths, while remaining easy to use and largely backwards compatible. These elements are quite useful in their own right. For example, the zooming and panning within meerK40t is done using the SVG matrix which more robust than the wxPython one. Internal console commands within meerK40t allows specifying robustly parsed angles of rotation, colors of objects, and naively uses the Path() and SVGImage objects. The ability to have these robustly manipulated with affine transformations provides considerable utility. There is significant utility in the interactions between these objects, however if one just want to robustly parse some SVG and convert the data to their own structures that is entirely reasonable. Without robust SVG parsing one'll find repeated edge cases of some svg files that do not parse correctly. svgelements aims to avoid those pitfalls with robust adherence to the SVG spec. I intent to maintain this package under the Debian Python Team.
Bug#983520: ITP: netproc -- tool to monitor network usage by processes
Package: wnpp Severity: wishlist Owner: Mayco Souza Berghetti * Package name: netproc Version : 0.5.5 Upstream Author : Mayco Souza Berghetti * URL : https://github.com/berghetti/netproc/ * License : GPL-3+ Programming Lang: C Description : tool to monitor network usage by processes Netproc monitors network traffic and tries to find out which process this traffic belongs to, this is useful to identify the processes that are consuming network resources and troubleshooting. I intend on maintaining this package, looking for a sponsor. Att. Mayco S. berghetti
Re: Contributing without your real name
Stephan Lachnit wrote on 25/02/2021: I had a discussion with someone who wants to contribute to Debian, but doesn't want to publish their real name in fear of getting doxed. I never really thought of this, and I'm not sure how much one can contribute to Debian without posting some kind of real name (sorry if that is already answered somewhere). In my understanding Key Endorsements allow this, see: https://lists.debian.org/debian-devel-announce/2020/11/msg3.html https://lists.debian.org/debian-devel-announce/2020/09/msg0.html Paride
Bug#983523: general: some WWW sites no longer work neither in Firefox nor in Chrome
Package: general Severity: normal I was angry with my Internet provider because on their site since several weeks the chat was reported as not available. It appeared the chat works all the time in any Windows browser. Today I tried to order some goods by Internet, by I was unable to select the interesting items with a click neither in Firefox nor in Chrome. Again it appeared that it works in any Windows browser. Please reassign as appropriate. Best regards Janusz -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- , Janusz S. Bien emeryt (emeritus) https://sites.google.com/view/jsbien
Re: Bug#983523: general: some WWW sites no longer work neither in Firefox nor in Chrome
On Thu, Feb 25, 2021 at 04:32:21PM +0100, Janusz S. Bień wrote: > Package: general > Severity: normal > > I was angry with my Internet provider because on their site since > several weeks the chat was reported as not available. It appeared the > chat works all the time in any Windows browser. > > Today I tried to order some goods by Internet, by I was unable to select > the interesting items with a click neither in Firefox nor in > Chrome. Again it appeared that it works in any Windows browser. > > Please reassign as appropriate. > > Best regards > > Janusz > > -- System Information: > Debian Release: 10.8 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.19.0-14-amd64 (SMP w/12 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US:en (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled What have you tried to fix your connectivity? File a bug report properly via 'reportbug' command and list what you've done in terms of troubleshooting in that report.
Bug#983523: general: some WWW sites no longer work neither in Firefox nor in Chrome
This really is a useless bug report. How can anyone try to duplicate it? You do not tell anyone who your internet provider is, How you try to get the "chat", what internet site you go to, and what kind of goods you select. In linux.debian.devel, you wrote: > Package: general > Severity: normal > > I was angry with my Internet provider because on their site since > several weeks the chat was reported as not available. It appeared the > chat works all the time in any Windows browser. > > Today I tried to order some goods by Internet, by I was unable to select > the interesting items with a click neither in Firefox nor in > Chrome. Again it appeared that it works in any Windows browser. >
Bug#983523: general: some WWW sites no longer work neither in Firefox nor in Chrome
On Thu, Feb 25 2021 at 10:27 -08, William Unruh wrote: > This really is a useless bug report. How can anyone try to duplicate it? > You do not tell anyone who your internet provider is, How you try to get > the "chat", what internet site you go to, and what kind of goods you > select. The chat is available only for the logged customer of the Internet provider. FYI, it is Multimedia - does it really help? On the other hand you can pretend to be a potential customer of https://kucharekszesc.pl/pl/ (I'm afraid the site is available only in Polish). Anyway a clue should be provided by the fact the both (perhaps all?) browsers are affected. The things broke several weeks ago, perhaps after the upgrade to 10.8. Best regards janusz -- , Janusz S. Bien emeryt (emeritus) https://sites.google.com/view/jsbien
Re: New service: https://debuginfod.debian.net
Frank's original reply didn't make it to the list for some reason and
has also gone missing on his end so resending on his request.
On Wed, 2021-02-24 at 15:23 -0500, Frank Ch. Eigler wrote:
---
Hi, Ian -
ijc wrote:
> [...]
> What are the security implications for users/clients of using this or
> more importantly enabling it by default?
Good questions. (I'm a debuginfod upstream developer.)
> Presumably clients have to trust that the server is not going to feed
> them malicious debug info. Are the tools which consume this information
> written to operate on completely untrusted inputs? It seems like many
> of them could have been written historically with the assumption that
> their inputs are mostly to be trusted. I suppose the use https helps
> mitigate this at least a bit when it comes to a debian.{org,net}
> service.
Indeed, technical measures like packaging level crypto-signatures become
inapplicable, since individual files are transferred. However, IMHO the
concern is substantially mitigated, if distro users connect securely to
trusted servers that index trusted content.
> What about information leakage? apart from debugids does this leak
> anything else to the server? On a quick look it seems like it might
> potentially leak source code paths (at least the leaf bits) to things
> being debugged -- does this mean that if a user is debugging private
> software (perhaps unpublished or perhaps proprietary software for
> $work) on a Debian system they are at risk of leaking the source
> filenames if they run gdb on one of their binaries while debugging?
> This might be a problem if it comes to enabling this transparently.
Yes, it might. On the other hand, this is mitigated by a few aspects.
Mainly, debuginfod clients like gdb only call out to the system in case
they have failed to look up the needed data another way. So if you're
debugging local software built normally, the buildids / source names
won't leak because the debugger will find them locally, and debuginfod
servers are not consulted.
Users who debug secret software but still wish to use internal
debuginfod distribution for it, can do so by setting up a personal
debuginfod instance whereever the secret stuff is held, and configure
that server to federate upstream to the public server. That way, the
public server will only see traffic that the local one couldn't satisfy.
Do these considerations overcome the concerns, so as to provide a
comfortable out-of-the-box experience for most users?
- FChE
New IRC Server
We are happy to move the old IRC server to the new one (ircfree2021.duckdns.org) right now. You can now connect to our new IRC server offered by IRCFree2021. Use: Server: ircfree2021.duckdns.org Port: 6667 There are no services, but you can still manage operators, etc.
Re: New service: https://debuginfod.debian.net
On Thursday, February 25 2021, Ian Campbell wrote: >> What about information leakage? apart from debugids does this leak >> anything else to the server? On a quick look it seems like it might >> potentially leak source code paths (at least the leaf bits) to things >> being debugged -- does this mean that if a user is debugging private >> software (perhaps unpublished or perhaps proprietary software for >> $work) on a Debian system they are at risk of leaking the source >> filenames if they run gdb on one of their binaries while debugging? >> This might be a problem if it comes to enabling this transparently. > > Yes, it might. On the other hand, this is mitigated by a few aspects. > Mainly, debuginfod clients like gdb only call out to the system in case > they have failed to look up the needed data another way. So if you're > debugging local software built normally, the buildids / source names > won't leak because the debugger will find them locally, and debuginfod > servers are not consulted. > > Users who debug secret software but still wish to use internal > debuginfod distribution for it, can do so by setting up a personal > debuginfod instance whereever the secret stuff is held, and configure > that server to federate upstream to the public server. That way, the > public server will only see traffic that the local one couldn't satisfy. > > Do these considerations overcome the concerns, so as to provide a > comfortable out-of-the-box experience for most users? Thanks for the reply, Frank. As I said in the announcement message, I have proposed a Merge Request against elfutils in order to enable the automatic usage of our debuginfod server. I know that there are people who are not comfortable with having a debugger consult a remote server "behind their backs", so a possible mitigation to this issue would be to have a debconf question asking whether the user wants to enable system-wide debuginfod usage or not. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
Re: Contributing without your real name
On 16055 March 1977, Stephan Lachnit wrote: I never really thought of this, and I'm not sure how much one can contribute to Debian without posting some kind of real name (sorry if that is already answered somewhere). I'm aware that for sponsored work the name doesn't really matter, but can one become a DM or even a DD? Yes, this is possible and we do have developers with pseudonyms in Debian already. DAM gets to know the real name and keeps it confidential. Interesting point is to build up a good reputation for the pseudonym, same as for anyone else. Key signing - well, key endorsements appear to make this part a little easier, but various people do sign keys of pseudonyms too, when they are sure that the key does belong to the person with that handle. So yeah, possible, probably a little easier nowadays. -- bye, Joerg
ftpmaster review reply Re: Comments regarding chroma_1.18-1_multi.changes
Hi. Thanks for looking at this package.
Because I believe in Debian's value of transparency I decided to CC
this reply to a public list. I didn't think there was a better list
than -devel. Readers of -devel will find references etc. below [1].
Sean Whitton writes ("Comments regarding chroma_1.18-1_multi.changes"):
> From reading work/resources/README, it seems to me that the
> reverse-engineerings of old games and the conversion scripts need to go into
> contrib, because they're useless without a copy of the original ROMs of those
> games?
I'm quite surprised by this comment.
Firstly, everything in that directory is completely DFSG-free in
itself.
Secondly, almost all of its contents are input files and scripts which
are actually used by the main build system to process the DFSG-free
input files (svgs, etc.) into the files which are shipped in the
.deb. So an integral part of the source code for the DFSG-free .deb.
The only thing which is useless without non-free ROMs is the script
resources/browser/convert2chroma.pl [2]. Obviously therefore this
script is not run at build time and is not shipped in the .deb.
The difficulty you are having here seems to be simply that this one
DFSG-free script, not shipped in any .deb, and not run during the
package build, is not useful as part of a completely-DFSG-free
workflow.
Are you really telling me that we have to strip out from the *source
package*, fully DFSG-free ancillary files which are shipped for
convenience by upstream in the same source tree ? Merely because they
are not used in Debian and don't ahve fully Free uses ?
By that rule any script (or maybe even documentation) in any source
package which is there to help work with proprietary data or on
proprietary systems would have to be thrown out (and the corresponding
source package laundered).
I don't see how this would benefit our users or protect Debian or
anything. And there must surely be many contrary examples of this in
Debian. It is very common for upstreams to provide ancillary stuff in
source packages which we in Debian don't use or ship. [3] They do
this for everyone's convenience and it causes no trouble. Until now :-/.
I hope my explanation is sufficient to get this package accepted.
Thanks,
Ian.
[1] I am replying here to ftpmaster comments on source package
"chroma" which I uploaded as sponsor on the 18th of January. Simon
Tatham, CC'd, is the upstream author and Debian maintainer. The
un-ACCEPTed source package can be obtained by Debian Members with
dgit --for-push clone chroma
as tag archive/debian/1.18-1 (at least unless it is REJECTed).
[2] I have doubled checked this with Simon, the upstream author.
[3] Should we DFSG-launder the Windows support out of our compiler
source packages ? That sounds like fun.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Re: ftpmaster review reply Re: Comments regarding chroma_1.18-1_multi.changes
Hello, On Thu 25 Feb 2021 at 09:02PM GMT, Ian Jackson wrote: > Firstly, everything in that directory is completely DFSG-free in > itself. Right, which is why we're discussing contrib, not non-free. > Secondly, almost all of its contents are input files and scripts which > are actually used by the main build system to process the DFSG-free > input files (svgs, etc.) into the files which are shipped in the > .deb. So an integral part of the source code for the DFSG-free .deb. > > The only thing which is useless without non-free ROMs is the script > resources/browser/convert2chroma.pl [2]. Obviously therefore this > script is not run at build time and is not shipped in the .deb. > > The difficulty you are having here seems to be simply that this one > DFSG-free script, not shipped in any .deb, and not run during the > package build, is not useful as part of a completely-DFSG-free > workflow. > > Are you really telling me that we have to strip out from the *source > package*, fully DFSG-free ancillary files which are shipped for > convenience by upstream in the same source tree ? Merely because they > are not used in Debian and don't ahve fully Free uses ? > > By that rule any script (or maybe even documentation) in any source > package which is there to help work with proprietary data or on > proprietary systems would have to be thrown out (and the corresponding > source package laundered). > > I don't see how this would benefit our users or protect Debian or > anything. And there must surely be many contrary examples of this in > Debian. It is very common for upstreams to provide ancillary stuff in > source packages which we in Debian don't use or ship. [3] They do > this for everyone's convenience and it causes no trouble. Until now :-/. Firstly, it's worth noting that when it comes to the requirements for the archive areas main/contrib/non-free, the distinction between source and binary packages is not relevant. In this case, I had thought that more than just convert2chroma.pl was useless without proprietary ROMs, but I wasn't sure, why is why I wrote to you. On the difference between main and contrib, Policy is worded in terms of whole packages -- "None of the packages in the *main* archive area require software outside of that area to function." It would be disingenuous to claim that as a result of this single perl script, the whole chroma /package/ "requires software outside of main to function". So I think it is fine to accept to main indeed. However, I would like the opinion of a more experienced ftp team member. So I've removed the internal note I'd put on the package in NEW, so that someone else can more readily take a look. -- Sean Whitton signature.asc Description: PGP signature
Work-needing packages report for Feb 26, 2021
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1197 (new: 0) Total number of packages offered up for adoption: 214 (new: 1) Total number of packages requested help for: 61 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. No new packages have been orphaned, but a total of 1197 packages are orphaned. See https://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: pencil2d (#983252), offered 4 days ago Description: Create hand-drawn animation using both bitmap and vector graphics Installations reported by Popcon: 432 Bug Report URL: https://bugs.debian.org/983252 213 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 866 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc courier-webadmin cvsweb debbugs-web doc-central dwww (137 more omitted) Installations reported by Popcon: 96997 Bug Report URL: https://bugs.debian.org/910917 asciio (#968843), requested 187 days ago Description: dynamically create ASCII charts and graphs with GTK+2 Installations reported by Popcon: 74 Bug Report URL: https://bugs.debian.org/968843 aufs (#963191), requested 250 days ago Description: driver for a union mount for Linux filesystems Reverse Depends: fsprotect Installations reported by Popcon: 13268 Bug Report URL: https://bugs.debian.org/963191 autopkgtest (#846328), requested 1548 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker sbuild-qemu Installations reported by Popcon: 1220 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 3441 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 656 Bug Report URL: https://bugs.debian.org/642906 broadcom-sta (#886599), requested 1144 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1707 Bug Report URL: https://bugs.debian.org/886599 cargo (#860116), requested 1416 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 1939 Bug Report URL: https://bugs.debian.org/860116 courier (#978755), requested 56 days ago Description: Courier mail server Reverse Depends: courier-faxmail courier-filter-perl courier-imap courier-ldap courier-mlm courier-mta courier-pcp courier-pop courier-webadmin couriergrey (3 more omitted) Installations reported by Popcon: 1034 Bug Report URL: https://bugs.debian.org/978755 cyrus-imapd (#921717), requested 748 days ago Description: Cyrus mail system - IMAP support Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication Installations reported by Popcon: 427 Bug Report URL: https://bugs.debian.org/921717 cyrus-sasl2 (#799864), requested 1982 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base adcli autofs-ldap cyrus-caldav cyrus-clients cyrus-common cyrus-dev cyrus-imapd cyrus-imspd cyrus-murder (78 more omitted) Installations reported by Popcon: 204215 Bug Report URL: https://bugs.debian.org/799864 dbad (#947550), requested 425 days ago Description: dnsmasq-based ad-blocking using pixelserv Bug Report URL: https://bugs.debian.org/947550 debtags (#962579), requested 260 days ago Description: Debian Package Tags support tools Reverse Depends: packagesearch Installations reported by Popcon: 1559 Bug Report URL: https://bugs.debian.org/962579 dee (#831388), requested 1686 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 gir1.2-unity-7.0 libdee-dev libunity-dev libunity-protocol-private0 libunity-tools libunity9 zeitgeist-core Installations reported by Popcon: 27492 Bug Report URL: https://bugs.debian.org/831388 developers-reference (#759995), requested 2371 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 5020 Bug Report URL: https://bugs.debian.org/759995 de
Bug#983523: general: some WWW sites no longer work neither in Firefox nor in Chrome
On Thu, Feb 25, 2021 at 6:45 PM Janusz S. Bień wrote: > Anyway a clue should be provided by the fact the both (perhaps all?) > browsers are affected. The things broke several weeks ago, perhaps after > the upgrade to 10.8. Please try some of the following things to narrow down where the problem is: Create a new user account on your computer and check if the problem occurs there. Create a new Firefox browser profile and check if the problem occurs there. Open up the Firefox/Chrome developer tools (F12 in Firefox) and check for any errors or warnings in the Console and Network tabs after reloading the page. Use the Debian wayback archive to switch back to an older version of the browsers to test if this is caused by the Debian upgrade or not. Please note that the older Firefox will not be able to open your current profile created by the newer Firefox, so create a new profile for the older version, you will be able to access the current profile after upgrading again. https://snapshot.debian.org/ -- bye, pabs https://wiki.debian.org/PaulWise
Bug#983523: general: some WWW sites no longer work neither in Firefox nor in Chrome
On Fri, Feb 26 2021 at 3:26 +00, Paul Wise wrote: > On Thu, Feb 25, 2021 at 6:45 PM Janusz S. Bień wrote: > >> Anyway a clue should be provided by the fact the both (perhaps all?) >> browsers are affected. The things broke several weeks ago, perhaps after >> the upgrade to 10.8. > > Please try some of the following things to narrow down where the problem is: Thank you very much for a constructive answer. [...] > Use the Debian wayback archive to switch back to an older version of > the browsers to test if this is caused by the Debian upgrade or not. I have some earlier version of Debian on virtual machines and I see that my hypothesis that the culprit is the recent upgrade was wrong. The problem occurs already in a December version. I will investigate first the console output for the chat site, there are some messages which can give a hint. When I click to select an item on the other site there is no console output at all. Best regards Janusz -- , Janusz S. Bien emeryt (emeritus) https://sites.google.com/view/jsbien
