On Thu, 2024-09-19 at 16:51 +0100, Phil Wyett wrote:
> Control: tags -1 +moreinfo
>
> Philippe,
>
> Preamble...
>
> Thank you for taking the time to prepare this package and your contribution
> to the Debian project.
>
> The review below is for assistance. This review is offered to help package
Control: tags -1 +moreinfo
Philippe,
Preamble...
Thank you for taking the time to prepare this package and your contribution
to the Debian project.
The review below is for assistance. This review is offered to help package
submitters to Debian mentors inorder to improve their packages prior to
: 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
Control: tags -1 +confirmed
EiPiFun,
Preamble...
Thank you for taking the time to prepare this package and your contribution
to the Debian project.
The review below is for assistance. This review is offered to help package
submitters to Debian mentors inorder to improve their packages prior to
Foundation maintained libraries. - Python 3.x
Actually this is a dependency of python package gymnasium and stable-
baselines3,
which are important libraries for deep reinforcement learning and I use
them daily.
Deep reinforcement learning is an important tech powered many important
things
like AlphaGo,
Control: tags -1 +confirmed
Havard,
Preamble...
Thank you for taking the time to prepare this package and your contribution
to the Debian project.
The review below is for assistance. This review is offered to help package
submitters to Debian mentors inorder to improve their packages prior to
p
On 24.08.2024 11:32, Phil Wyett wrote:
> Hi Havard,
>
> One still not spaced. I will look again after this one is corrected.
>
> Files: compat/dev_to_tty.c
> Copyright: 1998-2002 by Albert Cahalan
> License:LGPL-2.1+
Done
>
> Regards
>
> Phil
>
Hi Havard,
One still not spaced. I will look again after this one is corrected.
Files: compat/dev_to_tty.c
Copyright: 1998-2002 by Albert Cahalan
License:LGPL-2.1+
Regards
Phil
--
"I play the game for the game’s own sake"
Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans
--
Control: tags -1 -moreinfo
On 24.08.2024 09:18, Phil Wyett wrote:
> Control: tags -1 +moreinfo
>
> Havard,
>
> Preamble...
>
> Thank you for taking the time to prepare this package and your contribution
> to the Debian project.
>
> The review below is for assistance. This review is offered to
Control: tags -1 +moreinfo
Havard,
Preamble...
Thank you for taking the time to prepare this package and your contribution
to the Debian project.
The review below is for assistance. This review is offered to help package
submitters to Debian mentors inorder to improve their packages prior to
po
Control: tags -1 -moreinfo
On 23.08.2024 20:09, Phil Wyett wrote:
> Control: tags -1 +moreinfo
>
> Havard,
>
> Preamble...
>
> Thank you for taking the time to prepare this package and your contribution
> to the Debian project.
>
> The review below is for assistance. This review is offered to
Control: tags -1 +moreinfo
Havard,
Preamble...
Thank you for taking the time to prepare this package and your contribution
to the Debian project.
The review below is for assistance. This review is offered to help package
submitters to Debian mentors inorder to improve their packages prior to
po
n-scap.org/
* License : LGPL-2.1+ and expat, LGPL-3.0+, W3C, LGPL-2.1+, expat,
BSD-3-clause, GPL-2+, LGPL-2.0+
* Vcs : https://salsa.debian.org/debian/openscap
Section : admin
The source builds the following binary packages:
libopenscap-dev - libraries enabling inte
: 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 for
: 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'
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 : https://gitee.com/op
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: unstab
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 for
* 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 to
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 generate
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 files
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 ins
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 u
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 installin
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 s
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 pro
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 heavi
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" sound
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 conc
> Debian 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 link
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 must
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.
Regards
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 schrieb
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 b
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 plugins?
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 co
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
Mechtild
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
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' f
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 plu
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 top-le
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, icons,
* 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 information
* 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 paths
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 dh_
r fgrep... /usr/bin/grep -F
checking for non-GNU ld... /bin/ld
checking if the linker (/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking the maximum length of command line arguments..
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 th
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 descipt
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 shows
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
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 adverti
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 not work
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
differe
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?pkg=ca
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 c
Your message dated Fri, 09 Mar 2018 10:20:19 +
with message-id
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-1 [ITP] -- IBM Data Engine for NoSQL Software
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 L
e, how would 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. These
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 i
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 update appe
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 they
1 - 100 of 731 matches
Mail list logo
