On 01/07/2019 18:10, Enrico Weigelt, metux IT consult wrote:
On 19.06.19 09:09, Rebecca N. Palmer wrote:
I proposed [0] fixing this by creating a metapackage for "all OpenCL
drivers" (similar to the ones for graphics). However, having unusable
OpenCL drivers installed can trigger bugs: [1] i
> "Enrico" == Enrico Weigelt, metux IT consult writes:
Enrico> On 01.07.19 21:06, Enrico Weigelt, metux IT consult wrote:
Enrico> Hi,
>> IIRC the whole things is actually about crypto stuff. Why don't
>> zfs> folks just use the standard linux crypto api (potentially
>> in
On 01.07.19 21:06, Enrico Weigelt, metux IT consult wrote:
Hi,
> IIRC the whole things is actually about crypto stuff. Why don't zfs> folks
> just use the standard linux crypto api (potentially introduce a>
new algo if the existing ones aren't sufficient) ?
Addendum: just had a quick scan throug
On 07.06.19 10:16, Philipp Kern wrote:
Hi,
> This would not be the case here. But crippling the performance would be>
> indeed an option, even though this would make Debian much less
relevant> for ZFS deployments and people would just go and use Ubuntu
instead.
Is it really necessary to to have
On 19.06.19 09:09, Rebecca N. Palmer wrote:
Hi,
> I proposed [0] fixing this by creating a metapackage for "all OpenCL
> drivers" (similar to the ones for graphics). However, having unusable
> OpenCL drivers installed can trigger bugs: [1] in llvm, and some
> applications that treat "no hardware
On 15.06.19 11:20, Helmut Grohne wrote:
Hi,
> Unlike the ${dist}-proposed variant, the scratch distribution can be set> up
> entirely outside Debian. It only needs someone doing the work with
no> involvement of DSA. Wait, this reminds me of something. Luca
Falavigna> put up debomatic-${arch}.deb
On 01.07.19 15:09, Andrey Rahmatullin wrote:
> On Mon, Jul 01, 2019 at 03:04:26PM +0200, Enrico Weigelt, metux IT consult
> wrote:
>> On 29.05.19 17:41, Andrey Rahmatullin wrote:
>>
Perhaps we should update policy to say that the .orig tarball may (or
even "should") be generated from an
On 28.06.19 23:42, Ian Jackson wrote:
>https://wiki.debian.org/GitPackagingSurvey
>
> Unfortunately due to bugs in the Debian and Wiki CSS styles, it is
> displayed very suboptimally unless you log into the wiki and set your
> style to "Classic". (I have filed bug reports.)
Very nice work.
Picking just two examples:
Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices /
repository format"):
> I think for each supported upstream version there should be ...
Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices /
repository format"):
On 29.05.19 23:39, David Bremner wrote:
>> Also, how do you move to a new upstream version ?
>
> use git merge, typically from an upstream tag, or from a debian specific
> upstream branch with tarballs imported on top of upstream history.
Uh, that creates an pretty ugly, unreadable git repo and
On Mon, Jul 01, 2019 at 03:04:26PM +0200, Enrico Weigelt, metux IT consult
wrote:
> On 29.05.19 17:41, Andrey Rahmatullin wrote:
>
> >> Perhaps we should update policy to say that the .orig tarball may (or
> >> even "should") be generated from an upstream release tag where
> >> applicable.
> > Th
On 29.05.19 17:41, Andrey Rahmatullin wrote:
>> Perhaps we should update policy to say that the .orig tarball may (or
>> even "should") be generated from an upstream release tag where
>> applicable.
> This conflicts with shipping tarball signatures.
Does that really need to be the upstream's tarb
On 29.05.19 15:14, Ben Hutchings wrote:
> Perhaps we should update policy to say that the .orig tarball may (or
> even "should") be generated from an upstream release tag where
> applicable.
ACK. But there should also be some definition or at least guideline on
what is considiered "applicable" (o
On 02.06.19 16:22, Sam Hartman wrote:
>> "Nikolaus" == Nikolaus Rath writes:
>
>
> Yes, but the lack of similarity is the thing I find interesting.
> In git-pdm (and git-debrebase), you retain all the rebases and stitch
> them together with various pseudo-merges into a combined history.
>
>
On 02.06.19 00:57, Ian Jackson wrote:
Hi,
> The difficulty with this as a collaboration approach is that you can't
> tell whether a rebase is "the newest", at least without a lot of
> additional information. That additional information is the "clutter"
> if you like which the "cleaner" history d
On 29.05.19 14:47, Sam Hartman wrote:
Hi,
> I'm certainly going to look at dck-buildpackage now, because what he
> describes is a workflow I'd like to be using within Debian.
:)
Maybe you'd also find that useful: https://github.com/metux/deb-pkg
It's a little tool for automatically creating wh
Simon McVittie writes ("Re: Survey results: git packaging practices /
repository format"):
> The precise names of the branches are not immediately relevant to
> GitPackagingSurvey: it's the content of those branches that matters.
Thanks for this mail which I think will be very helpful.
> From ht
Ian Jackson writes ("Re: Survey results: git packaging practices / repository
format"):
> What it doesn't say is how changes to the upstream files are
> represented. Can you explain ?
Also: I had hoped that the table's focus on particularly these
questions:
- representation of changes to upstre
Andreas Tille writes ("Re: Survey results: git packaging practices / repository
format"):
> On Fri, Jun 28, 2019 at 10:42:29PM +0100, Ian Jackson wrote:
> > Thanks to everyone who responded. I (with some help from Sean and
> > some review from Sam) have worked the answers into a wiki page:
> >
>
On 29.05.19 13:50, Ian Jackson wrote:
Hi,
> Oh. I think I have misunderstood. I think you are describing a git
> workflow you use as a *downstream* of Debian, not as a maintainer
> *within* Debian.
Yes, something like that. I'm maintaining additional repos for certain
projects, usually backpor
On Mon, 01 Jul 2019 at 07:30:39 +0200, Andreas Tille wrote:
> I admit I did not joined the dgit discussion - may be that's the reason
> I can not really match the branches that are used in Perl team policy
>
> https://perl-team.pages.debian.net/git.html#repository_layout
>
> (which is used b
21 matches
Mail list logo
