Re: archive.debian.org mirrors

On Sun, 2024-04-28 at 07:04 +0200, Johannes Schauer Marin Rodrigues wrote: > speaking of mirroring problematic debian.org services [1] by adding more > copies > of terabytes of data [2]: is there an update of the situation regarding > snapshot.d.o? I do not see any activity in bugs like #1050815

Re: Permission to distribute

On Thu, 2024-04-04 at 01:01 -0700, John Lee wrote: > I just wondered if I can sell computers that I build with Debian > Linux pre-installed. The computers may also include programs I > create. I tried to find the answer to this question but still > unsure.  In addition to the other response you

Re: Debian testing/unstable users: beware of Firefox critical CVEs

On Sun, 2024-03-24 at 22:45 +, Samuel Henrique wrote: > I'm sending this to d-devel because there should be a lot of testing and > unstable users on this list. If you're not running firefox 124.0.1 or > firefox-esr 115.9.1esr-1, you should find a way of upgrading to those > versions.

Re: Any way to install packages+run autopkgtests on porterbox machines?

On Sun, 2024-03-03 at 10:20 -0800, Ross Vandegrift wrote: > Not exactly an answer, but an alternative - it's easy to get an ARM VM from > many cloud providers.  For a buck or two, I've avoided hours of futzing with > the porterboxes.  I've heard of providers with PPC, but haven't ever actually >

Re: Editor extensions to help editing debian/* files?

On Thu, 2024-01-25 at 22:22 -0800, Otto Kekäläinen wrote: > Yeah, I remember looking into cats some years back as a place to learn > what commands exist. Similarly I also occasionally browse > https://pre-commit.com/hooks.html. Yeah, there are lots of other tools similar to cats, many of them

Re: Proposal for how to deal with Go/Rust/etc security bugs

On Thu, 2024-01-25 at 00:24 +, Wookey wrote: > People keep telling us (@ARM) how marvellous Rust is, and we keep > telling them that it's useless in the real world until it sorts out > the stable ABI/dynamic linking problem. IIRC that has been worked on for some years now, and IIRC the

Re: Editor extensions to help editing debian/* files?

On Sat, 2024-01-20 at 23:43 -0800, Otto Kekäläinen wrote: > PS. Related, these are commands I frequently run manually but don't > have any editor integration for: Thats beginning to look like the history of check-all-the-things. Initially I maintained such a list of commands on the wiki:

Re: Debtags: understanding the heuristics of "Checks and hints" in the online editor

On Sat, 2024-01-20 at 09:40 +0100, Jonas Smedegaard wrote: > I am (very) willing to act as service maintainer. Please get in touch with the debtags team about this. https://wiki.debian.org/Teams/DebTags https://salsa.debian.org/groups/debtags-team/-/group_members > I have interest myself in

Re: Debtags: understanding the heuristics of "Checks and hints" in the online editor

On Fri, 2024-01-19 at 18:24 +0100, André Maroneze wrote: > I want to use debtags metadata for a research project The debtags service is planned to be shutdown and the data no longer published, as there is no-one in Debian who wants to maintain it.

Re: Limited security support for Go/Rust? Re ssh3

On Mon, 2024-01-15 at 10:17 +0100, Bastian Blank wrote: > I asked for practical solutions, not theoretical ones.  We don't have a > suitable way to rebuild all packages just because right now. There are some ideas on the static linking wiki page: https://wiki.debian.org/StaticLinking Probably

Re: Running Lintian against a debian/ directory?

ian tool with minor      modifications.         * debian/{lintian.links,manpages}:        + [NT] Install spellintian in PATH and install its manpage.          Thanks to Paul Wise for the suggestion.  (Closes: #767867)        -- Niels Thykier   Sun, 28 Jun 2015 14:08:29 +0200 -- bye, pabs https://wiki.

Re: Running Lintian against a debian/ directory?

On Fri, 2023-12-22 at 16:43 +0800, Otto Kekäläinen wrote: > Currently Lintian requires a (source or binary) package to check[1]. (and some checks require *both* source and binary packages available) > Is anyone aware of a way to run lintian directly on a debian/ > directory contents as-is

Re: What would help the most?

On Fri, 2023-10-27 at 14:00 -0500, Lukasz Szybalski wrote: > What is the minimum most value thing that would > help YOU accomplish your goals for Debian ? Check out this page if no-one gives anything more specific: https://www.debian.org/intro/help -- bye, pabs

Re: Hyphens in man pages

On Tue, 2023-10-24 at 05:40 +, Tobias Frost wrote: > Am 24. Oktober 2023 03:43:29 UTC schrieb Paul Wise: > > > BTW: as a Debian member, you have access to a gratis subscription: > > > > https://wiki.debian.org/MemberBenefits#LWN > > AFAIK this is no longe

Re: Hyphens in man pages

On Mon, 2023-10-23 at 11:17 -0500, G. Branden Robinson wrote: > https://lwn.net/Articles/947941/ > > Would someone be willing to send me a subscriber-sponsored link to it? BTW: as a Debian member, you have access to a gratis subscription: https://wiki.debian.org/MemberBenefits#LWN -- bye,

Re: QDMR on Raspberry Pi OS?

On Tue, 2023-10-10 at 01:28 +, Dan Tallant wrote: > curious about bringing the QDMR cps software for Linux to the > Raspberry Pi os (specifically 64 bit running on the Pi4 w/8gb RAM) As mentioned by Carsten on the list, qdmr is already available in Debian for arm64 since the bookworm

Re: Is there a generic canonical way for a package script to check network connectivity?

On Sun, 2023-10-08 at 22:49 -0400, Jonathan Kamens wrote: > I need to be able to tell from one of my package scripts whether the > host has networking connectivity. Which package and why do the maintainer scripts need network? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc

Re: allow missing description fields and empty long descriptions for Rust/etc packages?

On Fri, 2023-09-22 at 14:40 +0800, Paul Wise wrote: > Personally I think this boilerplate has little to no value, cutting the > long sentence down to something like just "Rust crate foo" would help This change has now been merged and will reach Debian eventually: https://salsa

Re: lpr/lpd

On Mon, 2023-09-25 at 12:08 +0900, Simon Richter wrote: > What I'd like to see is something like ... > No installed packages are looking for a new maintainer. That is what how-can-i-help does, except it doesn't print anything when there have been no changes to the status of packages on the

Re: lpr/lpd

On Mon, 2023-09-25 at 12:08 +0900, Simon Richter wrote: > What I'd like to see is something like > > No installed packages are looking for a new maintainer. That is what how-can-i-help does, except it doesn't print anything when there have been no changes to the status of packages on the

Re: lpr/lpd

On Fri, 2023-09-22 at 23:07 +0900, Simon Richter wrote: > One thing I'd think might help would be a tag in the package database > that is derived from WNPP status, which would allow the summary output > at the end of installs also list packages that are installed that are > currently in RFA or O

Re: lintian.debian.org off ?

On Fri, 2023-09-22 at 09:27 +0200, Jérémy Lal wrote: > Host lintian.debian.org not found: 3(NXDOMAIN) > > is this expected ? Yes, it is replaced by the UDD interface: https://wiki.debian.org/Services/lintian.debian.org https://udd.debian.org/lintian/ There is no web based location for the

Re: allow missing description fields and empty long descriptions for Rust/etc packages?

On Thu, 2023-09-21 at 19:05 +0200, Fabian Grünbichler wrote: > the structured metadata of crates only has a short description[0] Would the Debian Rust team be willing to talk to the upstream Rust community on adding the concept of crate long descriptions? > which is often also not very

allow missing description fields and empty long descriptions for Rust/etc packages?

Hi all, I have noticed that almost all Rust packages in Debian have boilerplate long descriptions that aren't very useful to Debian users. The only useful info is the crate name, but that is also in the package name. As far as I know they inherit this property from the upstream Rust crates,

Re: Default font: Transition from DejaVu to Noto

On Wed, 2023-09-13 at 21:09 +0200, Gunnar Hjalmarsson wrote: > So we have a conflict of goals here. The good news is that a user who > speaks some latin language, and who thinks it's important to be able to > easily select font directly in various applications, can do: > > apt purge

Re: Default font: Transition from DejaVu to Noto

On Sun, 2023-09-10 at 11:34 -0400, The Wanderer wrote: > Rather than discussing only Noto vs. DejaVu, is there any possibility of > reintroducing Bitstream Vera as a default-font option (even if with a > low priority), for systems which have that installed? IIRC DejaVu is a fork of and similar

Re: Default font: Transition from DejaVu to Noto

On Sat, 2023-09-09 at 23:08 +0200, Gunnar Hjalmarsson wrote: > My personal view is that it is a change in the right direction, and I > have taken a couple of follow-up steps in Debian. There are still loose > ends and more work to be done to achieve a consistent configuration in > this respect.

Re: debian/copyright format and SPDX

On Fri, 2023-09-08 at 12:09 +0530, Hideki Yamane wrote: > Making appropriate debian/copyright file is hard and boring task, IMHO Using scancode-toolkit/etc can probably automate most of that work. https://wiki.debian.org/CopyrightReviewTools -- bye, pabs https://wiki.debian.org/PaulWise

Re: __pycache__ directories (Re: Potential MBF: packages failing to build twice in a row)

On Mon, 2023-08-14 at 22:09 +0200, Michael Biebl wrote: > I received a couple of bug reports against packages I (co) maintain > regarding this issue and having a quick look, quite a few fail due to > python scripts being run during the build and creating a __pycache__ > directory. I recommend

Re: Potential MBF: packages failing to build twice in a row

On Sun, 2023-08-13 at 22:28 +0200, Johannes Schauer Marin Rodrigues wrote: > > dpkg-source: info: local changes detected, the modified files are: > >   plakativ-0.5.1/plakativ.egg-info/SOURCES.txt > > since this issue seems to be affecting a few more packages than plakativ, I > wanted to ask here

Re: Potential MBF: packages failing to build twice in a row

On Sun, 2023-08-13 at 21:18 +, Jeremy Stanley wrote: > Similarly, I got one for __pycache__/*.cpython-311.pyc file > overwrites... is that something dh_python should clean? Probably just send upstream a change removing them? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc

Re: Potential MBF: packages failing to build twice in a row

On Tue, 2023-08-15 at 09:21 -0400, Boyuan Yang wrote: > --- ibus-array-0.2.2.orig/po/zh_TW.po > +++ ibus-array-0.2.2/po/zh_TW.po > @@ -6,7 +6,7 @@ msgid "" >  msgstr "" >  "Project-Id-Version: ibus-array 0.2.2\n" >  "Report-Msgid-Bugs-To: https://github.com/lexical/ibus-array/issues\n; >

Re: Potential MBF: packages failing to build twice in a row

On Sat, 2023-08-05 at 17:29 +0100, Simon McVittie wrote: > Devref §6.8.8.2 also says that "it is common for Debian users who > need to build software for non-Debian platforms to fetch the source > from a Debian mirror rather than trying to locate a canonical upstream > distribution point", but

Re: Potential MBF: packages failing to build twice in a row

On Sat, 2023-08-05 at 17:06 +0200, Lucas Nussbaum wrote: > I wonder what we should do, because 5000+ failing packages is a lot... Add a message about this on tracker.debian.org for affected packages? > Should we give up on requiring a 'clean' target that works? After all, > when 17% of packages

Re: autodep8 test for C/C++ header

On Tue, 2023-08-08 at 11:42 +0300, Adrian Bunk wrote: > An additional check with some overlap would be whether >    pkgconf --cflags .pc > returns 0 for every pkgconfig file in a package. piuparts runs adequate, which runs something similar:    pkg-config --exists --print-errors .pc It emits

Re: autodep8 test for C/C++ header

On Tue, 2023-08-08 at 18:32 +0300, Adrian Bunk wrote: > Manual opt-in for our > 11k -dev packages is a significant cost > that would have to be justified by the people who oppose opt-out. You could use the Janitor to do automatic opt-in where it works, IIRC the Janitor runs autopkgtests before

Re: The future of mipsel port

On Sun, 2023-08-06 at 13:54 +0200, Florian Lohoff wrote: > I am late to the party but as i mentioned a couple times on debian-mips > already i'd like to keep mipsel as a debian-port - and i'd like to > revert away from mips32r2 back to mips2/mips3 - That change (with > stretch) basically dropped

Re: HFS/HFS+ are insecure

On Sat, 2023-07-22 at 12:11 +, Jeremy Stanley wrote: > When the user has plugged in something that they don't realize > contains a USB storage device, perhaps because it's attached to an > internal hub within a device which has other purposes. Probably it would be a good idea for Debian

Re: HFS/HFS+ are insecure

On Sat, 2023-07-22 at 08:54 +0100, Matthew Garrett wrote: > When is a user going to plug in a USB stick and *not* click that button? When they found a USB stick in the parking lot, plugged it in, got the error dialog & only then remembered their company security training :) -- bye, pabs

Re: HFS/HFS+ are insecure

On Fri, 2023-07-21 at 10:28 +, Bastien Roucariès wrote: > Long term solution will be to push under fuse these filesystem. > This a (short term)/(medium term band aid) solution. That still potentially exposes insecure code to untrusted data, just in a user context rather than a kernel

Re: The future of mipsel port

On Tue, 2023-07-18 at 12:45 +0800, YunQiang Su wrote: > As CIP United, we do maintain an unofficial port of mipsel. > So I wish that Debian can still accept our patch to support mipsel > port (source only). > https://repo.oss.cipunited.com/debian/ The closest Debian has to source-only ports are

Re: usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]

On Mon, 2023-07-17 at 07:16 +0200, Helmut Grohne wrote: > Then I found trei...@debian.org using edos-file-overwrite. That latter > one seems like what I need here. Should we move it to the qa space and > drop the edos part? I suggest debian...@lists.debian.org usertags > file-overwrite. 

Re: Re: systmd-analyze security as a release goal

On Sun, 2023-07-09 at 18:02 +0100, Luca Boccassi wrote: > Note that we already have such a package in the archive: dbus-broker. > It has been the default in Fedora for a long time, and it will be the > default in Ubuntu in the future. It has been available in Debian since > Bullseye - please help

Re: Policy consensus on transition when removing initscripts.

On Tue, 2023-06-27 at 09:36 +0100, Luca Boccassi wrote: > That has been implemented a long time ago, services can set > ProtectProc= so that processes run with hidepid: > > https://freedesktop.org/software/systemd/man/systemd.exec.html#ProtectProc= Thats opt-in and for services only, there are

Re: Policy consensus on transition when removing initscripts.

On Mon, 2023-06-26 at 20:04 -0400, nick black wrote: > furthermore, this is only true when procfs is mounted with a > nonzero hidepid, right? I note that systemd does not support non-zero hidepid, so procfs hidepid will always be off on systemd based systems:

Re: MBF: packages shipping init scripts without corresponding systemd units

On Sun, 2023-06-25 at 22:31 +0100, Luca Boccassi wrote: > Now the generator is also on the way to be deprecated and removed. ... > Therefore I filed a bug against all affected packages ... Will the generator be available separately for people who have packages not in Debian that still only have

Re: [Pkg-opencl-devel] opencl-icd virtual package(s)?

On Mon, 2023-06-19 at 11:04 +0100, Simon McVittie wrote: > Older Intel integrated GPUs are not very fast anyway, so this might not > be a particularly significant loss. Plenty fast enough to run the FOSS 3D games in Debian like 0ad though. -- bye, pabs https://wiki.debian.org/PaulWise

Re: Default network configuration system (was Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie)

On Tue, 2023-06-20 at 11:19 +0200, Lukas Maerdian wrote: > Netplan allows to configure both of those tools and is already being > used across Ubuntu and in Debian cloud-images for this purpose. All > while keeping full flexibility to use the underlying tool's native > config files, should

Re: [Pkg-opencl-devel] opencl-icd virtual package(s)?

On Sun, 2023-06-18 at 07:28 +0100, Rebecca N. Palmer wrote: > Hence, such a package would need to Depend on or Recommend *all* the > ICDs, similar to xorg-xserver-video-all. Ah. So considering what Vincent said, something like this?    Package: some-opencl-using-package    Recommends:

opencl-icd virtual package(s)?

[BCCed to OpenCL ICD implementation package maintainers] I noticed that some packages have a dep on specific OpenCL ICD packages, but don't dep on the opencl-icd virtual package(s). Presumably any of the OpenCL ICDs work for most packages? $ grep-aptavail --no-field-names --show-field Package

Re: Mass bug filing / call for testing: dependencies on SDL 1.2

On Mon, 2023-06-12 at 17:24 +0100, Simon McVittie wrote: > SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives > upstream maintenance or releases. Maintained software that uses SDL 1.2 > should be ported to SDL 2. It was pointed out to me on IRC that some SDL 1.2 extension

Re: Bug#1037250: ITP: fangfrisch -- Update and verify unofficial Clam Anti-Virus signatures

On Sat, 2023-06-10 at 09:50 -0400, Scott Kitterman wrote: > It does, but I think Fangfrisch is still a useful thing to have in Debian. I wonder if there is any tool that generates and/or contains the appropriate ClamAV configs for popular unofficial signatures, rather than manually downloading

Re: Bug#1037250: ITP: fangfrisch -- Update and verify unofficial Clam Anti-Virus signatures

On Fri, 2023-06-09 at 12:46 +0200, Gürkan Myczko wrote: >    Description : Update and verify unofficial Clam Anti-Virus signatures >   This is a sibling of the Clam Anti-Virus freshclam utility. It allows >   downloading virus definition files that are not official ClamAV canon, >   e.g. from

Re: 64-bit time_t transition for 32-bit archs: a proposal

On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote: > 2. i386 as a multiarch foreign architecture to run legacy binaries on >    modern x86_64 systems >    2a. legacy native Linux i386 binaries >    2b. legacy Windows i386 binaries via Wine (which requires a somewhat >    complete i386

Re: 64-bit time_t transition for 32-bit archs: a proposal

On Thu, 2023-06-08 at 08:57 +, Holger Levsen wrote: > You mean by somehow refreshing the signatures there? Some ideas for that are here: https://bugs.debian.org/763419 https://bugs.debian.org/820423 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a

Re: 64-bit time_t transition for 32-bit archs: a proposal

On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote: > 2. i386 as a multiarch foreign architecture to run legacy binaries on >    modern x86_64 systems Are these use-cases likely to work with future library ABIs, or do they need old library ABIs from when the binaries were compiled? >   

Re: 64-bit time_t transition for 32-bit archs: a proposal

On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote: > 2. i386 as a multiarch foreign architecture to run legacy binaries on >    modern x86_64 systems >    2a. legacy native Linux i386 binaries >    2b. legacy Windows i386 binaries via Wine (which requires a somewhat >    complete i386

Re: 64-bit time_t transition for 32-bit archs: a proposal

On Tue, 2023-06-06 at 12:45 -0700, Steve Langasek wrote: > since we don't really have an "i386 porting team" The release team have registered Adrian Bunk as an i386 porter: https://release.debian.org/testing/arch_spec.yaml -- bye, pabs https://wiki.debian.org/PaulWise signature.asc

Re: 64-bit time_t transition for 32-bit archs: a proposal

On Tue, 2023-06-06 at 09:33 +0200, Helmut Grohne wrote: > I've been reading the discussion around i386 a bit and found the > direction it has taken a little unproductive. I note that there are a number of packages available on i386 but not available on amd64, is anyone planning on an MBF about

Re: 64-bit time_t transition for 32-bit archs: a proposal

On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote: > When considering the future of i386, a factor that we need to bear in > mind is that there are two major use-cases for i386, with requirements > that sometimes conflict: There was another option mentioned earlier in the thread that could

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

On Wed, 2023-05-31 at 00:51 +0200, Diederik de Haas wrote: > I would be VERY disappointed if Debian would abandon people who do NOT have > the means to just buy new equipment whenever they feel like it. There are Debian contributors who are in this position (although perhaps not with i386

Re: Future of GNU/kFreeBSD in the debian-ports archive

On Mon, 2023-05-29 at 18:11 +0200, Aurelien Jarno wrote: > I would like to emphasize that packages will still be available on > snapshot.d.o for anyone interested in reviving the port. And the new port docs mention the potential procedures involved: https://wiki.debian.org/PortsDocs/New --

Re: Bug#1035110: ITP: drminfo -- Small utility to dump info about DRM devices

On Sat, 2023-04-29 at 15:13 -0600, Rodrigo Siqueira wrote: > * Package name    : drminfo > * URL : https://gitlab.freedesktop.org/emersion/drm_info This is already packaged in Debian as drm-info. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a

Re: Upgrade package from init script to Systemd, move config folder

On Wed, 2023-04-26 at 22:44 +0300, Boian Bonev wrote: > OTOH it is an un-favor to move or remove it ... > It is better to keep the init script in place. Another option is the orphan-sysvinit-scripts package: Description: Orphaned System-V-like init scripts  This package provides System-V init

Re: RFC: More C errors by default in GCC 14 (no more implicit function declarations etc.)

On Tue, 2023-04-18 at 16:07 +0200, Florian Weimer wrote: > TL;DR: I want to propose a GCC 14 change which will impact > distributions, so I'd like to gather some feedback from Debian. Is this change being made the upstream defaults? Or will it be a distro override like the hardening flags are?

Re: Best way to handle config overrides in packages

On Wed, 2023-03-29 at 15:43 +0300, Олег Михайлов wrote: > I have a case when I need to add multiple configuration files for > another package into the system as parts of its split config. The > thing is, I need to remove them when I remove my package because they > include lines which are only

Re: An email address for drive-by bug reports?

On Mon, 2023-03-06 at 16:56 -0800, Don Armstrong wrote: > This is my viewpoint too, and why I don't plan on implementing or > accepting a patch to do nosubmitter unless someone can convince me > otherwise. The use-case presented in the thread seems reasonable to me; when you are submitting a bug

Re: An email address for drive-by bug reports?

On Tue, 2023-02-28 at 18:36 +0100, Gioele Barabucci wrote: > Should there be a standard email address for "I'm reporting this because > I noticed it, but I'm not interested in it"-bug reports? Similar to the BTS noowner command, perhaps add a nosubmitter command? -- bye, pabs

Re: debian support veeam

On Wed, 2023-02-22 at 12:16 +0300, Nijam Deen wrote: > debain os will support for veeam backup using network storage Since Veeam is proprietary software, please ask their support team: https://www.veeam.com/support.html -- bye, pabs https://wiki.debian.org/PaulWise signature.asc

Re: Yearless copyrights: what do people think?

On Wed, 2023-02-22 at 09:47 -0800, Russ Allbery wrote: > People doing this should be aware that you're probably waiving certain > damage provisions in US copyright law should you ever sue someone in the > US for violating the license on the Debian packaging, at least so far as I > understand US

Re: Consensus on closing old bugs

On Mon, 2023-02-06 at 10:07 -0700, Sam Hartman wrote: > It's even appropriate to ask if the bug still happens. I'd like to see people asking that to put a slight amount of effort into reproducing the bug, especially if there are documented or obvious steps towards that. I recently encountered a

Re: Request to add firmware to installation images/nonfree repo

On Sat, 2023-01-21 at 09:38 -0800, Koohyar Hasani wrote: > install Debian (i386 arch) on a touchscreen device (Dell Venue 8 Pro) This device is likely 64-bit, so you should use amd64 instead.

Re: automated CI on salsa to prepare MR for new upstream version

On Fri, 2023-01-20 at 11:01 -0500, Yaroslav Halchenko wrote: > Is there any package/tool which already does something like that on CI? > Or may be you see some issues with such a procedure? The Debian Janitor is already doing some of that for all packages, for both new upstreams and new upstream

Re: Does removal of global variables from a library break C ABI?

On Wed, 2023-01-18 at 09:33 -0500, Scott Talbert wrote: > Thanks Russ and Peter.  I didn't find any usage of these symbols, but I > did sadly find a lot of bundled copies of this library in the archive.  :( It might be worth asking the upstreams to remove the copies and registering the existing

Re: Help patching files in dependency package

On Tue, 2023-01-17 at 00:55 +0100, Tobias Wackenhut wrote: > What would be the cleanest way to package the new version with the > mentioned patch? Ask the extension author to get the patch included into the upstream rt5 core, get a release of that, then get request-tracker-5 updated.

Re: looking for debian friendly web app technology

On Mon, 2022-12-12 at 18:01 +0100, Andreas Josef Heil wrote: > I wan't a highly interactive web app, A desktop app is also possible. What program are you intending to develop? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part

Re: Is an autogenerated configure shell script non-editable source

On Sun, 2022-12-11 at 16:47 +0100, Andreas Tille wrote: > Could you give some arguents for your feeling. See the posts I made in this and earlier threads: https://lists.debian.org/msgid-search/4363a2435e61bf351c7d3605136c3652118eae2f.ca...@debian.org

Re: Is an autogenerated configure shell script non-editable source

On Sat, 2022-12-10 at 10:28 +0100, Andreas Tille wrote: > So far for the actual case (bug report in CC). > > For the general case I somehow understand the consensus here on the list > that a missing configure.ac can be considered a bug but the severity > serious is not really rectified.  If I

Re: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

On Fri, 2022-12-09 at 13:14 +0100, Andreas Tille wrote: > Is an autogenerated configure shell script non-editable source [Short-winded way of saying something similar to Russ] In general I don't think such a situation meets DFSG item 2 nor the GPL "preferred form for modification", for the

Re: looking for debian friendly web app technology

On Fri, 2022-12-09 at 13:12 +0100, Andreas Josef Heil wrote: > I'd like to develop a free software web app and I wanne be the debian > maintainer for it. It should be fully integrated to debian und freedombox. > > What web technology should I use? Personally I would suggest to focus on static

Re: Misc Developer News (#58)

On Thu, 2022-12-01 at 11:42 +0100, Bastian Venthur wrote: > I wonder if there's an easy fix here, like a new version of anacron that > adds a check for this particular issue, offering to fix it during > upgrade of the package. It is hard to tell the difference between an affected system and

Re: a two cent suggestion

On Sat, 2022-11-26 at 19:42 +0100, Patrice Duroux wrote: > Any (or a specific group of) users could be able to install any > package of the first class by their own without asking a sysadmin (or > explicitly acquiring privilege of) user. The general idea of a safe way to allow users to manage

Re: Misc Developer News (#58)

On Fri, 2022-11-25 at 12:46 +0100, Bastian Venthur wrote: > On 21.11.22 00:18, Paul Wise wrote: > > anacron might be disabled if 2.3-33 was ever installed > [...] > I'm having trouble assessing the severity of the situation. Is more or > less everyone affected who uses unstable?

Re: [DEVEL] Enable support for Renesas platform

On Sat, 2022-11-19 at 09:06 +0200, Josua Mayer wrote: > However note I am not part of the Debian project.  > I don't know if joining makes sense, I don't know if the Debian > project would like to incorporate some developers who specifically > would collaborate to support certain vendors in

Re: [DEVEL] Enable support for Renesas platform

On Fri, 2022-11-18 at 15:20 +0700, Huỳnh Thành Hưng wrote: > I’m from Renesas Electronics Corporation, Welcome to Debian! In case your company would like to help out Debian, please review our suggestions for ways that companies can contribute: https://www.debian.org/intro/help#organizations >

Re: Q: How about versions/features in bookworm?

On Sun, 2022-11-06 at 13:58 +0900, Hideki Yamane wrote: >  Q1:  When dpkg will support zstd compression? reportbug says this is #892664, please review it for the status. >  Q2:  More default hardening options? (See > https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc )

Re: official Debian kernel-free images

On Sat, 2022-11-05 at 20:20 +0100, Patrice Duroux wrote: > There are many projects here and there (Termux, AnLinux, etc.) that are based > on > some sorts of kernel-free images of a minimal Debian system to be used through > chroot (other Linux) or PRoot (Android) or whatever environments. Some

Re: Port to LoongArch architecture for Debian

On Thu, 2022-11-03 at 20:11 +0800, 张丹丹 wrote: > Port to LoongArch architecture for Debian, now in the "Downstreaming" > section in the port life-cycle according to > . I initiated this document and wrote a fair bit of it, with help from the rest of the

Re: rebootstrap status update for Loongarch

On Thu, 2022-11-03 at 18:45 +0800, Zhang Ning wrote: > 7, m4, diffutils: need help, I don't know where is correct > upstream[1][2], the patch[3][4] is for generated files, but Debian > source has these files, thus how can I submit these patch to Debian > source? these two packages don't have VCS.

Re: cruft(-ng) and dh-cruft: handling and registering of dynamic files

On Sun, 2022-10-23 at 01:08 +0200, Alexandre Detiste wrote: > This DebHelper works this way: > * the "debian/cruft" list merely register the glob patterns, > * and "debian/purge" list also an "rm -rf" stanza in postrm/purge. > > As a bonus there's now also a new "cpigs" command, working akin to

Re: RFH: Packaging Intel's userspace tools for Data Streaming Accelerator

On Fri, 2022-10-21 at 12:48 -0500, Gunnar Wolf wrote: > The purpose of this mail is to help find interested people in Debian > that can help review and sponsor uploads of the userspace tools; the > kernel-side modules have been enabled as of bug #1021337 (thanks for > the quick reply!) PS: once

Re: Submitting Patches

On Fri, 2022-10-21 at 16:28 +1100, Phillip Smith wrote: > Where/How do I submit patches for Debian packages? It completely depends on the preferences of the team or person who will be reviewing the patches. Most teams and package maintainers accept changes via Salsa merge requests, but, as

Re: epoch for tss2 package

On Wed, 2022-10-19 at 23:04 -0700, Debora Velarde Babb wrote: > Initially I attempted to create the package with the new name ibmtss. > There was some discussion on debian-mentors list and the response was > that I should NOT change the name to ibmtss and instructed to instead > use an epoch

Re: Sunsetting sso.debian.org

On Mon, 2022-10-17 at 21:28 +0200, Joerg Jaspert wrote: > Salsa should be there for git (related) things. > NOT as an identity/login provider for Debian There are already Debian services that do not offer any other option for auth than Salsa. Personally I do not like GitLab, Salsa nor

Re: Sunsetting sso.debian.org

On Sun, 2022-10-16 at 16:21 -0700, Sean Whitton wrote: > At the present time, I believe this will break DDs logging into > tracker.debian.org.  I recently had to mess around with client > certificates in order to login there and subscribe to a new package. It will still be possible to manage DPT

Re: Firmware GR result - what happens next?

On Thu, 2022-10-13 at 17:35 +0200, Julien Cristau wrote: > I'd prefer if we could make things work vs making things fail, > however loudly. There seem to be a few ways to deal with this transition: 1. Document it in the release notes and let users handle it. This means lots of users won't get

Re: Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency

On Sun, 2022-10-09 at 18:54 +0200, David Kalnischkies wrote: > I suppose we could use 'foo-dbgsym Enhances foo:arch (= version)'. That sounds interesting and would be nice generally, however... > On a sidenote: What the Depends ensures which the Enhances doesn't is > that they are upgraded in

Re: Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency

On Sat, 2022-10-08 at 11:00 +0200, Niels Thykier wrote: >   2) We now have a debuginfod service, so you do not even have to install > dbgsym packages anymore (if you configure gdb to use it).  For the > cases where you do install the dbgsym, you still have to manage > inter-source

Re: Q: uscan with GitHub

On Mon, 2022-09-19 at 18:12 +0200, Samuel Thibault wrote: > The problem is that the tags page only contains snapshots of the > repository, and not an autoconf-ed tarball. I think that is an advantage, because then you can be sure that you can rebuild the autotools generated files from source

Re: Q: uscan with GitHub

On Mon, 2022-09-19 at 20:50 +0900, Hideki Yamane wrote: > Recent changes in GitHub releases pages, I cannot check upstream > version with uscan. How do you deal with it? If you are using the automatically generated tarballs, then just switching to the uscan git mode seems like the way to go.

  1   2   3   4   5   6   7   8   9   10   >