Re: .deb format: let's use 0.939, zstd, drop bzip2

der for ar was much simpler than for tar. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: .deb format: let's use 0.939, zstd, drop bzip2

means we should keep the property that a .deb can be unpacked with non-Debian-specific shell tools. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: Preferred git branch structure when upstream moves from tarballs to git [and 1 more messages]

Holger Levsen writes ("Re: Preferred git branch structure when upstream moves from tarballs to git [and 1 more messages]"): > On Thu, May 09, 2019 at 01:46:19PM +0100, Ian Jackson wrote: > > debcheckout *certainly* doesn't do this. It just gives you the > > current maste

Re: .deb format: let's use 0.939, zstd, drop bzip2

that be entangled with some random other nice-to-haves. Personally I still like my multi-ar-member proposal here https://lists.debian.org/debian-dpkg/2016/05/msg00027.html Guillem didn't seem entirely unreceptive but nothing came of it. Ian. -- Ian JacksonThese opinions are my own. If I emai

Re: Preferred git branch structure when upstream moves from tarballs to git [and 1 more messages]

Holger Levsen writes ("Re: Preferred git branch structure when upstream moves from tarballs to git [and 1 more messages]"): > On Wed, May 08, 2019 at 04:14:00PM +0100, Ian Jackson wrote: > > * Debian should provide source code as git branches which: > - can be buil

Re: Preferred git branch structure when upstream moves from tarballs to git

workflows are wrong; it is a very religious kind of topic. Let us save that for a bar conversation some time ... HTH. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: Preferred git branch structure when upstream moves from tarballs to git

quot;preferred form for modification" is "preferred by who", of course. As I say above, maintainers and (at least a big subset of) users/downstreams have different opinions. Happily since the maintainer's view is always an ancestor of the corresponding dgit view, publishing the dgit v

Re: .deb format: let's use 0.939, zstd, drop bzip2

es an example here.) As for the size limit, this was discussed in May 2016: https://lists.debian.org/debian-dpkg/2016/05/msg00027.html (I can't find a bug about it, though). I made a proposal. No decision was made and nothing was done, unfortunately. Ian. -- Ian JacksonThese op

Re: Configure your PC to contribute to Debian community

build tool. To make a chroot you can use sbuild-createchroot or, err, I forget what it's called, schroot-buildd-setup or something ? Maybe someone else will pop up with the answer. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, th

Re: Preferred git branch structure when upstream moves from tarballs to git

Simon McVittie writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"): > On Sat, 04 May 2019 at 21:10:34 +0100, Ian Jackson wrote: > > So far I have gained the impression that > > the kind of people who are using packaging-only git

Re: Preferred git branch structure when upstream moves from tarballs to git

Simon McVittie writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"): > On Tue, 07 May 2019 at 19:25:39 +0100, Ian Jackson wrote: > > What I am primarily advocating for in this thread is that maintainers > > should choose `dgit push-s

Re: Preferred git branch structure when upstream moves from tarballs to git

Simon McVittie writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"): > On Wed, 08 May 2019 at 12:18:41 +0100, Ian Jackson wrote: > > Indeed, you yourself say you avoid gbp but for many packages, the > > Vcs-Git header gives you a patch

Re: Preferred git branch structure when upstream moves from tarballs to git [and 1 more messages]

or the suggestion. In the meantime, > > [Ian Jackson:] > > > You should use dgit for the benefit of users. See my other mail which > > > answers why Vcs-Git and debcheckout is not enough. > > > > could you be so kind and provide a pointer, this thread is rather l

Re: Preferred git branch structure when upstream moves from tarballs to git

Holger Levsen writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"): > On Wed, May 08, 2019 at 12:18:41PM +0100, Ian Jackson wrote: > > I'm not sure what git branch format you are using. (Maybe you said it > > earlier in this thread.) Pa

Re: Preferred git branch structure when upstream moves from tarballs to git

> "If you disagree with me that everyone should do X then you are > unethical" I meant the former. I definitely don't mean to say that all the people not doing what I think is best, are bad people. Regards, Ian. -- Ian JacksonThese opinions are my own. If I emailed yo

Re: Preferred git branch structure when upstream moves from tarballs to git

is more complicated > and harder to grasp, so I'm still on that old slicing machine, which I > know since many years and which I can easily fix if the bread gets stuck > or the knifes need resharpening or some such. Yes, I quite understand this point of view. Regards, Ian. -- Ian Jacks

Re: Preferred git branch structure when upstream moves from tarballs to git

Sam Hartman writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"): > Ian Jackson writes: > > The latter point is because using dgit push is an ethical > > imperative, not because the two somehow have some deep > > technical link

Re: Preferred git branch structure when upstream moves from tarballs to git

ing bread perhaps I > should come up with a new metaphor, but it's really neat regardless of > what metaphor I use. Heh. > Still, this stuff is hard. git-debrebase is perhaps hard. It's certainly new. dgit is no harder than it needs to be, and easier than dpkg-source. I hope you

Re: Preferred git branch structure when upstream moves from tarballs to git

- dgit push |dput / dupload || dput NMUer must choose a stack, although if they use a gitish workflow they can mix-and-match upload tools. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org

Re: Preferred git branch structure when upstream moves from tarballs to git

ps://manpages.debian.org/stretch-backports/dgit/dgit-maint-debrebase.7.en.html#EDITING_THE_DEBIAN_PACKAGING et seq. An equivalently detailed and frank document about dpkg-source would be a nightmare. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or

Re: Preferred git branch structure when upstream moves from tarballs to git

Ben Finney writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"): > Ian Jackson writes: > > [...] I have not taught dgit how to convert [separate Debian > > packaging-only repository and upstream source repository] into a git > > t

Re: Preferred git branch structure when upstream moves from tarballs to git

Ansgar writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"): > On Fri, 2019-05-03 at 15:59 +0100, Ian Jackson wrote: > > Ansgar writes ("Re: Preferred git branch structure when upstream moves from > > tarballs to git"):

Re: Preferred git branch structure when upstream moves from tarballs to git

corresponds to what is in the archive. Have the maintainer's history. This is usually in a format useful to the maintainer, but it is not standardised. It may be the packaging history for a whole packaging ecosystem. It may be a linear history of a gbp pq branch. It may be a

Re: Preferred git branch structure when upstream moves from tarballs to git

Ben Hutchings writes ("Re: Preferred git branch structure when upstream moves from tarballs to git"): > On Thu, 2019-05-02 at 11:23 +0100, Ian Jackson wrote: > > Sorry for shouting, but, really. It is kind of frustrating to have > > designed and implemented and

Re: Preferred git branch structure when upstream moves from tarballs to git

e if you only use gbp and dput. What is happening there is that you are uploading a different thing to what you have in git, and not noticing. We don't tell people to not use lintian because it produces error messages, do we ? Ian. -- Ian JacksonThese opinions are my own. If I emailed you from a

Re: Preferred git branch structure when upstream moves from tarballs to git

a useable and correct and standardised git branch which can be used for building the package, developing patches, and sharing the results. The problem of streamlining the Debian maintainer's upload process to be more like "git push" remains. -- Ian JacksonThese opinions are

Re: Preferred git branch structure when upstream moves from tarballs to git

tuff? I think we should have a separate manpage. This kind of conversion stuff is (hopefully) used rarely. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: Preferred git branch structure when upstream moves from tarballs to git

Gard Spreemann writes ("Preferred git branch structure when upstream moves from tarballs to git"): > Recently, upstream has finally started using git. What is the > recommended way for me to maintain a sane branch structure for the > packaging repository while starting to use upstream's git

Re: Discussion on eventual transition away from source packages

e tag and feed the results to gpgv (and to work around infelicites in gpgv). Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Accepted chiark-utils 6.0.4 (source) into unstable

Jackson Changed-By: Ian Jackson Description: chiark-backup - backup system for small systems and networks chiark-really - really - a tool for gaining privilege (simple, realistic sudo) chiark-rwbuffer - readbuffer/writebuffer: prevents tape drive seesawing, etc. chiark-scripts - chiark system

Re: Reg: Debian Source code

Boyuan Yang writes ("Re: Reg: Debian Source code"): > Here are some resources that I am aware of: > > * By running "apt source ", you will be able to retrieve the > source code for that certain source package that corresponds to the > you indicated. `dgit clone ' does the same but ensures

Re: gbp-buildpackage showing change outside debian/, possibly after DEP-14 conversion

arning about this at some point, depending on at what stage you invoked dgit.) See https://manpages.debian.org/testing/dgit/dgit.7.en.html#GITATTRIBUTES for a discussion of the issue and https://manpages.debian.org/testing/dgit/dgit.1.en.html (search forward for `attrib') for details of what that

Bug#924037: Please add anacron back to task-desktop and task-laptop

Diversity team debian-init-divers...@chiark.greenend.org.uk should be consulted so that the appropriate fixes can be developed. Finally, this change is rather late wrt the freeze. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk

Accepted dgit 8.4 (all source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 01 Mar 2019 21:53:40 + Source: dgit Binary: dgit git-debrebase dgit-infrastructure Architecture: all source Version: 8.4 Distribution: unstable Urgency: medium Maintainer: Ian Jackson Changed-By: Ian Jackson Closes

Accepted xen 4.11.1+26-g87f51bf366-3 (all amd64 source) into unstable

: Debian Xen Team Changed-By: Ian Jackson Closes: 923013 923401 Description: libxen-dev - Public headers and libs for Xen libxencall1 - Xen runtime library - libxencall libxendevicemodel1 - Xen runtime libraries - libxendevicemodel libxenevtchn1 - Xen runtime libraries - libxenevtchn

Re: FYI/RFC: early-rng-init-tools

itical to the security properties of your scheme, then I would be making a much stronger complaint, because RC4 is (of course) broken (when used as a supposedly cryptographically secure pseudorandom bitstream generator). I hope you have found this review helpful. Regards, Ian. -- Ian Jackson

Re: FYI/RFC: early-rng-init-tools

suming that either (i) the entropy estimate provided on next boot is no bigger than the kernel's entropy counter at shutdown OR (ii) the kernel's PRNG was at any time properly seeded so that /dev/random unblocked. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @f

Re: FYI/RFC: early-rng-init-tools

her out of date since I left academia and I have not reviewed Thorsten's design in detail. Thanks, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: Use of the Build-Conflicts field

be that people think it isn't. I also expect that subject to the constraint that this won't generate RC bugs, people will be generally happy to have policy write down roughly what the criteria are for putting in a Build-Conflicts. Ian. -- Ian JacksonThese opinions are my own.

Accepted xen 4.11.1+26-g87f51bf366-2 (all amd64 source) into unstable

: Debian Xen Team Changed-By: Ian Jackson Closes: 798510 826871 851654 862236 911045 911046 912381 919758 Description: libxen-dev - Public headers and libs for Xen libxencall1 - Xen runtime library - libxencall libxendevicemodel1 - Xen runtime libraries - libxendevicemodel libxenevtchn1 - Xen

Re: Removal of linux-base from jessie-backports broke Xen upstream CI

then of course next time I can not write it up as a learning opportunity for Debian. I can just work around it instead. Rhonda D'Vine writes ("Re: Removal of linux-base from jessie-backports broke Xen upstream CI"): > On 2/13/19 1:09 PM, Ian Jackson wrote: > > 1. Packages should not

Re: Removal of linux-base from jessie-backports broke Xen upstream CI

tup, so this ought not to cause snapshot any difficulties.) Thanks to everyone behind snapshot.d.o which is, as ever, invaluable. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: Removal of linux-base from jessie-backports broke Xen upstream CI

om June!) that I missed; https://lists.debian.org/debian-backports-announce/2018/07/msg0.html I have to say I'm not sure this removal is very helpful but then I'm not helping maintain -backports so I guess my opinion doesn't carry much weight. Ian. -- Ian JacksonThese opinions a

Removal of linux-base from jessie-backports broke Xen upstream CI

und any explanation somewhere but perhaps I looked in the wrong places. Q. Why was linux-base removed from jessie-backports ? Opinions and suggestions welcome. Thanks, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org

Re: Recreating history of a package

but it could be easily > modified to grab the entire history of the package (as defined by it's > changelog). Cool, thanks! Have you considered making a package of it ? Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, tha

Re: Hierarchical tasksel / Blends support (Was: Debian Installer Buster Alpha 5 release)

node, or email me here. Regards, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: Recreating history of a package

er order, one might write something to look inside the package at the changelogs to try to discern the branch structure. I think the Launchpad folks have some code which can do this. Ian. [1] Caution: may not be true. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.

Re: Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

ically our sensible choices for the default are C.UTF-8 One of en_{AU,GB,NZ}.UTF-8 All of these would be better than en_US.UTF-8 for the reasons given by Adam (although, Adam, really, could you try to be a little less rude?). The middle-endian dates and 12-hour clock are particularly poor default

Re: Reusing source package name of long-removed, unrelated package

is sometimes better than picking a new name. To Gard: waiting for a few more opinions and then deciding is a good plan. Regards, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: Reusing source package name of long-removed, unrelated package

ge - unless it had some kind of ad-hoc and unreliable heuristic, perhaps. Someone who searches for archived bugs for your source package will find their search results contain bugs for the previous package of the same name. Also, using a different name means you do not need to use an epoch, which i

Re: Is multiple-layers of alternatives a good thing to users?

tually invoked. I agree that multiple layers of alternatives indirection is undesirable. But I think these libraries can be made coinstallable without that. HTH. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: Potentially insecure Perl scripts

> Either way, > the fact remains that if untrusted/unsanitised input is being passed > into your @ARGV, then something is already wrong. It is worth > noting that it took a real (embarged) RCE exploit to get the wheels in > motion to eventually fix '.' in @INC. Maybe we should not

Re: Potentially insecure Perl scripts

Holger Levsen writes ("Re: Potentially insecure Perl scripts"): > On Thu, Jan 24, 2019 at 03:18:40PM +, Ian Jackson wrote: > > To the Debian Perl maintainers: [...] > > To the Debian security team: [...] > > I've read the whole thread and am surprised &quo

Re: Potentially insecure Perl scripts

hypothetical fixed <> (ii) we're probably in a small minority of a tiny minority here (iii) changing the workaround so it works for both is easy. So I think this was a reasonable question to ask, but the answer is that this is very unlikely to be a significant problem. Ian. -- Ian JacksonT

Re: Potentially insecure Perl scripts

Ian Jackson writes ("Re: Potentially insecure Perl scripts"): > Even if we care only about scripts which are part of Debian, rather > than scripts which people merely expect to run on Debian (and where > they trust Debian to not blow their leg off), there will probably be &

Re: Potentially insecure Perl scripts

of scripts. Even if we care only about scripts which are part of Debian, rather than scripts which people merely expect to run on Debian (and where they trust Debian to not blow their leg off), there will probably be many thousands. Ian. -- Ian JacksonThese opinions are my own. If I emai

Re: Potentially insecure Perl scripts

Ian Jackson writes ("Re: Potentially insecure Perl scripts"): > The right answer is to fix the behaviour to be secure and sane by > default. We can arrange for an environment variable for people who > want to turn the crazy back on. To the Debian Perl maintainers: if I make a

Re: Potentially insecure Perl scripts

istent with the "formal specification" (such as it is) of the behaviour of <>. The right answer is to fix the behaviour to be secure and sane by default. We can arrange for an environment variable for people who want to turn the crazy back on. Ian. -- Ian JacksonThese opinions are

Re: Potentially insecure Perl scripts

Ian Jackson writes ("Re: Potentially insecure Perl scripts"): > Vincent Lefevre writes ("Potentially insecure Perl scripts"): > > I've just reported > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920269 > > against gropdf (also repor

Re: Potentially insecure Perl scripts

t iwj $ This is completely mad and IMO the bug is in perl, not in all of the millions of perl scripts that used <> thinking it was a sensible thing to write. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: Conflict over /usr/bin/dune

lso opposite to Debian policy. Under the circumstances I felt I wouldn't be listened to if I simply petitioned the maintainers of what is now src:dune again, so I have escalated this to the TC. See #919951. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvz

Re: quilt + dpkg + debhelper: Handling upstream files containing spaces

Mike Gabriel writes ("Re: quilt + dpkg + debhelper: Handling upstream files containing spaces"): > On Mi 09 Jan 2019 16:13:57 CET, Ian Jackson wrote: > > I do have an idea how to fix this: a source package format > > `3.0 (rsync)', which could represent any

Re: quilt + dpkg + debhelper: Handling upstream files containing spaces

n idea how to fix this: a source package format `3.0 (rsync)', which could represent any delta. But that project is stalled at a conceptual stage, mostly due to the need to support existing ftpmaster workflow :-/. Regards, Ian. -- Ian JacksonThese opinions are my own. If I emailed you fro

Accepted dgit 8.3 (all source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 07 Jan 2019 00:14:05 + Source: dgit Binary: dgit git-debrebase dgit-infrastructure Architecture: all source Version: 8.3 Distribution: unstable Urgency: medium Maintainer: Ian Jackson Changed-By: Ian Jackson Closes

Accepted vm 8.2.0b-5 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 06 Jan 2019 22:13:10 + Source: vm Binary: vm Architecture: source Version: 8.2.0b-5 Distribution: unstable Urgency: medium Maintainer: Ian Jackson Changed-By: Ian Jackson Description: vm - mail user agent

Re: Unicode License Additional Coverage

copyright.html#License. > > Among other files, that directory contains IVD_Sequences.txt, which > emacs (among other packages) uses. The license ambiguity for that > file had been a concern for someone. Thanks for your work on chasing this up. Ian. -- Ian JacksonThese opinions

Re: Nix and non-standard-toplevel-dir

n for this, > since it's a single edge case. Instead, I think it's a good use of a > Lintian override documenting what's going on. Obviously, if Nix becomes > really popular in the long run, we can then go back and write this into > Policy. This is a good approach. Ian. -- Ian Jacks

Re: Policy and procedures issue: init package hijacked via hostile NMU (declined by maintainers)

was about the process anyway. My inclination is to trust Dmitry's judgement about when to take steps such as those described here. Thanks, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes REJECTED

Mo Zhou writes ("Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes REJECTED"): > We (Julia maintainers) reached an agreement to revert the name of NEW > binary package "libjulia1" back to "libjulia0.7", and upload the ugly > package to unstable after a week or ten days, in order to bypass the NEW

Re: Conflict over /usr/bin/dune

Ian Jackson writes ("Re: Conflict over /usr/bin/dune"): > https://www.google.com/search?q=dune+software > https://en.wikipedia.org/wiki/Dune_(software) > https://www.google.com/search?q=%2Fusr%2Fbin%2Fdune > > Under the circumstances it seems obvious that, at the very

Re: Conflict over /usr/bin/dune

oftware) https://www.google.com/search?q=%2Fusr%2Fbin%2Fdune Under the circumstances it seems obvious that, at the very least, the ocaml build tool should not be allowed the name /usr/bin/dune. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evad

Re: Conflict over /usr/bin/dune

couldn't be bothered to do a Debian file search, https://www.google.com/search?q=dune+software https://en.wikipedia.org/wiki/Dune_(software) https://www.google.com/search?q=%2Fusr%2Fbin%2Fdune Under the circumstances it seems obvious that no-one should be allowed the name /usr/bin/dune. Ian. --

Re: Tainted builds (was Re: usrmerge -- plan B?)

capture some additional data of this kind, because someone will pop up and say `my build system is like this and it is fine' or whatever. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: Tainted builds (was Re: usrmerge -- plan B?)

:) And how to define "proper". This is being discussed in more detail in debian-policy (thread on #824495). I like your /usr/local taints. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: wicd-daemon-run_1.0_amd64.changes REJECTED

e it, but we should avoid that approach where we can. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Accepted vm 8.2.0b-4 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 28 Nov 2018 23:47:06 + Source: vm Binary: vm Architecture: source Version: 8.2.0b-4 Distribution: unstable Urgency: medium Maintainer: Ian Jackson Changed-By: Ian Jackson Description: vm - mail user agent

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

it will be most convenient to file a separate bug for that. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#914898: debootstrap, stretch-backports: Please disabled merged /usr by default

f I am wrong.) -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Accepted elogind 239.1+20181112+gd4a3f291e395+nosubmodule-1+debian1 (amd64 source) into unstable, unstable

Maintainer: Debian Ecosystem Init Diversity Team Changed-By: Ian Jackson Description: elogind- user, seat and session management daemon libelogind-dev - user, seat and session management library (development files) libelogind0 - user, seat and session management library libpam-elogind

Re: usrmerge -- plan B?

and executed transition to mandatory merged-/usr might well have offered overall technical benefits for the Debian ecosystem, this is not now socially possible and pressing on is not worth the social costs of being seen to bulldoze opposition. Ian. -- Ian JacksonThese opinions are my own. If

Re: usrmerge -- plan B?

Russ Allbery writes ("Re: usrmerge -- plan B?"): > Ian Jackson writes: > > We can then have this discussion again early in the bullseye release > > cycle. If we must. > > That idea makes me wince. This will just result in the same thing > happening again. Let

Re: usrmerge -- plan B?

fixed ? I think this is just outsourcing the pain of bad design choices, frankly. If we must get to merged-usr on all systems eventually, Adam's proposed transition plan is much better. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net

Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes REJECTED

ation. This seems like a good reason to me to override the lintian warning. In any case, please can we have the package ACCEPTed and bugs filed so that we can discuss this in the BTS ? Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)

rom a merged-usr build are not of general applicability and should be used only in a closed environment where all the target systems are also merged-usr. Does that make sense ? Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: usrmerge -- plan B?

Russ Allbery writes ("Re: usrmerge -- plan B?"): > This is a much better summary of the thread, and I wish that you would > have said this instead of claiming incorrectly that those same people are > the ones advocating for a full merge of all systems. Marco d'Itri writes ("Re: usrmerge -- plan

Re: usrmerge -- plan B?

Russ Allbery writes ("Re: usrmerge -- plan B?"): > Ian Jackson writes: > >> "We ran into some unanticipated issues when we usrmerged our build > >> systems, and we think the way to fix that is to force merge every one > >> of our users' syste

Do not contact this person IRL either (Re: I resigned in 2004)

necessary but it seems wise to write it.) Excuse the shouting, but, really. It is very unfortunate that I am having to explain these rather basic principles. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address

Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

Chris Lamb writes ("Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)"): > Ian Jackson wrote: > >[..] Compared to REJECT mails: > > - Discussions in the BTS are more transparent > > - Discussions in the BTS are better organised > &

Re: usrmerge -- plan B?

Marco d'Itri writes ("Re: usrmerge -- plan B?"): > On Nov 22, Ian Jackson wrote: > > Marco d'Itri writes ("Re: usrmerge -- plan B?"): > > > So far nobody reported anything significant. > > > > I hear there was a major free software project

Re: usrmerge -- plan B?

Marco d'Itri writes ("Re: usrmerge -- plan B?"): > So far nobody reported anything significant. I hear there was a major free software project who accidentally usrmerged their build systems and discovered that they then built broken packgaes. Ian. -- Ian JacksonThese opinio

Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

Holger Levsen writes ("Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)"): > On Thu, Nov 22, 2018 at 12:52:48PM +, Ian Jackson wrote: > > Because: > > ... > > thanks! nice summary. I replied in my other mail to the things I disagreed with (as

Re: usrmerge -- plan B?

ers' systems." That does seem to be the position that is being advanced. It's quite striking, isn't it ? At the very least more comprehensive thought and planning is needed. And very probably more time. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an

Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

grounds that it should be in experimental rather than unstable. Unless it's an overrideable auto-REJECT of course. As I say, I'm a fan of those. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

Holger Levsen writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"): > On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote: > > Why is any of this a reason for an ftpmaster REJECT ? I still think > > all of this should be handled as bugs (possibly RC bugs) in the BT

Re: usrmerge -- plan B?

Andreas Henriksson writes ("Re: usrmerge -- plan B?"): > Here's a dumbed down narrative for you: Svante's message was pretty bad but yours is even worse. Would everyone please stop it. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an addre

Re: usrmerge -- plan B?

have a transition plan which we can discuss and possibly get rough consensus on. Personally what I have seen so far gives me little confidence. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Re: julia_1.0.0-1_amd64.changes REJECTED

Emilio Pozuelo Monfort writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"): > > On 2018/10/25 12:24, Ian Jackson wrote: > >> Ian Jackson writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"): > >>> My main concern here is this: AFAICT this package has b

Re: usrmerge -- plan B?

Marco d'Itri writes ("Re: usrmerge -- plan B?"): > On Nov 20, Adam Borowski wrote: > > Another question is, why? > > It has been documented here long ago: https://wiki.debian.org/UsrMerge . I looked at that page and it has no rationale. > You are misconstructing the arguments in favour of

Accepted chiark-utils 6.0.3 (source) into unstable

Jackson Changed-By: Ian Jackson Description: chiark-backup - backup system for small systems and networks chiark-really - really - a tool for gaining privilege (simple, realistic sudo) chiark-rwbuffer - readbuffer/writebuffer: prevents tape drive seesawing, etc. chiark-scripts - chiark system

Re: Requesting input for pjproject/asterisk packaging

Marc Haber writes ("Re: Requesting input for pjproject/asterisk packaging"): > b. The multi tarball feature of dpkg-source would be helpful for a > number of other packages, it's about time that someone seriously uses > it. I have been using it for Xen in stretch-security and it all WFM. The

<    1   2   3   4   5   6   7   8   9   10   >