mp; fvwm-common.
(I already began to work on it actually, expect an upload next WE or so)
Cordialement,
--
- Vincent RENARDIAS [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux: http://www.openhardware.orgLogiciels du soleil: -
- http://www.fr.debia
in any way, pay for this
program by spending one hour petting one or several cats."
I'm indeed not quite sure 'catware' qualifies as DFSG-free.
--
- Vincent RENARDIAS [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux: http://www.openhardware.orgLogi
talled by default.
That would be cheating ;)
--
- Vincent RENARDIAS [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux: http://www.openhardware.orgLogiciels du soleil: -
- http://www.fr.debian.orgOpen Hardware: htt
umeric.
Cordialement,
--
- Vincent RENARDIAS [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux: http://www.openhardware.orgLogiciels du soleil: -
- http://www.fr.debian.orgOpen Hardware: http://www.lds
yway, I will include them in my working copy. Would
> be better if you mailed them to me DIRECTLY.
I usually wait for the package to be installed to send the NMU patch to
the Bug Tracking System which is why you haven't got it yet.
> Greetings
> Bernd
>
> On Mon, Jan 25, 1
sion to fix the most obvious bugs (notably the few missing
manpages).
Cordialement,
--
- Vincent RENARDIAS [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux: http://www.openhardware.orgLogic
Ok, so if we really want a Debian 2.1 that is 100% kernel 2.2.x
compatible it needs this package to be included in frozen.
I've just uploaded it in Incoming/ 10 minutes ago.
Non-developers can also access it at http://www.ldsol.com/~vincent/
(NB: there are _2_ binary packages to install:
On Wed, 27 Jan 1999, Eric Delaunay wrote:
> Vincent Renardias wrote:
> [There is text before PGP section.]
> >
> > Ok, so if we really want a Debian 2.1 that is 100% kernel 2.2.x
> > compatible it needs this package to be included in frozen.
> > I've just uplo
On 27 Jan 1999, Mikolaj J. Habryn wrote:
> >>>>> "VR" == Vincent Renardias <[EMAIL PROTECTED]> writes:
>
> VR> Including the current (2.9g-5) util-linux from unstable in
> VR> frozen is a Bad Idea(tm). This version has several big
>
t unless nobody else really wants it.
Cordialement,
--
- Vincent RENARDIAS [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux: http://www.openhardware.orgLogiciels du soleil: -
- http://www.fr.debian.orgOpen Hardware:
than Debian... ;)
--
- Vincent RENARDIAS [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux: http://www.openhardware.orgLogiciels du soleil: -
- http://www.fr.debian.orgOpen Hardware: http://ww
a new version of jdk117 from blackdown (v3) has been released. apparently,
the problems with glibc2.1 have been resolved, though i haven't checked this
out myself.
is anybody working on packaging it? can i help?
-vinny
-- Vincent Murphy | CompSci Undergrad, UCC | [EMAIL PROTECTED] |
On Wed, May 12, 1999 at 03:24:06PM +0100, Julian Gilbey wrote:
> Question: would it be worth making -devel-announce a moderated list?
absolutely. the logo thread on debian-devel-announce seriously pissed me
off, because i don't filter the -announce lists with procmail.
-vinny
rdinary packages i'm afraid,
never mind installer packages. although if anybody wants to take it on i'm
willing to help in any way that i can.
-vinny
-- Vincent Murphy | CompSci Undergrad, UCC | [EMAIL PROTECTED] | (086) 8397405
"With a PC, I always felt limited by the so
gency: low
Maintainer: Vincent Renardias <[EMAIL PROTECTED]>
Description:
gdb- The GNU Debugger
Changes:
gdb (4.18-1) unstable; urgency=low
.
* New upstream version!
Files:
619420e2fa1ab2af70dd95dd02472260 608 devel standard gdb_4.18-1.dsc
828d28487af6cec074639c110256947
_("Error: verification failed: %s\n"),
gpgme_strerror (err));
state_puts (buf, s);
}
You need to complain to GPGME.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work
❦ 11 novembre 2018 19:20 +0100, Wouter Verhelst :
> Meanwhile, it makes sense to be courteous to people who were a DD once
> but really couldn't care less now and want to get rid of the nagging,
> which seems like a far more likely scenario.
Then, they should click on the button they are asked t
ing debian/gitlab-yi.yml as proposed on
https://salsa.debian.org/salsa-ci-team/pipeline/blob/master/README.md
[...]adding the following definitions to your gitlab-ci.yml file[...]
[...]On Debian projects, you would normally want to put this file
under the debian/ folder,[...]
Regards,
V
❦ 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
❦ 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
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
've noticed that some other Perl scripts also use this filehandle and
might be affected by the same issue.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
It is probably never used, and probably useless (I would rather
use the features from the shell if I need a pipe).
If this is modified, "-" must still be supported as being
regarded as stdin (this one is normally safe, and at least
developers should already be aware of it).
--
Vincent Lefè
On 2019-01-23 17:23:10 +0100, Alex Mestiashvili wrote:
> On 1/23/19 4:44 PM, Vincent Lefevre wrote:
> > On 2019-01-23 15:32:00 +, Ian Jackson wrote:
> >> This is completely mad and IMO the bug is in perl, not in all of the
> >> millions of perl scripts that used &l
On 2019-01-24 11:12:43 +0100, Alex Mestiashvili wrote:
> On 1/24/19 2:40 AM, Vincent Lefevre wrote:
> But I disagree that a language can be considered insecure, just because
Note: just a feature, not the language itself.
> it lets you shoot in the foot.
> The first thing I learned wh
uickly learnt to preprend "<" to the filename in
the 1990s (the 3-arg version did not exist at that time, IIRC).
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
t;
> being broken in such a fundamental way is news to me. And I don't quite
> see any way you could communicate that to me in a way other than a
> run-time warning -- you don't re-read docs for basics you believe you
> already know well.
As for me, even though I knew that <
secure. :(
Now, perhaps the number of such scripts is close to 0. I don't know.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
e-with-null-bytes-in-serialized-instances
(IMHO, it would be safer if Perl did this everywhere.)
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
eel free to mail
> off-list. Either way, the fact remains that if untrusted/unsanitised
> input is being passed into your @ARGV, then something is already
> wrong.
I recall that a part of the issue is that this wasn't documented
(in addition to being unintuitive). As pure filenames, t
tuitive). As pure filenames, they are
already sanitized: a filename that ends with "|" is perfectly
valid.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
❦ 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
❦ 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
❦ 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 chrooti
❦ 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
❦ 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
❦ 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>
❦ 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
❦ 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
❦ 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
❦ 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
nfig. From there, the dh's standard tools would
> "just work(tm)" until dh_gencontrol where we have to inject the full
> version (the commented lines works around that if re-enabled).
>
> @Vincent: Do you feel something like this would be helpful, useful and
> doable? M
❦ 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
>
❦ 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
❦ 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
one-off
> designs.
>
> => Install gtk3-nocsd by default in all desktop tasks but Gnome. It's not
> perfect but it helps.
I have gtk3-nocsd installed on my machines, but I don't think a
default install is a good idea, as its necessary use via LD_PRELOAD
breaks *any* pro
Package: general
Severity: grave
Tags: security
Justification: user security hole
Affects: mutt
The /etc/mailcap file contains many rules with '%s' instead of %s,
for instance:
text/*; less '%s'; needsterminal
audio/ogg; ogginfo '%s'; copiousoutput
This is incorrect. For instance, Mutt quotes th
On 2019-06-22 10:51:35 +0200, Vincent Lefevre wrote:
[...]
> as seen in strace output:
>
> execve("/home/vinc17/bin/sh.screen", ["sh", "-c", "less
> ''/var/tmp/_.txt''"], 0x564ffe666f40 /* 132 vars */) = 0
FYI, the sh.
On 2019-06-22 10:51:35 +0200, Vincent Lefevre wrote:
> execve("/home/vinc17/bin/sh.screen", ["sh", "-c", "less
> ''/var/tmp/_.txt''"], 0x564ffe666f40 /* 132 vars */) = 0
>
> i.e. the filename is eventually not quoted!
&
On 2019-06-22 10:51:35 +0200, Vincent Lefevre wrote:
> The /etc/mailcap file contains many rules with '%s' instead of %s,
> for instance:
>
> text/*; less '%s'; needsterminal
> audio/ogg; ogginfo '%s'; copiousoutput
>
> This is incorrect.
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
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
❦ 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
❦ 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
❦ 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
On Tuesday 16 July 2019 23:11:24 Florian Weimer wrote:
> * Nicholas D. Steeves:
> > Package name: fuidshift
> > Version : 3.0
> > Upstream Author : Name
> > URL : https://github.com/lxc/lxd/tree/master/fuidshift
> > License : Apache 2.0
> > Programming Lang: Go
> >
❦ 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
❦ 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
❦ 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
❦ 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"
❦ 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
❦ 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
❦ 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
❦ 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
On Fri, 2019-08-30 at 12:20 -0400, Scott Kitterman wrote:
> On Friday, August 30, 2019 12:05:45 PM EDT Russ Allbery wrote:
> > This lets you generate the patches for people on demand, but they aren't
> > just sitting out there for anyone to look at whenever they want.
> >
> > I suppose it could b
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
Le 18/06/2023 à 08:28, Rebecca N. Palmer a écrit :
On 18/06/2023 03:37, Paul Wise wrote:
Presumably any of the OpenCL ICDs work for most packages?
For most OpenCL-using *packages* but not most *hardware*. (Except for
pocl-opencl-icd, which works nearly everywhere but is slow.)
Perhaps ther
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-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
at happens?
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
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
s manual documents how to install and use the Multiple Precision
Floating-Point Reliable Library, version 4.2.0.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
that if the source has been modified, it may be possible that
the second build succeeds but is incorrect. I suppose that you need
to check that both builds are identical.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
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
> have no functional equivalent in NM or would actually conflict with builtin
> functionality of NM.
>
>
> So, the remaining list of packages which I plan to do a MBF for is:
> aoetools
> auto6to4
> avahi-autoipd
> bind9
> chrony
As you rightfully stated higher up, chrony already includes native NM-dispatcher
scripts so you can remove it from the list of affected packages.
Cheers,
Vincent
signature.asc
Description: PGP signature
On 2023-10-26 02:03:49 +0200, Vincent Lefevre wrote:
> Hi,
>
> I've seen on https://tracker.debian.org/pkg/mutt that mutt was
> removed from testing on 2023-10-25, with a link to
>
> https://tracker.debian.org/news/1473564/mutt-removed-from-t
Closes: #1051563).
- CVE-2023-4874 ("Null pointer dereference when viewing a specially
crafted email).
- CVE-2023-4875 ("Null pointer dereference when composing from a specially
crafted draft message").
[...]
--
Vincent Lefèvre - Web: <https://www.vinc17.
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-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-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
give by
the realpath command.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
On 2024-02-14 19:46:58 +0100, Ansgar 🙀 wrote:
> Hi Vincent,
>
> On Wed, 2024-02-14 at 18:20 +0100, Vincent Lefevre wrote:
> > POSIX says:
> >
> > SHELL This variable shall represent a pathname of the user's
> > preferred command lan
On 2024-02-14 10:41:44 -0800, Russ Allbery wrote:
> Vincent Lefevre writes:
>
> > POSIX says:
>
> > SHELL This variable shall represent a pathname of the user's
> > preferred command language interpreter. If this interpreter
> >
/shells on my
> system contains both the /usr/bin and the /bin paths, so I'm still at a
> complete loss.
Not for mksh.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
On 2024-02-15 09:39:51 +0100, Marc Haber wrote:
> On Thu, 15 Feb 2024 00:05:36 +0100, Vincent Lefevre
> wrote:
> >This is invalid. See
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168
>
> That doesnt answer the question asked, it is a bug from 20
On 2024-02-15 16:59:28 +, Holger Levsen wrote:
> On Thu, Feb 15, 2024 at 10:08:11AM +0100, Vincent Lefevre wrote:
> > Not for mksh.
>
> so the subject should be "mksh is broken with usrmerge"?
No, because my bug report about mksh was closed because it is
not
irement on what pathnames $SHELL may contain (in the
case a same shell can be referenced by several pathnames, e.g. due to
the /bin -> /usr/bin symbolic link) is not acceptable. Hence my post
about this.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML -
o the path from passwd(5), which hopefully
> is from shells(5).
login(1) is not the only way to start a shell.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
a
restricted shell, the user may set $SHELL to a non-restricted
shell. Moreover, /etc/shells also contains restricted shells.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
On 2024-02-15 16:17:58 -0800, Russ Allbery wrote:
> Vincent Lefevre writes:
> > On 2024-02-15 14:14:46 -0800, Russ Allbery wrote:
>
> >> and pkexec is essentially a type of sudo and should be unavailable to
> >> anyone who is using a restricted shell.
>
>
ere are no issues with aliases pathnames in this case.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
I thought
that the presence of /var/lib/dpkg/info/*.md5sums would be sufficient
to detect issues. So, what's the point of these files?
[1] https://wiki.debian.org/MaintainerScripts
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http
y the end user / admin).
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
t... except by the Debian installer!
This is inconsistent.
So, in the present case, uuid-runtime wasn't installed by default,
though libuuid1 was installed and had a "Recommends: uuid-runtime".
But with the 64-bit time_t transition, libuuid1 got replaced by
libuuid1t64 a f
t;
> Correct. This is tracked as bug#742977
Bug#742977 is about whether to mark installed packages as
auto-installed or not. It is not about Recommends.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Wor
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 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
Is the salsa web server broken?
The display of https://salsa.debian.org/python-team/packages/fail2ban
is completely wrong, and https://salsa.debian.org/ gives an
error 500 "We're sorry. Something went wrong on our end.".
--
Vincent Lefèvre - Web: <https://www.vinc17.net
On 2024-05-24 11:51:15 +0200, Alexander Wirt wrote:
> Am Fri, May 24, 2024 at 11:23:44AM +0200 schrieb Vincent Lefevre:
> > Is the salsa web server broken?
> >
> > The display of https://salsa.debian.org/python-team/packages/fail2ban
> > is completely wrong, and https:/
dresses and the
host names with "last" (I don't know whether there's a better way to
get full information).
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - compute
1201 - 1300 of 1630 matches
Mail list logo
