Bug#891005: RFS: gdbm/1.14.1-5

[KAction]

[2018-02-28 10:21] Ansgar Burchardt 
> Gianfranco Costamagna writes:
> > I think there is nothing to worry about :)
> >
> > this is the path:
> > /usr/lib/*/diet/*/libgdbm.a
> 
> It is a problem as the package might provide different functionality
> when someone else builds and uploads it.

Well, should I introduce whole binary package with just one single
gdbm.a instead?

Bug#891005: RFS: gdbm/1.14.1-5

[Ansgar Burchardt]

Gianfranco Costamagna writes:
>>This means building the package will give different results depending
>>on dietlibc-dev installed or not?  That shouldn't happen...
>>
>>Please check via some other means that a build using dietlibc has been
>>requested; don't do different things just because a package happens to
>>be installed.
> mmm the result is not a different library, but an additional static library 
> put
> in a non-standard directory, built with another glibc.
> I think there is nothing to worry about :)
>
> this is the path:
> /usr/lib/*/diet/*/libgdbm.a

It is a problem as the package might provide different functionality
when someone else builds and uploads it.

We had problems with packages built in non-clean environments for a long
time, though it has admittedly become better with most (not all)
developers building packages in clean environments (sbuild, pbuilder,
...) or using source-only uploads.

Ansgar

Bug#891005: RFS: gdbm/1.14.1-5

[Gianfranco Costamagna]

Hello Ansgar


>This means building the package will give different results depending
>on dietlibc-dev installed or not?  That shouldn't happen...
>
>Please check via some other means that a build using dietlibc has been
>requested; don't do different things just because a package happens to
>be installed.
mmm the result is not a different library, but an additional static library put
in a non-standard directory, built with another glibc.
I think there is nothing to worry about :)

this is the path:
/usr/lib/*/diet/*/libgdbm.a


G.

Bug#891005: RFS: gdbm/1.14.1-5

[Ansgar Burchardt]

On Tue, 2018-02-27 at 13:58 +0300, kact...@gnu.org wrote:
> Anyhow, if you want to enable, you can do something like this, to
> make
> > me and you happy, and then easily revert when new bugs are opened
> 
>  
>   HAVE_DIETLIBC=no 
>   ifeq ($(shell dpkg -s dietlibc-dev | grep -o installed), installed)
>   DIET_LIBDIR := $(shell diet -L gcc)
>   HAVE_DIETLIBC=yes 
>   endif
>   
>   ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
>   HAVE_DIETLIBC=no 
>   endif

This means building the package will give different results depending
on dietlibc-dev installed or not?  That shouldn't happen...

Please check via some other means that a build using dietlibc has been
requested; don't do different things just because a package happens to
be installed.

Ansgar

Bug#891005: RFS: gdbm/1.14.1-5

[KAction]

Hello.

> Anyhow, if you want to enable, you can do something like this, to make
> me and you happy, and then easily revert when new bugs are opened
 
HAVE_DIETLIBC=no 
ifeq ($(shell dpkg -s dietlibc-dev | grep -o installed), installed)
DIET_LIBDIR := $(shell diet -L gcc)
HAVE_DIETLIBC=yes 
endif

ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
HAVE_DIETLIBC=no 
endif

Thanks, I will add this snippet.

> If you want to enable it, please make sure it works :)

Okay. I will add some autopkgtests.

Bug#891005: RFS: gdbm/1.14.1-5

[Gianfranco Costamagna]

Hello 



>With all my respect, I am very relucant to solve problems of Ubuntu at
>expense of Debian output. What exactly is wrong, Debian-wise, in package
>we are discussing, apart the need to specify long list of architectures,
>so I could fix it?


this is not an "Ubuntu" problem, but something that even Debian
had (remember, 4 bugs opened in less than a week).
So I would say, I'm reluctant in re-enabling something that did cause a lot
of troubles to Debian folks :)

Anyhow, if you want to enable, you can do something like this, to make me and 
you
happy, and then easily revert when new bugs are opened

HAVE_DIETLIBC=no
ifeq ($(shell dpkg -s dietlibc-dev | grep -o installed), installed)
DIET_LIBDIR := $(shell diet -L gcc)
HAVE_DIETLIBC=yes
endif

ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
HAVE_DIETLIBC=no
endif


>Short answer: >  because you need it to link program, using gdbm, with diet 
>libc,
>  resulting small static executable.
>Full answer: 
>  because I believe Debian should provide not only libraries for
>  build-dependencies of something in /bin, but also libraries for
>  developers to develop with.
>
>  I did some search, and seems this is already happening. We have a lot
>  of leaf libraries (mostly perl and java), for example: 
>- libxmlenc-java 
>- libwx-scintilla-perl

>

I can understand the reasons for having it, but the question is:
does it work?
How can I run some simple make commands to see if everything works?
because people on the bug reports tried and they said it wasn't working.

If you want to enable it, please make sure it works :)

>Or maybe we just need Guix/Nix?


I don't get this :)



cheers!

G.

Bug#891005: RFS: gdbm/1.14.1-5

[KAction]

[2018-02-21 17:02] Gianfranco Costamagna 
> >!Important! This upload re-enables diet libc support {conditional, via
> >build profiles}. Input from developers, experienced with Debian
> >bootstrap is very, very welcome.
> 
> Since this is causing troubles in Ubuntu (Matthias, please give your opinion 
> here),
> because dietlibc is in main, and gives also troubles to maintain the list of 
> dietlibc
> architectures where it is available, since it causes troubles using dietlibc
> (the build seems failing), I would prefer to actually implement it again once 
> dietlibc folks
> makes the whole stuff *working*.
> 
> [... description of problems in Ubuntu ...]

With all my respect, I am very relucant to solve problems of Ubuntu at
expense of Debian output. What exactly is wrong, Debian-wise, in package
we are discussing, apart the need to specify long list of architectures,
so I could fix it?

> I would prefer a patch from dietlibc folks, with an use case of *why*
> they need this static library, rather than building/including
> something that caused 4 bugs in Debian, a lot of pain in Ubuntu (and
> probably was even broken).
>
> What is your opinion? I would like to understand why we need this, and
> if this had even worked.

You ask good question. 

Short answer: 
  because you need it to link program, using gdbm, with diet libc,
  resulting small static executable.

Full answer: 
  because I believe Debian should provide not only libraries for
  build-dependencies of something in /bin, but also libraries for
  developers to develop with.

  I did some search, and seems this is already happening. We have a lot
  of leaf libraries (mostly perl and java), for example: 
- libxmlenc-java 
- libwx-scintilla-perl

Or maybe we just need Guix/Nix?

> The other stuff looks good to me :)

That is good news.

Bug#891005: RFS: gdbm/1.14.1-5

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hello!
>!Important! This upload re-enables diet libc support {conditional, via
>build profiles}. Input from developers, experienced with Debian
>bootstrap is very, very welcome.


Since this is causing troubles in Ubuntu (Matthias, please give your opinion 
here),
because dietlibc is in main, and gives also troubles to maintain the list of 
dietlibc
architectures where it is available, since it causes troubles using dietlibc
(the build seems failing), I would prefer to actually implement it again once 
dietlibc folks
makes the whole stuff *working*.

Right now the approach is not usable, and makes things harder for Ubuntu and 
Debian.
(e.g. in Ubuntu we should conditionalize and remove it, with something like
if dpkg-vendor --derives-from Ubuntu; then

HAVE_DIETLIBC=nofi

but even in that case, the pulling of build-dependencies from universe will 
cause mismatches in the
archive.

I would prefer a patch from dietlibc folks, with an use case of *why* they need 
this static library,
rather than building/including something that caused 4 bugs in Debian, a lot of 
pain in Ubuntu
(and probably was even broken).

The other stuff looks good to me :)

What is your opinion? I would like to understand why we need this, and if this 
had even worked.

G.

Bug#891005: RFS: gdbm/1.14.1-5

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

!Important! This upload re-enables diet libc support {conditional, via
build profiles}. Input from developers, experienced with Debian
bootstrap is very, very welcome.

Dear mentors,

I am looking for a sponsor for my package "gdbm"

* Package name : gdbm
  Version  : 1.14.1-5
  Upstream Author  : bug-g...@gnu.org
* Url  : https://gnu.org/software/gdbm
* Licenses : GPL-3+,GFDL-1.3+
  Programming Lang : C
  Section  : libs

 GNU dbm ('gdbm') is a library of database functions that use extendible
 hashing and works similarly to the standard UNIX 'dbm' functions.
 .
 The basic use of 'gdbm' is to store key/data pairs in a data file, thus
 providing a persistent version of the 'dictionary' Abstract Data Type
 ('hash' to perl programmers).

It builds those binary packages:

  * libgdbm5
  * gdbm-l10n
  * libgdbm-dev
  * gdbmtool
  * libgdbm-compat4
  * libgdbm-compat-dev

This package succesfully builds on debomatic machine:

  https://debomatic-i386.debian.net/distribution#unstable/gdbm/1.14.1-5
 
Please note, that package is maintained with dgit(1) tool
using dgit-maint-merge(7) workflow. For more information about how to
sponsor this package, see dgit-sponsorship(7).

  Git repository: https://salsa.debian.org/iu-guest/gdbm.git
  Git branch: master

With /bin/sh following commands should suffice:

  $ git clone https://salsa.debian.org/iu-guest/gdbm.git gdbm
  $ cd gdbm
  $ make -f debian/rules get-orig-source # 'gbp buildpackage' is fine
  $ dgit sbuild

Changes since last upload:

  * Update Vcs-* fields in debian/control.
  * Bump compat version to 11 (no changes needed)
  * Enable dietlibc build, unless pkg.gdbm.nodietlibc profile is in effect.
  * Change section of bin:gdbm-l10n to 'localization'
  * Fix spelling error on manpage
  * Enable large file support

Regards,
  Dmitry Bogatov