Hi,
Le 2024-12-13 13:38, IOhannes m zmölnig a écrit :
and *of course* all usernames have been normalized to lowercase ASCII.
I just took a look at some reasonably recent government-issued IDs and
it turns out the French ones normalized my name to uppercase
whatever-some-clerk-had-on-their-t
Le 2024-12-11 15:04, Pirate Praveen a écrit :
Many firewalls (for example in offices) also block almost every port
other than 80 or 443. So it'd still be valuable to have a web based
reportbug interface.
Well, usually they just block everything including ports 80 and 443,
often one has to u
Le 2024-12-11 15:00, Alec Leamas a écrit :
Well, "some places" includes basically all home users, at least in
Sweden where I live. This is not about ISPs blocking "some traffic",
they only block outgoing smtp traffic on default ports. The reasons are
obvious.
Did you try to connect using TC
Le 2024-12-11 13:52, Pirate Praveen a écrit :
reportbug can talk SMTP directly, is that not enough for you?
without configuring an smtp server? If I run reportbug and clicks
submit, does it send mail without any extra configurations?
It does, and that works for me (though maybe not from some
Hi,
Let me plop in right into this discussion with no general solution and
more things to think about. For the context I'm packaging Java things,
and Java has historically been notoriously bad at guessing how much
memory it could actually use on a given system. I'm not sure things are
much be
Hi,
Le 2024-12-05 16:43, Theodore Ts'o a écrit :
Given recent discussions about depends vs recommends vs suggests
inflation, I'm thinking about down-prioritizing e2fsprogs-l10n from
recommends to suggests.
Thoughts, comments?
There are existing task- and task--desktop
metapackages, but curr
Le 2024-11-29 18:35, Jonas Smedegaard a écrit :
Quoting sre4e...@free.fr (2024-11-29 16:57:23)
opened 15 years and a few days ago.
Great that you took "filing a bugreport" to imply checking first if
the issue was already reported.
Well, the point I wanted to make here was more about the spec
Le 2024-11-29 10:58, Simon Josefsson a écrit :
The only record of this is
indirectly with the maintainer signing the *.changes file during
package
upload. But that is weak (only successfully uploaded packages are
protected, not work-in-progress) and not widely audited (*.changes
files
aren't
Le 2024-11-29 15:12, Jonas Smedegaard a écrit :
Quoting sre4e...@free.fr (2024-11-29 13:29:05)
Would it be possible to make it the default when there is already an
existing `pristine-tar` branch in the repo being worked on?
Please consider filing that as a bugreport against bit-buildpackage -
Hi,
Le 2024-11-29 03:17, Otto Kekäläinen a écrit :
but right now I warmly recommend people use 'pristine-tar = True' in
their gbp.confs.
Would it be possible to make it the default when there is already an
existing `pristine-tar` branch in the repo being worked on?
Cheers,
--
Julien Pliss
Hi,
Le 2024-11-28 11:28, Alec Leamas a écrit :
Personally, the few packages I maintain are mostly repacked. Isn't
there also value in storing the hash of the repacked tarball, the thing
actually used?
Not much value, as both the hash and the data would be stored at the
same place (git repo
Hi Johannes,
Le 2024-11-22 12:45, Johannes Schauer Marin Rodrigues a écrit :
That's what I'm doing. But that works with tarballs not with upstream
as git.
If upstream (deliberately, so this will not change) has DSFG-non-free
content
in it, then I should not copy that into a git packaging repo t
12 matches
Mail list logo
