Hey!
When a package migrates from /lib to /usr/lib, it seems that
dpkg-maintscript-helper gets confused and says that the target path
(when trying to turn a directory to symlink for example) is not owned by
the (currently installed) package, which is right.
Is there a way to make dpkg-maints
Hey!
I am using qemu-user-static to compile to ARM64 from AMD64. There is a
long-time bug with recent versions of QEMU where you would get a segfault:
https://gitlab.com/qemu-project/qemu/-/issues/1913
I was using qemu-user-static_7.2+dfsg-7+deb12u5_amd64.deb for quite some
time, but recentl
On 2024-07-07 15:56, Daniel Gröber wrote:
From where I'm sitting ifupdown2 is completely out of the question as *the*
Debian ifupdown since it doesn't even support *basic* IPv6 use-cases like
DHCPv6. Upstream community seems nonexistant since this is software by a
corp for a corp where communit
On 2024-04-01 12:44, Bastian Blank wrote:
So in the end you still need to manually review all the stuff that the
tarball contains extra to the git. And for that I don't see that it
actually gives some helping hands and makes it easier.
So I really don't see how this makes the problem in hand a
On 2024-04-01 18:05, Jonathan Carter wrote:
The included firmware contributed to Debian 12 being a huge success,
but it wasn't the only factor.
Unfortunately, the shipped firmwares are now almost a year old,
including for unstable. I am following the progress since quite a few
years and I hav
On 2023-12-01 12:30, Simon McVittie wrote:
This does not prevent to have 127.0.0.1. I don't think this is a good use of
time to fix builds broken because there is no IPv4 loopback. This is the
same kind of artificial conditions as the 1-core builders.
Unfortunately, no, it's a bit more complicat
On 2023-11-30 22:42, Dale Richards wrote:
I recently submitted a patch for uvloop that was FTBFS on IPv6-only
builds (#1024079) and it really didn't take very long. While
building/running in IPv6-only environments is not currently mandated in
the Policy it's a fairly safe bet that it could/should
On 2023-11-30 21:38, Paul Tagliamonte wrote:
Now I would like to know if being able to run in an IPv6-only environment is
a must have feature for any debian package?
I run an IPv6 only LAN on my home network, where I use `jool`, and
`dns64-prefix`+`unbound` to interoperate with legacy IP space
On 2023-09-15 21:04, Sebastian Ramacher wrote:
Source: libcbor
Version: 0.10.2-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
https://qa.debian.org/excuses.php?package=libcbor
Issues preventing migration:
Not built on buildd: arch amd64 binaries uploaded by bernat
Not built o
On 2023-08-10 14:38, Lucas Nussbaum wrote:
On 08/08/23 at 10:26 +0200, Helmut Grohne wrote:
Are we ready to call for consensus on dropping the requirement that
`debian/rules clean; dpkg-source -b` shall work or is anyone interested
in sending lots of patches for this?
My reading of the discuss
On 2023-08-05 17:06, Lucas Nussbaum wrote:
Should we give up on requiring a 'clean' target that works? After all,
when 17% of packages are failing, it means that many maintainers don't
depend on it in their workflow.
Yes, please, this does not make sense anymore to enforce such a rule
when it
On 2023-07-12 07:54, Gioele Barabucci wrote:
1) It's an extra layer. [...]
2) It's a layer that you cannot ignore when editing the config. [...]
I'd also add 3) It requires Python and various Python libraries. At
least the CLI tool does.
In some circumstances installing Python and a bunch
On 2023-01-28 13:59, Adrian Bunk wrote:
I am not saying that trying to force maintainers to spend time on such
issues by making them release critical is better, but you are also
creating extra work and frustration for the people who are doing QA work
in Debian.
It also pushes some maintainers t
On 2023-01-28 00:20, Santiago Vila wrote:
Release Policy exists as a canonical list of what should be RC and > what not,
and it's intended to avoid stupid discussions like this one.
Extending build-essential is easier than asking many people to do
pointless work to satisfy a set of non-existi
On 2022-09-29 15:01, Michael Stone wrote:
On Wed, Sep 28, 2022 at 09:02:15PM -0600, Sam Hartman wrote:
* Finally, I can use bluetooth on linux with reasonably good audio
quality!
Aren't they both using the same backend? ldac/aptx weren't in pulseaudio
for a long time, but they are now. Or is
On 2022-09-09 04:51, Paul Wise wrote:
On Thu, 2022-09-08 at 17:58 +0200, 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 di
On 2022-08-27 15:53, M. Zhou wrote:
That's why I still hope ftp team to recruit more people. This is
a very direct and constructive way to speed up everything.
More volunteers = higher bandwidth.
Recruiting more people doesn't seem to have a serious disadvantage.
It does not seem to work. Eith
On 2022-08-19 23:14, Andrea Pappacoda wrote:
Would alternatives really be that bad? What if the current /usr/bin/muon
was moved to /usr/bin/muon-kde, muon-build was installed to
/usr/bin/muon-build and /usr/bin/muon was shared between the two
packages? What issues could it cause?
I don't thi
On 2022-07-16 23:49, Pierre-Elliott Bécue wrote:
In the past months, it's been clear that sending mails from an
@debian.org address to some mail providers, including GMail, has become
harder and harder. While user DKIM feature (documented on [0]) can help,
we thought providing a relay server for
On 2022-07-17 10:29, Dominik George wrote:
tl;dr: DKIM-signed mail is verifiable, but only the headers; the body can be
tampered with
That's not true. The body is always part of the signature (in a strict
or relaxed way).
> The Signer/Verifier MUST compute two hashes: one over the body of
On 2022-07-14 17:14, Russ Allbery wrote:
(Also, due to the limitations and history of naming conventions, the
software is inherently trying to map into a gender binary, which if one is
attempting to capture self-identification is likely to be unhelpful for
many populations, such as ones with lots
On 6/30/22 16:16, Sam Hartman wrote:
However there are some other features from the ITP:
-Support NTLS (formal GM dual-certificate protocol) handshake processing,
according to GB/T 38636-2020
TLCP
-QUIC API support
Is it compatible with QuicTLS, which is another fork of OpenSSL? Some
❦ 10 May 2022 14:30 -06, Sam Hartman:
> 2) We value being able to build from source when we can. We value
> being able to have reproducible builds when we can. We don't want to
> take steps backward in those areas in order to get hardware working
> better.
Is there any firmware that would match
❦ 10 March 2022 11:34 -05, Michael Stone:
On systems that don't use usergroups for all/some users, doesn't this
change make all files writable by other users by default? That would
seem like a very unsecure change on upgrades (or as a default).
>>>
>>> AFAIK systems that don't use
❦ 10 March 2022 11:21 +01, Philip Hands:
>> On systems that don't use usergroups for all/some users, doesn't this
>> change make all files writable by other users by default? That would
>> seem like a very unsecure change on upgrades (or as a default).
>
> AFAIK systems that don't use usergroups
❦ 7 March 2022 18:33 +01, Adam Borowski:
>> lumin highlights matches to a specified pattern (string or regular
>> expression) in files, using color. This is similar to grep with
>> colorized output, but it outputs all lines in the given files, not
>> only matching lines.
>
> .--[ ~/bin/hl ]
❦ 14 February 2022 22:39 +01, Jonas Smedegaard:
> I am trying hard to read good faith into your last sentence above, but
> have quite some difficulty reading as anything but you describing
> unbundling as inevitably leading to disaster.
That's how you should read it.
> Maybe my point was uncl
❦ 14 February 2022 10:56 +01, Jonas Smedegaard:
>> I've finally give up and am just using ALL the bundled node packages:
>> https://salsa.debian.org/chromium-team/chromium/-/commit/a418d219f0217d6398a01c30035d35c42f7a76f1
>>
>
>> It's not ideal, but at least with this we'll match all of the nod
❦ 28 January 2022 22:52 +01, Sebastian Ramacher:
>> > http://bugs.debian.org/1004272
>> > I agree that it should have been announced somewhere in addition to the
>> > #debian-devel topic.
>>
>> Running unstable, are we at risk having problems? Are the packages
>> updated in the last few days bei
❦ 28 January 2022 12:34 +05, Andrey Rahmatullin:
> http://bugs.debian.org/1004272
> I agree that it should have been announced somewhere in addition to the
> #debian-devel topic.
Running unstable, are we at risk having problems? Are the packages
updated in the last few days being rebuilt?
--
Ma
❦ 26 January 2022 10:04 +01, Marc Haber:
>>> Are the IP ranges of the Cloud Providers registered that badly that
>>> deb.debian.org wouldn't reliably point to the mirrors inside the
>>> provider's infrastructure? Or are the cloud providers' mirrors
>>> differnet from what we expect from a Debian
❦ 25 January 2022 21:51 +01, Jonas Smedegaard:
>> I didn't comment at first because I thought someone else would raise
>> the idea. But it seems people still like the idea of a NEW queue. Not
>> me. The NEW queue is a hindrance.
>
> For the record, I don't "like" the NEW queue.
>
> I don't like
❦ 21 January 2022 09:51 -05, M. Zhou:
> I'd rather propose choice C. Because I to some extent understand
> both sides who support either A or B. I maintain bulky C++ packages,
> and I also had a little experience reviewing packages on behalf of
> ftp-team.
I didn't comment at first because I tho
❦ 7 December 2021 23:35 GMT, Simon McVittie:
> I believe what Vincent meant is that the generic non-Flatpak binaries
> provided by the "Ungoogled Chromium" project are compiled on unknown
> machines and require trusting their submitters, whereas the Flatpak
> binaries provided by Flathub are com
❦ 7 December 2021 21:46 +01, Mathias Behrle:
>> (I have been running an ungoogled-chromium for a while (ca. a year
>> ago?), however at that time their chrome wasn't extremely stable so I
>> gave up again. Does anybody have experience using it recently?)
>
> (Using chromium only as fallback br
❦ 28 September 2021 13:04 -05, Richard Laager:
> Are you saying "everything breaks" as in:
> A) the change is not applied (correctly) in the way that it would be if
>the system was rebooted, or
> B) the change is applied, but the human made a mistake in the config and
>the change breaks t
❦ 28 September 2021 11:16 -05, Richard Laager:
>>> As to what should be the distro default, I'm not sure I am convinced
>>> either way, but to argue the other side... There is some value in
>>> using netplan by default. Some random thoughts:
>> [...]
>> OTOH, netplan is just an abstraction above
❦ 28 September 2021 01:29 -05, Richard Laager:
> As to what should be the distro default, I'm not sure I am convinced
> either way, but to argue the other side... There is some value in
> using netplan by default. Some random thoughts:
[...]
OTOH, netplan is just an abstraction above existing sy
❦ 12 August 2021 10:31 +02, Ansgar:
>> I give myself password less sudo to "apt update" (without additional
>> options), "apt upgrade" (same), "apt full-upgrade" (same). I was
>> thinking this should be safe, but now I need to check if the pager is
>> properly restricted when displaying NEWS file
❦ 12 August 2021 11:38 +05, Andrey Rahmatullin:
>> >> I just ran across this article
>> >> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
>> >> the attacks on Debian 11 and they work successfully giving me a root
>> >> shell prompt.
>> > I don't think calling this "privile
❦ 12 August 2021 10:39 +05, Andrey Rahmatullin:
>> I just ran across this article
>> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
>> the attacks on Debian 11 and they work successfully giving me a root
>> shell prompt.
> I don't think calling this "privilege escalation"
❦ 11 August 2021 11:27 +02, Steffen Möller:
> I have no exact idea what to change, though. A rolling Debian would be
> cool, yes, but also a bit late when compared with environments that
> Conda offers or the ease that comes with multiple installations of conda
> to e.g. avoid name conflicts. If
❦ 23 janvier 2021 15:39 +02, Jonathan Carter:
> But the sentiment above and in other similar messages were that the
> completely free images are broken for many users that might need some
> non-free firmware. This is simply not true. I've only ever installed
> using the free images, and then afte
❦ 11 décembre 2020 20:36 -05, Mark Pearson:
>> They seem to say future releases will be tagged. So, I think you should
>> use in gbp.conf:
>>
>> upstream-tag = v%(version%~%-)s
>> pristine-tar = False
>>
>> No need for upstream-branch since you won't use "gbp import-orig" as the
>> origin lives
owner 960788 markpear...@lenovo.com
quit
❦ 11 décembre 2020 12:15 -05, Mark Pearson:
>>> I did have to comment out "overlay = True" in the gbp.conf - it gave me
>>> an error that I'll have to dig into.
>>
>> That's because you went for the first "classic" solution. I was pushing
>> for the over
❦ 10 décembre 2020 12:57 -05, Mark Pearson:
> I did have to comment out "overlay = True" in the gbp.conf - it gave me
> an error that I'll have to dig into.
That's because you went for the first "classic" solution. I was pushing
for the overlay solution as the upstream git repository is pushing
❦ 7 décembre 2020 08:57 -05, Mark Pearson:
> I'd like to solve the lack of Intel SOF audio firmware & topology
> files being available on Debian - I know it's impacting a lot of users
> on some of the newer Thinkpads. I figured I should have a stab at this
> exercise myself and see what happens.
Hey!
Chromium is stuck at version 81.0.4044.92 since April. Current stable is
83.0.4103.97 and, like often, it includes many security fixes. It seems
Michael is not currently available and no work is done to update
Chromium to the latest version, both in unstable and stable. Is there
someone famil
❦ 4 mai 2020 11:23 +02, Jeff:
> The Fedora maintainer for a package for which I am upstream has pointed
> out that it still uses gconftool or gconftool-2, which is way out of
> date and should use gsettings[1].
>
> Unfortunately, my search engine foo is failing me and I can't find the
> right in
❦ 26 avril 2020 15:04 -07, Russ Allbery:
>> This is not how this is implemented. I am using GitHub and GitLab with
>> 2FA enabled and I am rarely asked to enter any token. Once you get
>> authenticated on a device, it remains for a long time.
>
> Pretty much every time I go to salsa.debian.org, I
❦ 26 avril 2020 20:29 +00, Jeremy Stanley:
> You're already seeing quite a few folks responding that being
> required to use an additional application or device each time they
> authenticate would be an inconvenience to them. This is a signal. I
> personally wouldn't enjoy being prompted to activ
Package: wnpp
Severity: wishlist
Owner: Vincent Bernat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: bgpq4
Version : 0.0.6
Upstream Author : Job Snijders
* URL : https://github.com/bgp/bgpq4
* License : BSD 2-clause
Programming Lang: C
❦ 26 avril 2020 14:07 +02, Bernd Zeimetz:
> There are even cli tools that do the same stuff. I'd guess there is at
> least one on Debian.
There is oathtool.
--
I dote on his very absence.
-- William Shakespeare, "The Merchant of Venice"
signature.asc
Description: PGP signature
❦ 25 mars 2020 15:57 +01, Jonas Smedegaard:
>> rpm packages record the package license information in a one-line License:
>> field.
>
> Is your point that 9 lines can be reduced to one, or that 100 lines can
> be reduced to one?
>
> It is legal in Debian to write debian/copyright files looking l
❦ 24 mars 2020 16:30 -07, Russ Allbery:
> On the other hand (and I don't follow this community closely, so apologies
> if I have the details wrong here), my impression is that the Go community
> is not planning to support shared libraries, loves its staticly-linked
> binaries, and makes extensive
❦ 24 mars 2020 16:30 -07, Russ Allbery:
> On the other hand (and I don't follow this community closely, so apologies
> if I have the details wrong here), my impression is that the Go community
> is not planning to support shared libraries, loves its staticly-linked
> binaries, and makes extensive
❦ 24 mars 2020 14:18 +01, Julien Puydt:
>> There are other reasons, notably that you speed up builds by having
>> all the source code ready.
>
> Sorry, I don't know much about how go works, but : can't the developer
> just have the deps ready -- and just not commit them to the repo and
> not ship
❦ 24 mars 2020 05:37 -05, Michael Lustfield:
>> > Kubernetes is already using Go modules. They happen to have decided to
>> > keep shipping a `vendor/` directory but this is not uncommon. It is
>> > often considered as a protection against disappearing modules. So, there
>> > is nothing to be don
❦ 24 mars 2020 10:14 +00, Paul Wise:
>> Kubernetes is already using Go modules. They happen to have decided to
>> keep shipping a `vendor/` directory but this is not uncommon. It is
>> often considered as a protection against disappearing modules. So, there
>> is nothing to be done upstream. And
❦ 24 mars 2020 03:11 +00, Paul Wise:
>> Specifically, as README.Debian states, the vendor/ subdirectory of the
>> source package contains more than two hundred Go libraries.
>
> There are a *lot* of embedded code/data copies in Debian already.
> While it would be nice to remove them, sometimes it
❦ 19 février 2020 13:55 +13, Michael Hudson-Doyle
:
> So in Ubuntu we got this interesting bug
> https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1855140 which can be
> summarized as saying that haproxy doesn't work out of the box in a docker
> container, because it installs a tmpfiles.d s
❦ 6 février 2020 10:45 +01, Svante Signell :
>> To not have logs duplicated in two places.
>
> If this is your motivation for the change it is a _very_ weak one, right? Disk
> space is not a crucial problem anymore. Additionally, what would be the
> defaults
> for non-systemd systems running GN
❦ 6 février 2020 09:50 +11, Dmitry Smirnov :
>> and 2) continuing to use rsyslog isn't an option if the default changes.
>
> No. I just don't want default to change. IMHO rationale for this is weak but
> everybody keeps arguing that it would not be a big deal. In time we will see
> how that go
❦ 5 février 2020 01:01 -05, Scott Kitterman :
> Not particularly useful IMO. In /var/log/mail.log I can see log entries from
> all the programs configured to log to the mail facility. That way I can see
> the interaction between them. On a typical server that is for sending mail I
> often
❦ 4 février 2020 11:30 -08, Russ Allbery :
>> As a heavy user or Rsyslog features I feel that switching default
>> logging system yields no benefits to say the least.
>
> As a heavy user, perhaps you're not the target audience for a default?
> You're going to install rsyslog no matter what, sinc
❦ 31 octobre 2019 21:49 +01, Thomas Goirand :
> The idea has always been that it would be on best-effort from people who
> volunteer, without forcing anyone to do any sysv-rc support if they
> don't feel like it. What you describe goes along this line.
I have raised my concern about this a few m
❦ 31 octobre 2019 17:51 -07, Russ Allbery :
> I think we should adopt sysusers.d fragments as the preferred mechanism
> for creating system users (with some rules, such as a standard for how to
> name the users and a requirement that the UID be specified as - unless one
> goes through the normal
❦ 2 octobre 2019 05:47 +02, Jean-Philippe MENGUAL :
> An idea: establishing a time of discussion. At the end, if there is not
> consensus (as Gitlab), there is not. If there is, ensuring every DD can
> still have an opinion via GR or changes proposals in some guidelines
> (Debian Policy, etc). W
❦ 24 septembre 2019 10:41 +02, Gard Spreemann :
> A package I maintain (src:gudhi) was mostly under GPL-3+ up to and
> including the current version in the archives. Since then, upstream has
> switched to an MIT license, but with the caveat that many parts of the
> code has GPL dependencies and t
Package: wnpp
Severity: wishlist
Owner: Vincent Bernat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: xtl
Version : 0.6.5
Upstream Author : QuantStack
* URL : https://github.com/QuantStack/xtl
* License : BSD
Programming Lang: C
❦ 14 août 2019 22:32 +00, Holger Levsen :
>> I systematically turn off Gitlab MR support for projects I am involved
>> in, because I am not confortable and efficient using it myself, it is
>
> what helps me is having a note with this line:
>
> git config alias.mr '!sh -c "git fetch $1
> merge-r
❦ 15 août 2019 14:11 +02, Simon Richter :
> So we might have to invent magic comments still and/or convinve systemd
> people that it might be a good idea to have unit files that can support
> both immediate and on-demand start.
It's already the case. Require the socket for on-demand start, requi
❦ 11 août 2019 10:27 +02, Marc Haber :
>>* Better restart semantics and monitoring of services/ways to configure
>> restart.
>
> We have, however, failed to make use of that. "systemctl restart" is
> nearly useless in Debian because a non-negligible part of our daemon
> packages make systemd thi
❦ 9 août 2019 09:22 +02, Martin Steigerwald :
>> Reality seems different. Almost nothing was using inetd (tftpd is the
>
> I note that you wrote "seems". But still:
>
> As if there would just be *one* reality. Actually there is. But I never
> saw any human being being able to express it in word
❦ 8 août 2019 21:47 +02, Simon Richter :
>> inetd performance is very low because it needs to spawn one instance for
>> each connection. systemd socket activation has absolutely 0 overhead
>> except on the first connection (where systemd needs to start the
>> service).
>
> If you specify "wait"
❦ 8 août 2019 19:10 +02, Simon Richter :
> For servers, the benefit is rather limited. There is no local user who
> makes system-wide policy decisions, and hardware is not changing
> dynamically either. The actual services provided are either implemented as
> daemons (i.e. not microservices), or
❦ 28 juillet 2019 12:11 +02, Philipp Kern :
>> Just a quick note: seccomp filters may need adaptations from one libc
>> to another (and from one kernel to another as the libc may adapt to
>> the current kernel). For example, with the introduction of "openat"
>> syscall, the libc has started to us
❦ 19 juillet 2019 17:18 +02, Christoph Biedl :
> Upstream of the file package added seccomp support a while ago, and
> probably everyone with even a small concern about security will agree
> the file program, often being used on dubious or even doubtless
> malicious input, should use seccomp to m
❦ 14 juillet 2019 12:30 -07, Russ Allbery :
> There seems to be a clear infrastructure gap for the non-systemd world
> here that's crying out for some inetd-style program that implements the
> equivalent of systemd socket activation and socket passing using the same
> protocol, so that upstreams
❦ 14 juillet 2019 19:23 +01, Simon McVittie :
> Some systemd system services are meant to start on-demand via socket
> events (systemd.socket(5)), and can work via inetd on non-systemd-booted
> systems. micro-httpd appears to be an example of this - I'm a bit surprised
> there aren't more. Perhap
❦ 13 juillet 2019 11:52 -07, Russ Allbery :
>> Previously, we had a sort of agreement (through the TC decision) that
>> such scripts should be maintained by people caring about them and we
>> should only act on bug reports with proper patches to have them.
>
> I don't agree that this was ever the
Hey!
Lintian got a new tag to enforce Policy 9.11:
Packages may integrate with these replacement init systems by
providing implementation-specific configuration information
about how and when to start a service or in what order to run
certain tasks at boot time. However, any package integrati
Package: wnpp
Followup-For: Bug #883393
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hey!
Any progress on this? Do you need help packaging?
-BEGIN PGP SIGNATURE-
iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl0mDQYSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5SVQP/2rf1gCpD3aw71BxPFf7xAzw
❦ 12 juin 2019 14:02 +08, Paul Wise :
>> * I had to patch reprepro to support multiple versions:
>> https://github.com/profitbricks/reprepro
>
> I think it would be very helpful to a lot of derivative distros and
> small or private apt repositories if this patch could be merged
> upstream and mad
❦ 4 juin 2019 15:47 +01, Ian Jackson :
> If not, how do you think the question you pose should be answered ?
> Since it is a question of tradeoffs, with no definite right or wrong
> answer, perhaps we should hold a GR ? What do you think the result of
> such a GR would be ?
>
> I think such a G
❦ 28 mai 2019 06:50 +00, PICCA Frederic-Emmanuel
:
>> packages. While my Perl is a bit rusty, I can propose some "dh_fetch"
>> helper for this if there is no huge opposition against this approach.
>
> why not a dh_uscan ?
>
> what is the fundamental difference between dh_fetch and what you can
>
❦ 28 mai 2019 06:30 +00, Niels Thykier :
> I.e. with the proper implementation of "make-it-work" (in the lack of a
> better name - maybe something "fetch-and-build"), the following should
> be possible
>
> """
> #!/usr/bin/make -f
>
> # DISTRIBUTION = $(shell sed -n "s/^VERSION_CODENAME=//p" /etc
❦ 28 mai 2019 08:59 +08, Paul Wise :
>> People using tools like fpm will never get familiar with our tools and
>> will never be contributors.
>
> I enjoyed your blog post about pragmatic packaging using Debian's
> tools instead of fpm, it seems like a good approach if one is
> committed to using
❦ 27 mai 2019 16:15 +10, Ben Finney :
>> If you just want to get upstream's idea of their package onto a system
>> with their release schedule and their recommended dependency versions,
>> there are better ways than getting a package into Debian.
>
> In the Debian mentors forum (that is, the chat
❦ 26 mai 2019 12:04 +02, Jonas Smedegaard :
>> > * People who make changes across the archive such as enabling
>> > hardening, cross-building, bootstrapping, etc benefit
>> > significantly from more uniformity in packaging practices. The
>> > time they spend working on packages that use
❦ 25 mai 2019 13:26 -04, Sam Hartman :
> * People who make changes across the archive such as enabling hardening,
> cross-building, bootstrapping, etc benefit significantly from more
> uniformity in packaging practices. The time they spend working on
> packages that use dh is significantly
❦ 19 mai 2019 23:53 -04, Sam Hartman :
> >> As promised, I'd like to start a discussion on whether we want to
> >> recommend using the dh command from debhelper as our preferred
> >> build system.
>
> Sean> For those who haven't seen it, the original author of dh, Joey
> Sean>
❦ 9 avril 2019 08:41 +10, Ben Finney :
>> >> yes, it can be done, but it is a lot more work for individual
>> >> packagers.
>> >
>> > Sure. And, on the other hand, providing an APT repository for arbitrary
>> > packages of unknown copyright status is also a lot of work to expect
>> > disinterest
❦ 8 avril 2019 14:46 +10, Ben Finney :
>> yes, it can be done, but it is a lot more work for individual
>> packagers.
>
> Sure. And, on the other hand, providing an APT repository for arbitrary
> packages of unknown copyright status is also a lot of work to expect
> disinterested volunteers to d
❦ 24 mars 2019 14:40 +01, Didier 'OdyX' Raboud :
>> Wouldn't it break chrooted processes? But mostly, as the whole pattern
>> is broken, it seems to be a low-effort solution.
>
> Vincent: what scenario did you have in mind?
For the first part, any daemon chrooting (like HAProxy, lldpd). For the
❦ 24 mars 2019 09:42 +01, Geert Stappers :
> What would be the harm to the Buster release
> if lsb-base got NMU
> with
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=888743;filename=init-functions.diff;msg=37
> ?
Wouldn't it break chrooted processes? But mostly, as the whole pattern
❦ 9 février 2019 13:10 +01, Philipp Kern :
> Some core packages recently adding system users resorted to names like
> systemd-$daemon and _apt, which both address my concerns - as you can
> come up with simple rules like "no user might include [-_] in their
> username". On the other hand I know
Package: wnpp
Severity: wishlist
Owner: Vincent Bernat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: bpftrace
Version : git
Upstream Author : IO Visor Project
* URL : https://github.com/iovisor/bpftrace
* License : Apache 2
Programming
❦ 22 novembre 2018 18:00 +0100, Marco d'Itri :
> Actually I believe that the fact that this could be solved quickly and
> with a trivial change is a great argument in favour of the quality of my
> plan and work for switching to merged-/usr.
Thank you for that! My workstation was switched to me
❦ 19 novembre 2018 09:51 -0600, Dirk Eddelbuettel :
> | Dirk Eddelbuettel writes ("Our build system may be broken: /bin vs
> /usr/bin"):
> | > tl;dr: We may be messing up /bin and /usr/bin on some platforms
> |
> | This is the result of the change of the buildds to have `usrmerge', ie
> | merg
1 - 100 of 660 matches
Mail list logo
