On 2019-10-07 13:43, Johannes Schauer wrote:
Quoting Philipp Kern (2019-10-07 13:21:36)
On 10/7/2019 1:17 PM, Shengjing Zhu wrote:
> On Mon, Oct 7, 2019 at 6:29 PM Simon McVittie wrote:
>> On Mon, 07 Oct 2019 at 07:22:53 +0200, Johannes Schauer wrote:
>>> Specifically, curren
be the correct solution for
consistent versioning across all architectures. Ubuntu exclusively does
those and I still struggle how we would build such a service in Debian
without facing exactly the same concerns as tag2upload. Maybe if dak
itself would do it?
Kind regards
Philipp Kern
voted and if
those people are the most active in the project. But I don't think that
this is particularly useful distinction. For the best we know the others
did not care enough to vote (or were unable to for technical reasons)
and were thus ok with any outcome. Also we welcome people to join the
proj
oice for *periodic jobs* that we
should document as the default unless there is a reason to use something
else. It does not need to be cron, though.
Kind regards
Philipp Kern
that journalctl's (and also
systemctl status') performance reading journal files is still pretty
awful on spinning rust[1]. At times this makes me go to text logs
instead because slicing the files using tail and grep is much, much
faster.
Kind regards
Philipp Kern
[1] I think this
re, for which allowlist and rejectlist are
terms that actually describe what is happening in most contexts.
Of course communities also build up some slang to see who is "in" the
group and who is "out". But it actually makes things more accessible to
others if you describe things as they are.
Kind regards
Philipp Kern
to look at potential whitelisting code, but I think last time
someone tried a big refactoring and introduction of tests was required
of them prior to the contribution - which is a high bar after getting
dak to run properly for development purposes first.)
Kind regards
Philipp Kern
ts that.
I mean I don't want to suggest that buying hardware is required, but
that's literally what they were designed for. Automatically dealing with
origin information sanely and then a touch signs you in. OTPs are as
fishable as passwords.
Kind regards
Philipp Kern
owners have to do this today for good reasons. That pushes the cost
elsewhere of course. On the other hand it's not the worst idea to
require signatures on all commits instead.
Kind regards
Philipp Kern
Package: wnpp
Severity: normal
I intend to orphan the icon-naming-utils package.
Last upstream release was 11 years ago. There is effectively no churn in
this package. It is also a required build dependency for a bunch of icon
themes:
# Broken Build-Depends:
extra-xdg-menus: icon-naming-utils
gn
l, it looks like GNU which was last updated in 2015 (both tarball and
CVS) and despite GNU redirecting to a github.io page it doesn't look
like there is any more up-to-date repository of it either. So I'm not
sure if maintenance is a great argument here. Although I will note that
Archlinux does not actually patch it.
Kind regards
Philipp Kern
ate in the first place? Everyone
who got access to a debian.org email address has been an OSS contributor
of sorts. Which leaves those who opted out of the email address entirely
(rather than not using it) - but they are free to reactivate it. It
feels like just checking for @debian.org is good enough, IMO.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
rather than not using it) - but they are free to reactivate it. It
>> feels like just checking for @debian.org is good enough, IMO.
>
> Well, DMs don't have debian.org email addresses.
Sure, but I'd expect that state to be temporary, no?
Kind regards
Philipp Kern
sible for someone who
> *only* uses main to download the source, install the build dependencies,
> and successfully build the package themselves. Doing *that* must not
> require anything outside of main.
Somewhat ironically not depending on anything but main is also true for
non-free and contrib. (At least when you want it to be built by the
official builders.)
Kind regards
Philipp Kern
ackages would we need to install to keep track of new
major kernel versions in backports?
Kind regards and thanks
Philipp Kern
rs and see what they think? (Of
course, you could also just point at the precedent, but sometimes things
slip in without ftp-master review.)
Kind regards
Philipp Kern
able in a mission critical environment should do their own
acceptance testing before deploying changes. But the same would be true
with other vendors as well.[1]
Kind regards
Philipp Kern
[1] Well, maybe you could try to hold them liable in certain cases,
depending on the contract, but even then the
er and group
IDs.
Kind regards
Philipp Kern
where it's harder to test this, but maybe that's not even a
real problem in the cases we are talking about.
Kind regards
Philipp Kern
many places like
determining key packages) it would be helpful sometimes to be able to
slice and dice the data into "how many users do have sysvinit as their
init system and use this package". Alas, AFAIU that's not possible
today.
Kind regards
Philipp Kern
[1]
http://ral-
know it's
broken, there seems to be noone else out there who cares enough to fix
it"?
Kind regards
Philipp Kern
word of the PKCS#12 file,
which can be the empty string.)
Probably something like "openssl pkcs12 -export -inkey enrico.key -in
enrico.crt -name enrico -out enrico.p12" and something for the password
to generate the PKCS#12 blob.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
ingle TLS connection (well, one
per host). A casual Wireshark seems to confirm that.
Kind regards
Philipp Kern
On 10/17/2016 08:48 PM, Cyril Brulebois wrote:
> Philipp Kern (2016-10-17):
>> On 10/17/2016 05:39 PM, Cyril Brulebois wrote:
>>> AFAICT from a recent https deployment, apt will perform a TLS handshake
>>> for each and every file it downloads from the mirror; includin
separate package that collects and provides these kind of stubs?
These poly-/ponyfills seem unlikely to ever change their API as well
because they can't, so that should actually be feasible. (I suppose
dependencies are strictly versioned as well and you don't get fixes? Or
packages
had a short
read earlier today and I had no idea how to even report it without that
information. (Of course I know how to turn on debugging but then it
picked a different one and succeeded.)
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
On 10/24/2016 09:19 AM, Tollef Fog Heen wrote:
> ]] Philipp Kern
>> On 10/18/2016 06:47 PM, Marco d'Itri wrote:
>>> On Oct 17, Ian Campbell wrote:
>>>> Have we gotten to the point where we consider deb.d.o suitable for
>>>> production use? The web
in doing that when modifying the key set.)
Nothing a SPI programmer can't fix, but it'd be annoying nonetheless.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
adapter ROM) if executed on the main CPU. The printer example is not
particularly relevant to that.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
it also only tells you how to
pin one of the two CDNs on its homepage. Maybe we could fix that and
then let users pick one rather than letting everyone round-robin between
them... (Something in me wants to tongue-in-cheek suggest to couple
httpredir and deb.debian.org to pick the sanest CDN for the
nds of the onion balancer), we could have the same
with an HTTPS-based solution just fine. It'd likely raise the same
scalability and operational questions as HTTPS. Your proposal here
simply has different tradeoffs, not none as you claim.
Kind regards
Philipp Kern
viewable
by humans, a stable update could be possible. It's still on a
case-by-case basis, so you would need to ask and the Release Team cannot
approve what they do not know about.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
includes this, but I think it would be nice to
explicitly mention source uploads work too.)
Packages are only built when accepted from p-u-NEW. We require binary
uploads to be able to review the binary debdiffs (see e.g. the binary
debdiff links on [1]).
Kind regards
Philipp Kern
[1] https
I think
we are beyond the "let's collect random modules into big packages" at
this point but it's IMO still fair to call out problematic ones like
this one.
Kind regards
Philipp Kern
[1] https://github.com/gulpjs/has-gulplog/blob/master/index.js
signature.asc
Description: OpenPGP digital signature
vers should not simply be restarted while clients are actively using
them.
I can see how it's slightly less dangerous with stateless services like
DNS, where people might just not bother.
Kind regards
Philipp Kern
ge
> that, and instead make this opt-out.
It's not "explicitly subscribe to buildd failure" AIUI, but "subscribe
to the package". I.e. it's part of the default set of tags and anyone
who was subscribed to "default" when the buildd was added got it added
to their subscription.
Kind regards
Philipp Kern
s output). The excludes are configured in
/srv/buildd.debian.org/etc/buildlogs.conf and do not list all (but
various unofficial ports). Maybe you could argue that kfreebsd-* should
be in there as well, but that's a different discussion.
Kind regards
Philipp Kern
stable, notice a bug,
rinse and repeat...
Kind regards
Philipp Kern
, sure. But I don't think the
way they are used right now can be used for jokes except by quite
ignorant people.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
isn't relevant to the discussion.
I do sympathize with the "drop md5sum to see what breaks". But that's a
discussion for after the release. And how you formulate your argument
does not help your case.
Kind regards
Philipp Kern
en dpkg is invoked. In this case having also the size or a
combination of hashes would make me more comfortable.
Anyway, that said, is there a bug on this on the dpkg side already?
Kind regards
Philipp Kern
ak as DD.
I suggest that you take your vitriol elsewhere, not to Debian lists.
Kind regards and thanks
Philipp Kern
signature.asc
Description: OpenPGP digital signature
ort the archive can ensure that the build
profile was actually the default one (or accept divergences with a
conscious decision, like using NEW or BYHAND).
So I don't think it's as black and white wrt full flexibility in
dependencies as you paint it. :)
Kind regards
Philipp Kern
can never be fully trusted
anyway. :)
Fair enough. I guess at which point it boils down to archive
deficiencies within dak in particular that buildinfo and changes content
are not easily accessible, because they are not kept as part of archive
metadata that can be synced.
Kind regards and thanks
Philipp Kern
les)
FWIW, this technically isn't required. You can simply overwrite existing
modules and dkms will handle that fine. It will shadow the stock ones
when putting the new versions into updates/dkms.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
ds anyway.
So what's the difference between setting DEB_BUILD_OPTIONS=parallel=n
and -Jn then? The former has some precedent in being set on build
daemons, so I'd assume that -Jn doesn't regress behavior here? Or is the
suggested interface the environment variable?
Kind regards and thanks
Philipp Kern
nd-guess, but I think you can at least
enforce some comment to be present. As someone who now ponders to
re-introduce the package I have zero context as well as to why the
package got removed and if it's sensible to re-introduce it in the first
place.
(Note that nothing here is intended to assign some kind of personal blame.)
Kind regards
Philipp Kern
d upon and closed.
Kind regards
Philipp Kern
am version. But I'd say that rollbacks are exactly that:
reuse of a different epoch with the same upstream version. Like what
happened to imagemagick multiple times.
Kind regards
Philipp Kern
On 09.02.2018 17:02, Ian Jackson wrote:
> Philipp Kern writes ("Re: Debian part of a version number when epoch is
> bumped"):
>> You say upstream version. But I'd say that rollbacks are exactly that:
>> reuse of a different epoch with the same upstream v
On 09.02.2018 18:20, Russ Allbery wrote:
> Philipp Kern writes:
>> On 09.02.2018 17:02, Ian Jackson wrote:
>
>>> I don't know precisely what you mean by "rollback". If you mean
>>> "change our mind about uploading foo new upstream version 3, a
oming up with
arbitrary deadlines of support are not all that helpful. Users don't
care if the ancient version of the software they need in stable is
security supported until mid-2022. If it doesn't satisfy their
requirements anymore, they move to testing or to another distribution.
Kind regards
Philipp Kern
as well. But they might
be somewhat transiently connected and I don't think there are prompts on
device plug-in?
Kind regards and thanks
Philipp Kern
right because for some reason our tools rely on the whole delta
to be present in the .changes file rather than inferring it from the
in-package changelog. So bug closure information gets lost unless you're
careful in how you build the package, which makes it more likely to get
wrong.
Kind regards
Philipp Kern
ith arch: all packages.
The recommended way today is to annotate within the package. It does not
actually interact poorly with arch:all packages. When dpkg builds the
source package and there's no arch:any package it will list all
architectures explicitly in the .dsc and if there's an arch:all package
all will be added in addition.
Kind regards
Philipp Kern
On 9/3/17 11:40 AM, Philipp Kern wrote:
> On 2017-09-02 23:48, Holger Levsen wrote:
>> On Mon, Jul 03, 2017 at 07:23:29PM +0200, Philipp Kern wrote:
>>> > Not yet. We people from the reproducible team couldn't find a way to
>>> > usefully talk to ftp-master
ad.
(There's of course also the question of VAC notices to crawl, though. If
someone went away for a longer period of time with an intent to come
back, it should be fair game to fix the package and own related breakage
but obviously not to just hijack it away from the original maintainer.)
Kind regards
Philipp Kern
g on the technical side.)
Kind regards
Philipp Kern
ou are done with the conference/sprint.
Kind regards and thanks
Philipp Kern
On 2018-04-19 23:00, Christoph Biedl wrote:
Philipp Kern wrote...
Turns out that this is a terrible idea.
Because?
People will start to rely on names for sorting again. Regardless if it's
the right thing technically people are people and will use what tools
they have available.
e to integrate udev with debhelper so
that the correct snippet could be generated for various packages'
postinsts instead of everyone who ships a rules file hand-rolling it. Of
course if people actually need to write complicated rules to select the
rules to re-trigger, that seems much more dif
;t say that it isn't valuable to have packages in case someone
runs something in the background. Just like there should be a solid
solution for repository management, there should be one for building.
But the infrastructure needs of Debian itself are different.
Kind regards
Philipp Kern
ile from the new postinst.
What's the consequence from deleting the files and only recreating them
later? Longer startup time of the interpreter in that short window?
Because if it's worse, it'd be good to have py3clean only delete the
obsolete files in the postinst?
Kind regards
Philipp Kern
27;re asking for trouble anyway if
your home directory contains a space, but this script will break in
interesting ways. :)
I did not look at the original code of pass, but I don't find this code
handling secrets confidence inspiring, to be honest.
Kind regards
Philipp Kern
[0]
https://lists.zx2c4.com/pipermail/password-store/2016-January/001932.html
places. Especially if it's something that handles a
user's secrets.
> Whoever stops auditing this Bash application because it does not> start with
> `set -e`, does not have the right skills and experience
for> reviewing/auditing it.
And these ad hominems are just unhelpful.
Kind regards
Philipp Kern
oard
> gpg: can't open '/home/pkern/.pw/pw.tgz': No such file or directory
> gpg: symmetric encryption of '/home/pkern/.pw/pw.tgz' failed: No such file or
> directory
But as soon as tar writes incomplete output (which it totally can, it's
a Tape ARchiver) you have silent corruption.
Kind regards
Philipp Kern
On 16.07.2018 15:14, Dashamir Hoxha wrote:
> On Mon, Jul 16, 2018 at 2:16 PM Philipp Kern <mailto:pk...@debian.org>> wrote:
>
> rather than trying to appeal to authority like Marc - I could have been
> wrong -, I will point out that my first point was not actually a
On 2018-07-16 15:58, Andrey Rahmatullin wrote:
Can we assume you didn't look at the code trying to follow the logic
and
you don't have the full picture?
Can we please stop here? It takes grace to take back the request.
Kind regards and thanks
Philipp Kern
On 2018-07-18 18:24, ju xor wrote:
Philipp Kern:
Should this live in some kind of tor-* namespace?
no
Without any rationale? :(
Kind regards
Philipp Kern
ure that glibc splits out libcrypt into its own package, have
libc6 depend on it and then provide libcrypt1? (Because it's really
providing libcrypt's ABI from another package.) Versioning might be
tricky, though.
Kind regards
Philipp Kern
On 20.07.2018 10:18, Marco d'Itri wrote:
> On Jul 20, Philipp Kern wrote:
>> Make sure that glibc splits out libcrypt into its own package, have libc6
>> depend on it and then provide libcrypt1? (Because it's really providing
>> libcrypt's ABI from another
On 18.07.2018 20:38, ju xor wrote:
> Philipp Kern:
>> On 2018-07-18 18:24, ju xor wrote:
>>> Philipp Kern:
>>>> Should this live in some kind of tor-* namespace?
>>> no
>> Without any rationale? :(
> i'm not sure what you mean, but in case it
ourse in Debian that mechanism is called GR or appealing to the
tech-ctte and letting them vote (and then maybe another GR, hah).
Kind regards
Philipp Kern
x27;t actually rely on a support
contract.
For s390x I can say that the port was driven without any commercial
interest on both Aurelien's and my side.
Kind regards
Philipp Kern
ual
address space or don't have modern languages like Go or Rust around, it
quickly approaches the point where it's not worth it anymore.
Kind regards
Philipp Kern
at least
need to hold them accountable to listening to feedback.
> That way, the vendors could just pick some minimal base system (maybe
> apline or devuan based) [...]
That's also where you lost me, FWIW.
Kind regards
Philipp Kern
s well as an
actual shell script that checks for the preconditions. Would anacron and
cron need to be depended upon in that case or would they could they even
just be recommended? Both would not be needed on a default Debian system
that ships with systemd.
Kind regards and thanks
Philipp Kern
[
On 2018-10-16 14:36, Ian Jackson wrote:
Philipp Kern writes ("Re: Debian Buster release to partially drop
non-systemd support"):
Could someone reiterate about what the current state of init diversity
is supposed to be? Is it assumed to be best effort of every maintainer
being requir
to /etc/crontab (a conffile). And you'd of course still have cron
wake up to execute the shell statement.
But it's not like timer units are forbidden. Just like my
introductionary statement of "but if you use a different system not
considered an init system, you are fine", there's nothing in policy
mandating periodic jobs to work in a particular way. It just talks about
what to do if you do ship a cronjob.
Kind regards
Philipp Kern
a GNU operating system.
You particularly seem to only need a Systemd operating system.
So what you want is https://www.gnu.org/software/shepherd/?
Kind regards
Philipp Kern
;s not how the law works in the US. Without actual litigation
and precedent, the most you'll get is a risk assessment of getting sued
and your likelihood of winning if so. :)
Kind regards and IANAL
Philipp Kern
7;"
I suppose it'd be useful to have a generalized solution to this. :/
Kind regards
Philipp Kern
of Debian packaging work. And the same is likely true for cowdancer
itself - although it's theoretically more brittle - with the twist that
for some reason pbuilder does not have native support for it.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
n a network file
system, but that's then shared with other GNOME applications using it.)
Kind regards
Philipp Kern
enial and
up (VersionedKernelPackages in /etc/apt/apt.conf.d/01autoremove). For
Trusty (and Precise and Lucid) we wrote our own tooling to deal with
this issue.
Kind regards
Philipp Kern
[*] Ubuntu doesn't bump the ABI on *every* new version, just the ones
changing the ABI. In reality t
x27;t think it's quite that easy, but I wish you luck. :)
However in terms of how to get it in in the first place: For
bootstrapping the usual way is to do an upload per architecture that has
been built using a locally installed version of the package and then
binNMU it in the archive again
builder's _ARCH.buildinfo actually
corresponds to the published binaries, that clearly must take
precedence.
Is the buildinfo actually published today? I don't see it in the pool.
As I would've had some use for them at work I was sort of curious if
they could be ingested automatically.
Kind regards and thanks
Philipp Kern
On 07/03/2017 07:06 PM, Mattia Rizzolo wrote:
> On Mon, Jul 03, 2017 at 07:00:20PM +0200, Philipp Kern wrote:
>> [ Correcting ftp-master's email address, but keeping the large list of
>> recipients for some reason. ]
>
> really… that's just a ftp-master is
traightforward, given that it's
a consensual revert applied upstream.
I think this could be suitable for stable, but I'd suggest to you to
hash out the potential disagreement[2] in private mail to the
maintainers rather than on project-wide mailing lists (not even cc'ing
them).
Kind regards
On 2017-07-10 10:32, Pirate Praveen wrote:
On 07/10/2017 01:38 PM, Philipp Kern wrote:
On 07/10/2017 07:00 AM, Pirate Praveen wrote:
[Moving to -devel]
Not sure why, as this seems to be a release matter.
Because I wanted to get inputs from other developers on how to proceed.
Without
te on. Instead you get a bunch of match expressions. Which
leaves things like daemons, which more often hardcode IP addresses than
interfaces, though.
Kind regards
Philipp Kern
[1] Which indeed has flaws, most notably with IPv6.
signature.asc
Description: OpenPGP digital signature
ion, that I don't know[1].
Kind regards
Philipp Kern
[1] Although I feel like I should.
signature.asc
Description: OpenPGP digital signature
resent in the binary? For the
latter I'd imagine something with a low certainty suggesting that you
depend on a certain meta package. (To catch the cases where there's
actually autodetection at runtime.)
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
. To the point that I already
considered raising the baseline and at least retiring the builder that
does not support the higher architectural requirement. You end up with a
lot of packages being technically unbuildable and unrunnable on older
machines.
Kind regards
Philipp Kern
[1] Which isn't
urpose back then being to connect to the ICQ (and MSN?) services.
Someone wrote a Free client implementation, hence we should offer it to
our users. I could pull other strawmans like "what about tools that
connect to the telephone network, which is non-free?". Where would we
even draw that line
same time holding testing hostage does not feel right to me. I
applaud the intention, but I strongly dislike the implementation.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
freedom to our users?
The agreed-upon baseline is the DFSG which does not offer this premise
you interpret as a guarantee, though.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
On 08/27/2017 12:20 PM, Dr. Bas Wijnen wrote:
> On Sat, Aug 19, 2017 at 06:21:23PM +0200, Philipp Kern wrote:
>> On 08/18/2017 10:36 AM, Dr. Bas Wijnen wrote:
>>> Consider the following: unrar-nonfree contains some software which is
>>> non-free
>>> and can t
On 2017-09-02 23:48, Holger Levsen wrote:
On Mon, Jul 03, 2017 at 07:23:29PM +0200, Philipp Kern wrote:
> Not yet. We people from the reproducible team couldn't find a way to
> usefully talk to ftp-masters people, whom never replied to any of the
> questions in the thread at #763
quired targets may attempt
> network access.
And then again it should allow for network access (including bind(2)) to
localhost.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
601 - 700 of 750 matches
Mail list logo
