Hi,
On 2019-05-21 23:52, Paul Wise wrote:
> Has anyone repeated the training of Mozilla DeepSpeech for example?
By chance I found a paper from a pile of papers (that attacks AI models)
that Berkeley researchers have successfully attacked DeepSpeech:
https://arxiv.org/pdf/1801.01944.pdf
IHMO
On Wed, May 29, 2019 at 8:46 PM Raphaël Halimi wrote:
> What would be the "cleanest" solution according to you ?
The cleanest solution would be to get this code into Linux mainline.
Some discussion of workarounds:
dak needs a way to restrict the availability of arch:all packages to
certain arch
On Wed, May 29, 2019 at 5:36 PM Mo Zhou wrote:
> For example, many years ago I proposed that we could hire some
> web developers to rewrite our homepage, to make it more good-looking
> (Generally I don't care about superficial stuff but our homepage
> is really old enough. Look at Gentoo's homepag
Ian Jackson writes:
> Can you please look through the table below and see if I have covered
> everything you do ?
You have covered the workflows I set up where I have the choice. Thanks.
--
\ “I am amazed, O Wall, that you have not collapsed and fallen, |
`\since you must
Le 29/05/2019 à 15:41, Ondřej Surý a écrit :
> can’t you just “skip” building the module in DKMS when on unsupported
> architecture?
>
> Install the package on that system would be noop then.
Well, I was so focused on trying to make the package unavailable on
non-ACPI architectures that I didn't
Package: wnpp
Severity: wishlist
Owner: Steffen Moeller
* Package name: wham
* URL : http://www.cs.wisc.edu/wham/
* License : GPL
Programming Lang: C
Description : Wisconsin's High-Throughput Alignment Method
To be team-maintained on salsa.debian.org/med-team/wham
Ian Jackson writes:
> Ian Jackson writes ("Re: Survey: git packaging practices / repository
> format"):
>> David Bremner writes ("Re: Survey: git packaging practices / repository
>> format"):
> ...
>> > With unmodified upstream files in the main branch, plus debian/*, but
>> > usually no d/patc
Ian Jackson writes:
> Hi. Thanks for your contributions which I am trying to capture, but I
> don't think I fully understand them.
>
> David Bremner writes ("Re: Survey: git packaging practices / repository
> format"):
>> With modified upstream files in the main branch, plus debian/*, but
>> us
Ian Jackson writes ("Re: Survey: git packaging practices / repository format"):
> David Bremner writes ("Re: Survey: git packaging practices / repository
> format"):
...
> > With unmodified upstream files in the main branch, plus debian/*, but
> > usually no d/patches, I use git-debcherry to gener
Hi. Thanks for your contributions which I am trying to capture, but I
don't think I fully understand them.
David Bremner writes ("Re: Survey: git packaging practices / repository
format"):
> With modified upstream files in the main branch, plus debian/*, but
> usually no d/patches I use a sepera
On Wed, May 29, 2019 at 12:20:23PM -0400, Sam Hartman 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.
> Andrey> This conflicts with shipping tarball signatures.
>
> "Andrey" == Andrey Rahmatullin writes:
Andrey> On Wed, May 29, 2019 at 02:14:09PM +0100, Ben Hutchings wrote:
>> [...] > My understanding is that this unusual difference between
>> the .orig > tarball and what's in git is an attempt to "square
>> the circle" between > two c
On Wed, May 29, 2019 at 02:14:09PM +0100, Ben Hutchings wrote:
> [...]
> > My understanding is that this unusual difference between the .orig
> > tarball and what's in git is an attempt to "square the circle" between
> > two colliding design principles: "the .orig tarball should be upstream's
> > o
On Wed, 29 May 2019 at 14:14:09 +0100, Ben Hutchings wrote:
> On Wed, 2019-05-29 at 00:39 +0100, Simon McVittie wrote:
> [...]
> > My understanding is that this unusual difference between the .orig
> > tarball and what's in git is an attempt to "square the circle" between
> > two colliding design p
> "Sam" == Sam Hartman writes:
ke the Software Freedom Conservancy (SFC)'s
Sam> position
Sam> https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/-UUU:**--F1
Sam> *unsent wide reply to Aron Xu* Bot L50 (Message SC:f MML Abbre
Ah, that's an interesting artifact of how cut&pas
Hi,
With my Debian ZoL maintainer hat + FTP trainee hat on, I didn't wish
to jump into this topic too early without a in-depth investigation...
On 2019-05-29 14:14, Sam Hartman wrote:
> And if you take the Software Freedom Conservancy (SFC)'s position
> https://sfconservancy.org/blog/2016/feb/25/
I hope that we do not choose to open the zfs discussion at this time.
If it does get opened, I think my approach would be to try and educate
the community about the various different viewpoints, find text for GRs
that would allow key stakeholders to believe their positions were
respected and c
On Wed, 2019-05-29 at 13:43 +0200, Dan wrote:
> Hi Jonathan,
>
> On Tue, May 28, 2019 at 8:50 PM Jonathan Carter wrote:
> > On 2019/05/28 18:43, Dan wrote:
> > > ZFS 0.8 has been released with lots of improvements, notably encryption.
> >
> > Yep, it's an exciting feature.
> >
> > > Sadly the L
On Wed, May 29, 2019 at 8:55 PM Ian Jackson
wrote:
>
> Ansgar writes ("Re: ZFS in Buster"):
> > Ian Jackson writes:
> > > I think this would be both unwise legally (without seeking additional
> > > legal advice) and rather rude to the kernel upstream whose code is
> > > then being reused without p
> On 29 May 2019, at 14:45, Raphaël Halimi wrote:
>
> Hi,
>
> I'm the maintainer of package acpi-call, which is a kernel module
> allowing a user to call ACPI methods. Its build is handled by DKMS.
>
> The module used to build on all architectures, even if it was obviously
> useless on those
On Wed, 2019-05-29 at 00:39 +0100, Simon McVittie wrote:
[...]
> My understanding is that this unusual difference between the .orig
> tarball and what's in git is an attempt to "square the circle" between
> two colliding design principles: "the .orig tarball should be upstream's
> official binary a
On Tue, 2019-05-28 at 21:14 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Re: Survey: git packaging practices / repository
> format"):
[...]
> > Debian Linux kernel
> > ===
> >
> > Tree contains: an incomplete debian/ directory, notably without d/control,
> > and no upstream
Package: wnpp
Severity: wishlist
Owner: Steffen Moeller
* Package name: python-geneimpacts
* URL : https://github.com/brentp/geneimpacts
* License : MIT/X
Programming Lang: Python
Description : wraps tools to assess variants in gene sequences
To be team-maintained
Ansgar writes ("Re: ZFS in Buster"):
> Ian Jackson writes:
> > I think this would be both unwise legally (without seeking additional
> > legal advice) and rather rude to the kernel upstream whose code is
> > then being reused without permission - indeed, contrary to their
> > explicitly stated inte
> "Ian" == Ian Jackson writes:
Ian> Enrico Weigelt, metux IT consult writes ("Re: Survey: git
Ian> packaging practices / repository format"):
>> I'd call it the 'git-only-workflow' ;-)
Ian> ...
>> It's not in official Debian. I've announced it long go, but
>> nobody he
Hi,
I'm the maintainer of package acpi-call, which is a kernel module
allowing a user to call ACPI methods. Its build is handled by DKMS.
The module used to build on all architectures, even if it was obviously
useless on those which don't support ACPI.
Starting with Linux 5.2, what used to be a
Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices /
repository format"):
> On 28.05.19 22:08, Ian Jackson wrote:
> > Please can we leave aside discussion of the merits or otherwise of
> > each of these formats/workflows.
> >
> > Perhaps we can talk about that (again!)
Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices /
repository format"):
> I'd call it the 'git-only-workflow' ;-)
...
> It's not in official Debian. I've announced it long go, but nobody
> here really cared. I couldn't even convice debian maintainers for
> little less
[moving a discussion from -devel to -project where it belongs]
> "Mo" == Mo Zhou writes:
Mo> Hi,
Mo> On 2019-05-29 08:38, Raphael Hertzog wrote:
>> Use the $300,000 on our bank accounts?
So, there were two $300k donations in the last year.
One of these was earmarked for a DSA
Hi Jonathan,
On Tue, May 28, 2019 at 8:50 PM Jonathan Carter wrote:
> On 2019/05/28 18:43, Dan wrote:
> > ZFS 0.8 has been released with lots of improvements, notably encryption.
>
> Yep, it's an exciting feature.
>
> > Sadly the Linux Kernel has introduced a commit in kernel 4.19 and 5.0
> > tha
Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices /
repository format"):
> hmm, sounds quite complicated ... anyone here who could explain why
> exactly they're doing it that way ?
>
> by the way: that's IMHO an important information we should also collect:
> why exact
On 28.05.19 18:43, Dan wrote:
> Sadly the Linux Kernel has introduced a commit in kernel 4.19 and 5.0> that
> prevents ZFS from using SIMD. The result is that ZFS won't be>
usable in Buster. See the following issue>
https://github.com/zfsonlinux/zfs/issues/8793
We recently had this discussion on
Ian Jackson writes:
>
> Main packaging Delta from upstream Tools for manipulating
> git branch represented as delta from upstream,
> contains building .dsc, etc.
>
> Unmodified debian/patches gbp, gbp pq
> ups
On 28.05.19 19:31, Simon McVittie wrote:
Hi,
> Debian Linux kernel
> ===
>
> Tree contains: an incomplete debian/ directory, notably without d/control,
> and no upstream source
> Changes to upstream source are: d/patches only
> Baseline upstream: changelog version => .orig tarbal
On 29.05.19 01:39, Simon McVittie wrote:
Hi,
> You might reasonably assume that, but no, they are not. mesa (and probably
> other xorg-team packages) uses v1.0 dpkg-source format combined with
> dh --with quilt, so deliberate Debian changes can be either direct
> changes to the upstream source co
Hi,
On 2019-05-29 08:38, Raphael Hertzog wrote:
> Use the $300,000 on our bank accounts?
I totally support the idea that we should find more valuable usage
of our fund. For example, if developers don't have enough time or
don't want to do something difficult, we could hire somebody else
to fix th
On 28.05.19 22:08, Ian Jackson wrote:
Hi,
> Please can we leave aside discussion of the merits or otherwise of
> each of these formats/workflows.
>
> Perhaps we can talk about that (again!) at some point, but it tends to
> derail any conversation about git packaging stuff and I don't want
> this
On 28.05.19 22:30, Ian Jackson wrote:
> Hi, thanks for replying. You have an interesting workflow which I
> think I need to ask some questions about before I can document it
> fully.
I'd call it the 'git-only-workflow' ;-)
The main reasons behind are:
* i wanna be able to easily rebase onto upst
On Wed, 29 May 2019, Ansgar wrote:
> On Wed, 2019-05-29 at 10:38 +0200, Raphael Hertzog wrote:
> > On Wed, 29 May 2019, Andrey Rahmatullin wrote:
> > > One of the popular answers to this and some other problems is "nobody sat
> > > down and wrote the code". Not sure what can we do about this class
On Wed, 2019-05-29 at 10:38 +0200, Raphael Hertzog wrote:
> On Wed, 29 May 2019, Andrey Rahmatullin wrote:
> > One of the popular answers to this and some other problems is "nobody sat
> > down and wrote the code". Not sure what can we do about this class of
> > reasons.
>
> Use the $300,000 on ou
Hi,
On Wed, 29 May 2019, Andrey Rahmatullin wrote:
> One of the popular answers to this and some other problems is "nobody sat
> down and wrote the code". Not sure what can we do about this class of
> reasons.
Use the $300,000 on our bank accounts?
https://lists.debian.org/debian-news/2019/msg00
41 matches
Mail list logo
