: Apache-2.0, BSD-3-clause
* Vcs : https://salsa.debian.org/debian/shaderc
Section : libs
The source builds the following binary packages:
glslc - Command line compiler for GLSL/HLSL to SPIR-V
libshaderc-dev - Library API for accessing glslc functionality -
static
Your message dated Sun, 17 Mar 2024 10:26:48 +0100
with message-id
and subject line Re: Bug#1065442: RFS: shaderc/2023.8-1 [RC] -- Library API for
accessing glslc functionality - shared libraries
has caused the Debian Bug report #1065442,
regarding RFS: shaderc/2023.8-1 [RC] -- Library API
: https://salsa.debian.org/debian/shaderc
>Section : libs
>
> The source builds the following binary packages:
>
> glslc - Command line compiler for GLSL/HLSL to SPIR-V
> libshaderc-dev - Library API for accessing glslc functionality -
> static libraries and h
y -
static libraries and headers
libshaderc1 - Library API for accessing glslc functionality - shared
libraries
To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/shaderc/
Alternatively, you can download the package with 'dget' using th
Your message dated Mon, 11 Dec 2023 11:47:30 + (UTC)
with message-id <556064559.4024519.1702295250...@mail.yahoo.com>
and subject line Re: Bug#1057919: RFS: bglibs/2.04+dfsg-4 [ITA] -- This package
contains a collection of libraries (documentation)
has caused the Debian Bug report #1
: LGPL-2+, LGPL-2.1+, GPL-2+
* Vcs : https://salsa.debian.org/debian/bglibs
Section : devel
The source builds the following binary packages:
libbg2 - This package contains a collection of libraries (libraries)
libbg-dev - This package contains a collection of
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: liudun@qq.com
Dear mentors,
I am looking for a sponsor for my package "ukui-interface":
* Package name : ukui-interface
Version : 4.0.0.0-1
Upstream contact : liuhao
* URL :
On Thu, Sep 7, 2023 at 2:00 PM liudun wrote:
>
> Package: sponsorship-requests
> Severity: wishlist
> X-Debbugs-Cc: liudun@qq.com
>
> Version:4.0.0.0-1 (View RFS template)
> Uploaded: 2023-09-07 05:52
> Source package: ukui-interface_4.0.0.0-1.dsc
> Distribution:
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: liudun@qq.com
Version:4.0.0.0-1 (View RFS template)
Uploaded: 2023-09-07 05:52
Source package: ukui-interface_4.0.0.0-1.dsc
Distribution: unstable
Section:libs
Priority: optional
Homepage:
Your message dated Mon, 21 Aug 2023 10:58:27 +0200
with message-id <89e39153-3fe7-42e2-ae51-1ce8b6fae...@debian.org>
and subject line Re: RFS: ffcall/2.4-2.1 [NMU] -- foreign function call
libraries - closures in C (non-reentrant variant)
has caused the Debian Bug report #1050092,
regardi
ction call libraries - development files
libffcall1b - foreign function call libraries - main shared library
libavcall1 - foreign function call libraries - calling C functions with
variable arguments
libcallback1 - foreign function call libraries - closures with variable
arguments in C
libt
* License : Apache-2.0, Apache-2.0 or LGPL-3+
* Vcs : https://salsa.debian.org/java-team/jnr-ffi
Section : java
The source builds the following binary packages:
libjnr-ffi-java - Java library for loading native libraries without writing
JNI code
libjnr-ff
Your message dated Sun, 9 Oct 2022 20:21:12 +0200
with message-id
and subject line Re: Bug#1021501: RFS: shaderc/2022.2-1 [ITP] -- Library API
for accessing glslc functionality - shared libraries
has caused the Debian Bug report #1021501,
regarding RFS: shaderc/2022.2-1 [ITP] -- Library API
* License : Apache-2.0, BSD-3-clause
* Vcs : https://salsa.debian.org/debian/shaderc
Section : libs
The source builds the following binary packages:
glslc - Command line compiler for GLSL/HLSL to SPIR-V
libshaderc-dev - Library API for accessing glslc functionality -
static
Your message dated Sat, 1 Oct 2022 14:15:48 +0200
with message-id
and subject line Re: Bug#1021051: RFS: bats-support/0.3.0-1 [ITP] -- Supporting
library to test bats helper libraries
has caused the Debian Bug report #1021051,
regarding RFS: bats-support/0.3.0-1 [ITP] -- Supporting library
1.0
* Vcs : https://salsa.debian.org/bats-team/bats-support
Section : libdevel
The source builds the following binary packages:
bats-support - Supporting library to test bats helper libraries
To access further information about this package, please visit the
following URL:
Your message dated Fri, 22 Jul 2022 21:53:08 +0200
with message-id <948f3e44-179d-9ff6-64b1-1e6031cb3...@debian.org>
and subject line Re: RFS: openscap/1.3.6+dfsg-1 -- libraries enabling
integration of the SCAP line of standards
has caused the Debian Bug report #1015750,
regarding RFS: op
Control: retritle -1 RFS: xapp/2.2.6-1 [RC] -- Libraries and common
resources for multiple desktop environments
Did a small improvements and new upload to mentors:
xapp (2.2.6-1) experimental; urgency=medium
.
[ Joshua Peisach ]
* Add dh-sequence-gir to build deps
* Bump Standards
On 7/6/21 9:38 pm, jrb3-beckenbach.us wrote:
Hi again, Jon!
On 6 Jun 2021, at 20:51, Jon Gough wrote:
These suggest that a full cleanup could/should(?) be done including all user
generated files.
Not at all, because packages do not install any files to any user-$HOME.
If the user
Hi again, Jon!
> On 6 Jun 2021, at 20:51, Jon Gough wrote:
> These suggest that a full cleanup could/should(?) be done including all user
> generated files.
Not at all, because packages do not install any files to any user-$HOME.
If the user generated (or triggered the generation of) any
On 5/6/21 5:36 pm, Andrey Rahmatullin wrote:
On Sat, Jun 05, 2021 at 07:43:54AM +1000, Jon Gough wrote:
On 9/5/21 5:40 pm, Andrey Rahmatullin wrote:
On Sun, May 09, 2021 at 04:41:13PM +1000, Jon Gough wrote:
My conclusion is that application plugin mangers should make use of the
platform
On Sat, Jun 05, 2021 at 09:03:05AM +1000, Jon Gough wrote:
> On 5/6/21 7:59 am, The Wanderer wrote:
> > And what if the user is uninstalling, but intends to install again
> They get asked if they want to do a complete uninstall of all downloaded
> plugins, or leave them
What happens to the other
On Sat, Jun 05, 2021 at 07:43:54AM +1000, Jon Gough wrote:
>
> On 9/5/21 5:40 pm, Andrey Rahmatullin wrote:
> > On Sun, May 09, 2021 at 04:41:13PM +1000, Jon Gough wrote:
> > > My conclusion is that application plugin mangers should make use of the
> > > platform installation process for
On 5/6/21 8:36 am, Sven Hartge wrote:
The Wanderer wrote:
I genuinely do not see what insisting on uninstalling plugins at the
same time as the main program, for all user accounts, provides as a
benefit. The only maybe benefit I've seen suggested is cleaning up to
free disk space, and that
On 5/6/21 7:59 am, The Wanderer wrote:
On 2021-06-04 at 17:43, Jon Gough wrote:
On 9/5/21 5:40 pm, Andrey Rahmatullin wrote:
On Sun, May 09, 2021 at 04:41:13PM +1000, Jon Gough wrote:
I now know what path I need to follow, i.e. have a plugin manager
that uses the platform installation
The Wanderer wrote:
> I genuinely do not see what insisting on uninstalling plugins at the
> same time as the main program, for all user accounts, provides as a
> benefit. The only maybe benefit I've seen suggested is cleaning up to
> free disk space, and that seems to me to be so obviously
On 2021-06-04 at 17:43, Jon Gough wrote:
> On 9/5/21 5:40 pm, Andrey Rahmatullin wrote:
>
>> On Sun, May 09, 2021 at 04:41:13PM +1000, Jon Gough wrote:
>>> I now know what path I need to follow, i.e. have a plugin manager
>>> that uses the platform installation process so that the uninstall
>>>
On 9/5/21 5:40 pm, Andrey Rahmatullin wrote:
On Sun, May 09, 2021 at 04:41:13PM +1000, Jon Gough wrote:
My conclusion is that application plugin mangers should make use of the
platform installation process for installing and uninstalling plugins as it
"the platform installation process"
Am Sun, May 09, 2021 at 04:41:13PM +1000 schrieb Jon Gough:
>
>
> On 9/5/21 4:31 pm, Mechtilde wrote:
> > Hello Jon,
> >
> > which plugin manager are you talking about.
> >
> > Each application providing plugins has its own mechanism to handle them.
> >
> > So i don't understand what your
bian policy is the reference, and §9 refers to the FHS with
> > execptions. This is probably what you need to read to answer your
> > question, if I got you right.
> >
>
> The debian policy manual also mentions plug-ins in section 10.2.
Only about specifics of linking plugin
On Sun, May 09, 2021 at 04:41:13PM +1000, Jon Gough wrote:
> My conclusion is that application plugin mangers should make use of the
> platform installation process for installing and uninstalling plugins as it
"the platform installation process" sounds like using debs, am I wrong?
> would appear
On Fri, 7 May 2021, 08:35 Tobias Frost, wrote:
> On Fri, May 07, 2021 at 10:58:27AM +1000, Jon Gough wrote:
> > The user install plugins can vary between very simple with a config file
> and
> > a couple of icons up to complex with large data >1GB and hundreds of
> icons.
> >
> > So, if debs
On 9/5/21 4:31 pm, Mechtilde wrote:
Hello Jon,
which plugin manager are you talking about.
Each application providing plugins has its own mechanism to handle them.
So i don't understand what your conclusion is. So I want to know whether
my packages can be affected or benefit of it.
Hello Jon,
which plugin manager are you talking about.
Each application providing plugins has its own mechanism to handle them.
So i don't understand what your conclusion is. So I want to know whether
my packages can be affected or benefit of it.
Regards
Mechtilde
Am 08.05.21 um 23:50
On 8/5/21 10:51 pm, Sven Hartge wrote:
Jon Gough wrote:
So, any user installable application extension/plugin which has
executables and supporting data is left behind on the system when the
owning application is removed or updated using the system installation
process? This is accepted
Jon Gough wrote:
> So, any user installable application extension/plugin which has
> executables and supporting data is left behind on the system when the
> owning application is removed or updated using the system installation
> process? This is accepted behaviour?
Yes, this is accepted
On 2021-05-07 at 16:47, Jon Gough wrote:
> On 8/5/21 12:17 am, Kris Deugau wrote:
>
>> Jon Gough wrote:
>>> Is there a process that allows the deb to 'clean up' the
>>> application when the application is uninstalled, in particular
>>> any 'install' artefacts that have been installed by
Hi Jon,
On Fri, May 7, 2021 at 10:47 PM Jon Gough wrote:
> On 8/5/21 12:17 am, Kris Deugau wrote:
>
> Jon Gough wrote:
>
> The user install plugins can vary between very simple with a config file
> and a couple of icons up to complex with large data >1GB and hundreds of
> icons.
>
> So, if debs
On 8/5/21 12:17 am, Kris Deugau wrote:
Jon Gough wrote:
The user install plugins can vary between very simple with a config
file and a couple of icons up to complex with large data >1GB and
hundreds of icons.
So, if debs must not touch files in $HOME but is allowed to create
files there (is
The user install plugins can vary between very simple with a config file
and a couple of icons up to complex with large data >1GB and hundreds
of icons. So leaving them lying around on smaller, resource constrained
systems when the main application is removed does not seem very user
friendly.
Jon Gough wrote:
The user install plugins can vary between very simple with a config file
and a couple of icons up to complex with large data >1GB and hundreds of
icons.
So, if debs must not touch files in $HOME but is allowed to create files
there (is that not a contradiction?) where else
Hello Jon,
do you have a special plugin in mind.
I packaged several plugins for thunderbird and libreoffice.
They all are installed as root under /usr/lib and/or /usr/share. Some of
them has also config files.
So I offer we can work step-by-step to the packaging process.
Kind regards
On Fri, May 07, 2021 at 10:58:27AM +1000, Jon Gough wrote:
> The user install plugins can vary between very simple with a config file and
> a couple of icons up to complex with large data >1GB and hundreds of icons.
>
> So, if debs must not touch files in $HOME but is allowed to create files
>
The user install plugins can vary between very simple with a config file
and a couple of icons up to complex with large data >1GB and hundreds of
icons.
So, if debs must not touch files in $HOME but is allowed to create files
there (is that not a contradiction?) where else could the 'system'
On Thu, May 06, 2021 at 01:16:13PM +1000, Jon Gough wrote:a
(Please refrain from top-posting)
> Hi,
> Thanks for the info, I thought this may be the case. Using that it is
> easy to install and uninstall plugins from the main program. The uninstall
> can be just the plugin resources or the
Hi,
Thanks for the info, I thought this may be the case. Using that it
is easy to install and uninstall plugins from the main program. The
uninstall can be just the plugin resources or the plugin resources and
configuration items as well and we can ask the user what level of
uninstall they
Hi Jon,
Maybe it would be preferable to use the XDG recommendation ?
App configuration, and plugins configuration too:
XDG_CONFIG_HOME:-$HOME/.config/[MyTLD]/[MyApplication]/
User installed plugins resources:
XDG_DATA_HOME:-$HOME/.local/share/[MyTLD]/[MyApplication]/
*where MyTLD is a
Hi List,
I am working on a user driven plugin management process for an
application which is installed via a 'deb' file. The application is
installed using 'root' privileges, but the plugins need to be
installable by the user without root privileges. The plugins will
consist of libs,
* License : LGPL-2
* Vcs : https://salsa.debian.org/ondracek/simlib
Section : libs
It builds those binary packages:
libsimlib3 - SIMulation LIBrary for C++ - shared libraries
libsimlib-dev - SIMulation LIBrary for C++ - development files
To access further informa
* License : Apache-2
* Vcs : https://salsa.debian.org/python-team/packages/python-absl
Section : python
It builds those binary packages:
python3-absl - Abseil Python Common Libraries
To access further information about this package, please visit the following
URL
* License : GPL-2+
* Vcs :
http://anonscm.debian.org/gitweb/?p=debian-science/packages/hmat-oss.git
Section : science
It builds those binary packages:
libhmat-oss1 - dynamic libraries for HMat
libhmat-oss-dev - headers and development libraries for HMat
libhma
Your message dated Mon, 27 Apr 2020 21:35:22 -0400
with message-id <8729f96418e6b5728844b1e94ec43c001b2a2069.ca...@debian.org>
and subject line Re: RFS: openscap/1.2.17-0.1 [NMU, RC] -- Set of libraries
enabling integration of the SCAP line of standards
has caused the Debian Bug report #
* License : [fill in]
* Vcs : None
Section : libs
It builds those binary packages:
libopenscap-dev - Set of libraries enabling integration of the SCAP
line of standards
libopenscap8 - Set of libraries enabling integration of the SCAP line
of standards
python
L-1
* Vcs : https://salsa.debian.org/science-team/coinutils
Section : science
It builds those binary packages:
coinor-libcoinutils3v5 - Coin-or collection of utility classes
(binaries and libraries)
coinor-libcoinutils-dev - Coin-or collection of utility classes
(developer files
Hi Adam,
On Sun, Jan 26, 2020 at 01:39:00AM +0100, Adam Borowski wrote:
> On Sat, Jan 25, 2020 at 11:53:02PM +, Sudip Mukherjee wrote:
> > * Package name: coinor-vol
> >Version : 1.5.4-3
>
> > Changes since the last upload:
> >
> >* QA upload.
> >* Fix relative
On Sun, Jan 26, 2020 at 12:39 AM Adam Borowski wrote:
>
> On Sat, Jan 25, 2020 at 11:53:02PM +, Sudip Mukherjee wrote:
> > * Package name: coinor-vol
> >Version : 1.5.4-3
>
> > Changes since the last upload:
> >
> >* QA upload.
> >* Fix relative paths.
> >* Use
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu
format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format...
func_convert_file_noop
checking for /bin/ld option to reload object files... -r
checking for objdump... objdu
or.org/Vol
* License : EPL-1
* Vcs : https://salsa.debian.org/debian/coinor-vol
Section : science
It builds those binary packages:
coinor-libvol1 - Coin-or linear programming solver (libraries)
coinor-libvol-dev - Coin-or linear programming solver (development files
On Sun, Jan 19, 2020 at 9:42 PM Sudip Mukherjee
wrote:
>
> Hi Adam,
>
> On Sun, Jan 19, 2020 at 8:32 PM Adam Borowski wrote:
> >
> > On Sun, Jan 19, 2020 at 08:00:28PM +, Sudip Mukherjee wrote:
> > > * Package name: coinor-vol
> > >Version : 1.5.4-2
> >
> > > Changes since
Hi Adam,
On Sun, Jan 19, 2020 at 8:32 PM Adam Borowski wrote:
>
> On Sun, Jan 19, 2020 at 08:00:28PM +, Sudip Mukherjee wrote:
> > * Package name: coinor-vol
> >Version : 1.5.4-2
>
> > Changes since the last upload:
> >
> >* QA upload.
> >* make separate short
On Sun, Jan 19, 2020 at 08:00:28PM +, Sudip Mukherjee wrote:
> * Package name: coinor-vol
>Version : 1.5.4-2
> Changes since the last upload:
>
>* QA upload.
>* make separate short desciption.
>* Upload source. (Closes: #949299)
Hi!
The debdiff from 1.5.4-1
or.org/Vol
* License : EPL-1
* Vcs : https://salsa.debian.org/debian/coinor-vol
Section : science
It builds those binary packages:
coinor-libvol1 - Coin-or linear programming solver (libraries)
coinor-libvol-dev - Coin-or linear programming solver (development files
Your message dated Sat, 28 Dec 2019 21:28:10 +0100
with message-id <20191228202810.ga15...@angband.pl>
and subject line Re: Bug#947598: RFS: libcommoncpp2/1.8.1-8 [QA] [RC] -- Header
files and static libraries for Common C++ "2"
has caused the Debian Bug report #94759
g/software/commoncpp/
* License : GPL-2
* Vcs : https://salsa.debian.org/pkg-voip-team/libcommoncpp2
Section : devel
It builds those binary packages:
libcommoncpp2-dev - Header files and static libraries for Common C++
2
libccgnu2-1.8-0v5 - GNU package fo
rg/science-team/coinutils
Section : science
It builds those binary packages:
coinor-libcoinutils3v5 - Coin-or collection of utility classes (binaries
and libraries)
coinor-libcoinutils-dev - Coin-or collection of utility classes
(developer files)
coinor-libcoinutils-doc - Coin-or collection
On Fri, Dec 06, 2019 at 06:24:49PM +0100, Alf Gaida wrote:
> Am 06.12.2019 um 17:37 schrieb Ole Streicher:
> > How should one handle this?
> >
> > Best regards
> >
> > Ole
> >
> Arch dependend symbols are a pain in the ... :D
However, it can be helpful to detect ABI changes that are not
Andrey Rahmatullin writes:
> On Fri, Dec 06, 2019 at 05:37:25PM +0100, Ole Streicher wrote:
>> for the "casacore" package (written in C++), we wanted to introduce
>> symbols files for the shared libraries it produces. However, this
>> somehow does n
Am 06.12.2019 um 17:37 schrieb Ole Streicher:
How should one handle this?
Best regards
Ole
Arch dependend symbols are a pain in the ... :D
there are some approaches to handle it - one could have a look into the
KDE packaging tools and packaging how the KDE team handle this. I use a
On Fri, Dec 06, 2019 at 05:37:25PM +0100, Ole Streicher wrote:
> Hi,
>
> for the "casacore" package (written in C++), we wanted to introduce
> symbols files for the shared libraries it produces. However, this
> somehow does not work, as they seem to depend on the ar
Hi,
for the "casacore" package (written in C++), we wanted to introduce
symbols files for the shared libraries it produces. However, this
somehow does not work, as they seem to depend on the architecture and/or
the C++ compiler version:
https://buildd.debian.org/status/logs.php?pk
Paul Wise wrote:
> Hmmm, what about something that looks at the headers?
This is possible in theory although it looks complex, fragile and
insufficient to me. It would help library maintainers to detect API
breaks and subsequently ABI breaks (at least one source for them), but
I can't see how it
On Mon, Mar 12, 2018 at 4:20 PM, Yavor Doganov wrote:
> Because of the dynamic nature of the language this information is not
> available at build time.
Hmmm, what about something that looks at the headers?
--
bye,
pabs
https://wiki.debian.org/PaulWise
Paul Wise wrote:
> On Mon, Mar 12, 2018 at 2:02 AM, Yavor Doganov wrote:
> > If -initWithAddressBook:readOnly: is removed in a new version of the
> > library, that's an API/ABI break but again, it won't be reflected in
> > the symbols table. In a C/C++ library you'll see a symbol
> > disappearing
On Mon, Mar 12, 2018 at 2:02 AM, Yavor Doganov wrote:
> If -initWithAddressBook:readOnly: is removed in a new version of the
> library, that's an API/ABI break but again, it won't be reflected in
> the symbols table. In a C/C++ library you'll see a symbol
> disappearing but it won't happen here.
Adam Borowski wrote:
> On Tue, Mar 06, 2018 at 08:28:17AM +0200, Yavor Doganov wrote:
> > * Package name: addresses-for-gnustep
> >Version : 0.4.8-3
> I don't understand ObjC library stuff well enough to adequately
> check these parts, but it's unlikely we'd get someone else who
Your message dated Fri, 09 Mar 2018 10:20:19 +
with message-id <e1euf8n-0005o2...@quantz.debian.org>
and subject line closing RFS: cxlflash/4.3.2580-1 [ITP] -- IBM Data Engine for
NoSQL Software Libraries
has caused the Debian Bug report #870909,
regarding RFS: cxlflash/4.3.2580-
Mentors,
I am picking up work on this package. I'm working through the issues
already outlined to make sure they are resolved and all questions are
answered.
Once that is done, I'll refresh the package if necessary, and inform of
the updates and answered questions.
Thanks.
Barry Arndt
IBM
ld I
> do the versioning?
Package them separately and file ITP bugs for each.
I can see these libraries being useful for other projects too.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Hi,
I would like to work on packaging the Tilde text editor (RFP #692512). (Full
disclosure: I am the author of said software.)
To package Tilde, I would also need to package the separately distributed
support libraries, which each have their own version numbering and release
schedule
Hi,
We've made a new upload. Please, consider this .dsc ->
https://mentors.debian.net/debian/pool/main/c/cxlflash/cxlflash_4.3.2560-1.dsc
Thanks,
Rodrigo R. Galvao
Hi,
The latest version of this package fix the issues pointed in the
previous comment, as well as other points made in mentors.debian.
Here is the link to the .dsc ->
https://mentors.debian.net/debian/pool/main/c/cxlflash/cxlflash_4.3.2554-1.dsc
Thanks,
Rodrigo R. Galvao
Control: tags -1 - moreinfo
src/build/install/resources/{cap,ptd}.gz are prebuilt binaries too.
If you remove them too, and are sure there is no other such things, you
may change the package bacn to main from non-free.
cxlffdc won't work on Debian properly, I suspect there are other things
like
On Mon, Aug 28, 2017 at 06:50:49PM +, Michael P Vageline wrote:
> The firmware and prebuilt binaries are covered under the
>click-to-accept license.
So it's not permitted for Debian to distribute them?
--
WBR, wRAR
signature.asc
Description: PGP signature
On Mon, Aug 28, 2017 at 05:03:02PM +, Michael P Vageline wrote:
> 1. cxlflash depends upon libudev1 and libcxl1 for their runtime shared
> libraries
${shlibs:Depends} already covers that and does the job better.
> 2. The include files were modified, so no copyright updat
Hi,
This upload has the changes pointed by Michael in the previous message
->
https://mentors.debian.net/debian/pool/non-free/c/cxlflash/cxlflash_4.3.2533-1.dsc
Thanks,
Rodrigo R. Galvao
hi,
The next RFS update has these chgs:
1. cxlflash depends upon libudev1 and libcxl1 for their runtime shared libraries
2. The include files were modified, so no copyright update appears to be
required
3. the code is changed to use dh_systemd
4. the license files are moved back to /usr/share
Why does cxlflash explicitly depend on libudev1, libcxl1?
debian/copyright is still not updated.
Why do the maintainer scripts use deb-systemd-helper directly and how does
that work with code aded by dh_systemd_*?
I think the licenses shouldn't be in /usr/share/doc but in
/usr/share/pkgname as
Hi Andrey,
> > There are a lot of errors in the install_root_man1 target.
> > There are warnings about unused ${perl:Depends}.
>
>
> We've made changes that should fix these errors. Could you check it,
> please? ->
>
Hi Andrey,
> There are a lot of errors in the install_root_man1 target.
> There are warnings about unused ${perl:Depends}.
We've made changes that should fix these errors. Could you check it,
please? ->
https://mentors.debian.net/debian/pool/non-free/c/cxlflash/cxlflash_4.3.2528-1.dsc
On Thu, Aug 24, 2017 at 10:19:29AM -0300, Rodrigo wrote:
> >> I was able to build from the link I sent to you using 'debuild -us -uc'.
> >> Could you share with us what's the error, please?
> > cflash_block_kern_mc.c:59:10: fatal error: scsi/cxlflash_ioctl.h: No such
> file or directory
>
> We
Hi Andrey,
>> I was able to build from the link I sent to you using 'debuild -us -uc'.
>> Could you share with us what's the error, please?
> cflash_block_kern_mc.c:59:10: fatal error: scsi/cxlflash_ioctl.h: No
such file or directory
We made some changes that fix this build problem. Here is
On Wed, Aug 23, 2017 at 07:23:33PM +, Michael P Vageline wrote:
> Your build error is from missing this file:
> > dpkg -S /usr/include/scsi/cxlflash_ioctl.h
> linux-libc-dev: /usr/include/scsi/cxlflash_ioctl.h
>
> Are you building using a kernel that is shipped with 17.10?
17.10 of what? Your
hi,
Your build error is from missing this file:
> dpkg -S /usr/include/scsi/cxlflash_ioctl.h
linux-libc-dev: /usr/include/scsi/cxlflash_ioctl.h
Are you building using a kernel that is shipped with 17.10?
> Why do both packages depend on some -dev packages?
> *fixed
Why does cxlflash depend
On Wed, Aug 23, 2017 at 03:56:59PM -0300, Rodrigo wrote:
> I was able to build from the link I sent to you using 'debuild -us -uc'.
> Could you share with us what's the error, please?
cflash_block_kern_mc.c:59:10: fatal error: scsi/cxlflash_ioctl.h: No such file
or directory
Besides, you should
Hi,
> I don't really see any changes and also you haven't answered many of
my questions.
> Also, the package doesn't build. Please don't upload packages you haven't
> tested.
I was able to build from the link I sent to you using 'debuild -us -uc'.
Could you share with us what's the error,
On Wed, Aug 23, 2017 at 06:36:21PM +, Michael P Vageline wrote:
> Why do both packages depend on some -dev packages?
> *fixed
Why does cxlflash depend on some -dev packages then?
--
WBR, wRAR
signature.asc
Description: PGP signature
hi,
These are all fixed in the latest... once you get the correct updates.
I: cxlflash: package-contains-empty-directory usr/share/man/man3/
*fixed
I: cxlflash: unused-override hardening-no-fortify-functions
*fixed
/usr/share/cxlflash/readme.txt and maybe some other files should be
hi,
>Do I understand correctly that postinst touches /opt? Including /opt/bin?
>I'm not sure that's a good idea even if that's only for migration (and
>it's definitely a bad idea if anything in /opt is created on a clean
>system).
>As the maintainer script logic is very
On Wed, Aug 23, 2017 at 02:54:18PM -0300, Rodrigo wrote:
> We've made some changes and uploaded it again, here is the link ->
> https://mentors.debian.net/debian/pool/main/c/cxlflash/cxlflash_4.3.2520-1.dsc
I don't really see any changes and also you haven't answered many of my
questions.
Also,
Hi Andrey,
We've made some changes and uploaded it again, here is the link ->
https://mentors.debian.net/debian/pool/main/c/cxlflash/cxlflash_4.3.2520-1.dsc
About the "non-free", how does it work? I mean, we have to change some
file in specific? (i.e. debian/control)
Thanks,
Rodrigo R.
1 - 100 of 676 matches
Mail list logo
