Package: wnpp
Severity: wishlist
Owner: Adam Borowski
* Package name: pmdk-convert
Version : 1.5.1
Upstream Author : Intel
* URL : https://github.com/pmem/pmdk-convert
* License : BSD-3
Programming Lang: C, C++
Description : convert pmdk/pmemobj pools t
On Tue, Feb 19, 2019 at 11:52:49PM +0100, W. Martin Borgert wrote:
> On 2019-02-19 22:55, Chris Lamb wrote:
> > (Naturally, downloading them during the build would not be
> > acceptable, but I wonder what the consensus would be on the ethics
> > of downloading "contrib"-like data during autopkgtest
On Wed, Feb 20, 2019 at 12:06:30AM +0100, Chris Lamb wrote:
> Noted, but it is not the size that is the concern, but rather the
> licensing.
once those (licencing concerns) are resolved, I wonder whether it makes
sense to provide a fate-testdata package which then other packages can
build-depend o
On 2019-02-20 00:06, Chris Lamb wrote:
> Noted, but it is not the size that is the concern, but rather the
> licensing.
Sure! If this cannot be clarified, I'll try to either find
similar files with a suitable licsense, or even produce them
myself. Like with the "(Ma)Lena, the cat" photo :-)
W. Martin Borgert wrote:
> > Naturally, downloading them during the build would not be
> > acceptable, but I wonder what the consensus would be on the ethics
> > of downloading "contrib"-like data during autopkgtests?
>
> It's also a practical matter: Can I run autopkgtests, when my
> computer is
On 2019-02-19 22:55, Chris Lamb wrote:
> Dumb question: have you tried consulting upstream?
Not yet. If this question has been clarified inside Debian
before, I'm reluctant pestering upstream again. I know, that
some upstreams get shirty about our insistence on such matters.
But if not, I'll conta
W. Martin Borgert wrote:
> I can easily add the small number of needed files to debian/fate-
> suite/, but I'm not even sure about the license of the files.
Dumb question: have you tried consulting upstream? Getting a
definitive statement from them on the licensing of these files
would probably b
Hi,
a package I'm working on makes use of eight files from the FATE
project for unit testing. The files are multimedia files (image,
audio, video, subtitles). By default it downloads files during
build, but it's easy to just provide them locally. So far, I
could not find any FATE files in Debian.
Package: general
Severity: important
"Hewlet"Hewlett Packard Pavilion g6 2239-sr reffered as "laptop" later
t Packard Pavilion g6 2239-sr reffered as "laptop" later
Dear Maintainer,
"Hewlett Packard Pavilion g6 2239-sr reffered as "laptop" later
after clean Debian stable install (with Xfce DE, bu
Package: wnpp
Severity: wishlist
Owner: suman rajan
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-vasync
Version : 2.2.0
Upstream Author : Caolan McMahon
* URL : https://github.com/davepacheco/node-vasync
* License : Expat
Programming Lang:
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: kma
Version : 1.1.7
Upstream Author : , Philip Clausen, Technical University of Denmark
* URL : https://bitbucket.org/genomicepidemiology/kma
* License : Apache-2.0
Programming Lang: C
De
Package: wnpp
Severity: wishlist
Owner: Sylvestre Ledru
* Package name: lscolors
* URL : https://github.com/sharkdp/lscolors
* License : Apache 2 or MIT
Description : Colorize paths using the LS_COLORS environment variable
It was in fd-find, it moved as a new packag
> Hi Thomas,
>> Dear Andreas,
>>
>> Thanks for taking care of toulbar2. I did spend some time to try to go
>> around this #920459 bug but even a postprocessing of the LaTeX output of
>> doxygen (removing inclusion of the xcolor package that generates the
>> LaTeX compilation issue) did not work (an
Sorry, missed the Reply-All as Andreas pointed out. See attached mail.
Thomas
--- Begin Message ---
Hi Thomas,
On Tue, Feb 19, 2019 at 11:15:13AM +0100, Thomas Schiex wrote:
> Dear Andreas,
>
> Thanks for taking care of toulbar2. I did spend some time to try to go
> around this #920459 bug bu
On Tue, Feb 19, 2019 at 11:13:29AM +0100, Andreas Tille wrote:
> On Tue, Feb 19, 2019 at 09:07:24AM +0100, Ondřej Surý wrote:
> > I believe that it was the case before that if the autoremoval was due a
> > specific RC bug, any activity on that specific bug would reset the timer
> > for autoremova
On Tue, Feb 19, 2019 at 09:07:24AM +0100, Ondřej Surý wrote:
> I believe that it was the case before that if the autoremoval was due a
> specific RC bug, any activity on that specific bug would reset the timer for
> autoremoval.
I've thought the same but despite the activity it is not reset (at
Processing commands for cont...@bugs.debian.org:
> package general firmware-iwlwifi
Limiting to bugs with field 'package' containing at least one of 'general',
'firmware-iwlwifi'
Limit currently set to 'package':'general', 'firmware-iwlwifi'
> reassign 922665 firmware-iwlwifi
Bug #922665 [genera
Processing commands for cont...@bugs.debian.org:
> forcemerge 815037 922665
Bug #815037 [firmware-iwlwifi] "Microcode SW error detected. Restarting ..."
every few seconds
Unable to merge bugs because:
package of #922665 is 'general' not 'firmware-iwlwifi'
Failed to forcibly merge 815037: Did not
Guillem Jover writes:
> 3) Switching packages to the merged-/usr layout could have been
>accomplished automatically via debhelper for a coverage of around
>99% (?) of the archive. With something along the lines of:
>
> ,---
> D=debian/tmp
> for d in /bin /sbin /lib; do
>
Hi,
I believe that it was the case before that if the autoremoval was due a
specific RC bug, any activity on that specific bug would reset the timer for
autoremoval.
But it might have changed since… or my memory is failing me.
Cheers,
Ondrej
> On 19 Feb 2019, at 08:46, Andreas Tille wrote:
>
20 matches
Mail list logo
