Re: RFS: scram/0.16.2-1

2018-01-16 Thread Olzhas Rakhimov 
On Tue, Jan 16, 2018 at 11:34:01AM +0100, Sébastien Villemot wrote:
> Thanks, looks good.
>
> However you forgot to push the pristine-tar branch, can you please do so?
>

Done.

Olzhas

Re: RFS: scram/0.16.2-1

2018-01-14 Thread Olzhas Rakhimov 
On Sun, Jan 14, 2018 at 09:45:20PM +0100, Sébastien Villemot wrote:
>
> About epochs in general:
>
>  https://www.debian.org/doc/debian-policy/#version
>
> About the current epoch of the g++ package:
>
>  apt show g++

Thanks for guiding.

> You may want to update the Vcs-* fields with the new addresses:
>
> Vcs-Git: https://salsa.debian.org/science-team/scram.git
> Vcs-Browser: https://salsa.debian.org/science-team/scram
>
> The old URL (with anonscm.d.o) still works for the time being, because a
> redirection has been setup, but this is clearly temporary, as has just been
> stressed again, see:
>
> https://salsa.debian.org/salsa/AliothRewriter/commit/a777f2f76aac583e1b8b13f1f486ae8ad166a241
>
> However note that some people in the Debian Science Team do not agree with the
> dropping of the anonscm.d.o hostname and refuse to do the change for the time
> being.

Changed Vcs links to point to Salsa.

> P.S.: Please do not CC me on replies, I am subscribed to the list. See
> https://www.debian.org/MailingLists/#codeofconduct

Ok. 'reply-to-list' feature doesn't seem to exist on gmail.
Time to learn mutt, I guess.

Regards,
Olzhas

Re: RFS: scram/0.16.2-1

2018-01-14 Thread Olzhas Rakhimov 
On Sun, Jan 14, 2018 at 12:28 PM, Sébastien Villemot 
wrote:

>
> Note that your versioned dependency on g++ (>= 7.1) is not working as you
> want
> (it won’t enforce the requirement that you have in mind.
>
> Since g++ has an epoch number (currently 4), what you want is g++ (>=
> 4:7.1).
>

​Thanks. Pushed the epoch. Btw, where can I read about it?

Also, is there anything Salsa related update to d​o?

Olzhas

Re: RFS: scram/0.16.2-1

2018-01-14 Thread Olzhas Rakhimov 
On Sun, Jan 14, 2018 at 11:50 AM, David Bremner  wrote:

>
> If you can't build it on debian unstable, it's not ready for upload yet.
>

​It should build just fine. I have it built on Ubuntu 17.10 and 18.04:
https://launchpad.net/~rakhimov/+archive/ubuntu/scram

It is just that I currently don't have a proper local setup to do gbp
buildpackage.​

Olzhas

RFS: scram/0.16.2-1

2018-01-14 Thread Olzhas Rakhimov 
Hello All,

Is source-only uploads into mentors.debian.net acceptable for review?

scram 0.16.2 is moved to C++17 requiring gcc7, boost 1.61, qt 5.9,
so I am currently on franken-Ubuntu 16.04 with custom ppas to build it.
However, it doesn't build this way with gbp, so I only used debuild -S.

Regards,
Olzhas Rakhimov

Re: RFS: scram/0.16.1-1

2018-01-04 Thread Olzhas Rakhimov 
Thanks Sebastien!

On Thu, Jan 4, 2018 at 1:01 PM, Sébastien Villemot 
wrote:
>
>
> You may also want to fix this lintian message in the next upstream release:
>
> I: scram: spelling-error-in-binary usr/lib/scram/libscram.so algorith
> algorithm
>

​Hmm, I am grepping all around but cannot find 'algorith'.​

Regards,
Olzhas

RFS: scram/0.16.1-1

2018-01-04 Thread Olzhas Rakhimov 
Hi,

This is a bug-fix release of scram package;
there's no notable packaging changes.
I would appreciate your sponsorship.

I updated alioth repo and uploaded on mentors.

​Is there some salsa migration work to do, ​or is it going to be automated?

​Regards,
Olzhas​

Re: RFS: scram/0.16.0-1

2017-11-22 Thread Olzhas Rakhimov 
On Wed, Nov 22, 2017 at 2:34 AM, Sébastien Villemot <sebast...@debian.org>
wrote:

> Dear Olzhas,
>
> On Sat, Nov 18, 2017 at 06:28:12PM -0800, Olzhas Rakhimov wrote:
>
> > I need sponsorship to update the scram package.
> > A notable packaging-related change from the previous release
> > is that libxml++ is dropped in favor of libxml2.
> >
> > The alioth git is updated, and package is uploaded to mentors for review.
>
> I made the upload. I just added a fix for bug #871662.
>

​Thanks Sebastien!
I completely missed that.
How do I get notified about bug reports against my package?

Olzhas​

RFS: scram/0.16.0-1

2017-11-18 Thread Olzhas Rakhimov 
Hello,

I need sponsorship to update the scram package.
A notable packaging-related change from the previous release
is that libxml++ is dropped in favor of libxml2.

The alioth git is updated, and package is uploaded to mentors for review.

Thanks,
Olzhas Rakhimov

RFS: scram/0.15.0-1

2017-08-15 Thread Olzhas Rakhimov 
Hello,

The upstream incorporates patches and feedback
form the previous 0.14.0-1 packaging,
which was an introduction of Qt based GUI and multi-binary packaging.
Other than that, there's no packaging changes.

However, there's a strange issue I noticed since moving to multi-banary
packaging.
The package description is broken or not being picked up by some debian
services:

https://blends.debian.org/science/tasks/engineering
https://screenshots.debian.net/package/scram
https://screenshots.debian.net/package/scram-gui

I'm not sure what the problem is.

I updated the git repo and uploaded to mentors ready to be reviewed.

Thanks,
Olzhas Rakhimov

Re: RFS: scram/0.14.0-1

2017-08-06 Thread Olzhas Rakhimov 
On Sun, Aug 6, 2017 at 2:52 PM, Mattia Rizzolo <mat...@debian.org> wrote:

> On Sun, Aug 06, 2017 at 02:22:29PM -0700, Olzhas Rakhimov wrote:
> > Should be good to go.
>
> Uploaded!
>

​Thanks, Mattia!​

Re: RFS: scram/0.14.0-1

2017-08-06 Thread Olzhas Rakhimov 
On Sun, Aug 6, 2017 at 7:07 AM, Mattia Rizzolo <mat...@debian.org> wrote:

> On Sun, Aug 06, 2017 at 03:18:11AM -0700, Olzhas Rakhimov wrote:
> > It becomes a problem with multi-arch builds (executable with '--help'
> > isn't available).
>
> Right, I keep forgetting it…
>
> > I probably have an older version of dh_install.
>
> Well, that's a quite new thing indeed..
>
> > Is there alternative check for missing files?
>
> It's fine as you did it, you can move from `dh_install --list-missing`
> to `dh_missing --list-missing` with the next debhelper compat bump.
>
> > I looked through the changes but didn't see anything relevant to my
> > current packaging.
> > I'll bump the version.
>
> Cool.
> With all of this, I believe the package can be uploaded as it is.  If
> you are fine as well, I can build and upload :)
>

​Uploaded to mentors with the latest standard.
Should be good to go.

Thanks,
Olzhas Rakhimov

Re: RFS: scram/0.14.0-1

2017-08-06 Thread Olzhas Rakhimov 
On Sun, Aug 6, 2017 at 2:20 AM, Mattia Rizzolo <mat...@debian.org> wrote:

> On Sat, Aug 05, 2017 at 03:16:14PM -0700, Olzhas Rakhimov wrote:
> > Probably, I have to learn how to do uploads to experimental.
>
> it's just about using "experimental" instead of "unstable" in the
> changelog :)
>
> > > * all of this said, why was the manpage removed from the upstream side?
> > >
> > The upstream switched to help2man to generate manpages from help prompts
> > automatically.
>
> ok, then can't it be generated at build time=
>
> ​It becomes a problem with multi-arch builds (executable with '--help'
isn't available).
Indeed, help2man is a bit of work packagers, but it helps the upstream with
keeping only single source of truth
 for its ​

​command-line options.
I couldn't find an alternative easier way.
​

> > Thanks for the review. There’s definitely a lot nitty-gritty stuff to
> > learn for me.
>
> heh, worry not!
>
> So, about your new changes:
> * "dh_install --(fail|list)-missing" are deprecated, as the manpage
>report
>
​I probably have an older version of dh_install.
Is there alternative check for missing files?
​


> * last night a new debian-policy came out.  The website has yet to be
>   updated, but in debian-devel-announce (which I expect you to be
>   subscribed) you can find the relevant announcement with the changes.
>   Please update your package as well for it.
>   https://www.debian.org/doc/debian-policy/ch-controlfields.
> html#s-f-Standards-Version
>
​I looked through the changes but didn't see anything relevant to my
current packaging​.
I'll bump the version.

Thanks,
Olzhas

Re: RFS: scram/0.14.0-1

2017-08-05 Thread Olzhas Rakhimov 
On Sat, Aug 5, 2017 at 5:12 AM, Mattia Rizzolo <mat...@debian.org> wrote:

On Wed, Aug 02, 2017 at 06:51:00AM -0700, Olzhas Rakhimov wrote:
> > I explicitly listed 'to-be-installed' files in scram.install &
> > scram-gui.install. Reuploaded
>
> Very well, so let's get to the rest of the packaging review:  btw, be
> aware that I am looking only at what's in the git repository, I haven't
> even looked at mentors.d.n.
>
> * I see the bash completion moved from
>   /usr/share/bash-completion/completions/scram.sh to
>   /usr/share/bash-completion/completions/scram/scram.sh - I have no
>   knowledge of how bash completions should be handled, does it still
>   work?  (it's due a trailing '/scram' in d/scram.install, remember that
>   dh_install does not behave like cp…)
>
​
This script with shell extension was somehow failing on Ubuntu​.
I wanted to rename and remove the extension.

* is d/p/0001-GUI-Fix-the-static-build.patch still needed after
>   switching to the dynamic lib again?
>
​You are right it is not needed anymore. I removed it.

* is d/p/0001-GUI-Update-.desktop-with-URL-and-Keywords.patch upstreamed
>   or something?
>
​Yes, this is directly from upstream.
​

* The last debian upload was 0.11.5-1, but there are a bunch of other
>   changelog entries: it's not a real problem (I just need to pass the
>   correct -v option to dpkg-buildpackage (dpkg-genchanges actually) when
>   building before upload), but still weird.  Consider that you could
>   have uploaded all of those to experimental instead of keeping them for
>   now :)
> * stadards-version bump is not documented
> * new binary is not documented either
> * same for d/copyright changes
>
​
Probably, I have to learn how to do uploads to experimental.
For now, I will squash the changelogs for the pseudo-published releases.
​

* all of this said, why was the manpage removed from the upstream side?
>
​The upstream switched to help2man to generate manpages from help prompts
automatically.​

* last: why -DBUILD_TESTS=OFF ?
>
​This depends on custom (patched) googletest submodule that I cannot seem
to pull into ​builds.
I need to download the tarball or with git submodule update --init
--recursive with the original repository.
I hope to drop that custom dependency someday and switch to standard
googletest available on debian;
at that time, it should be easier to port the tests as well.


> As you can see nothing major, in my opinion: nice work :)
>
> ​Thanks for the review. There’s definitely a lot nitty-gritty stuff to
learn for me.​

Regards,
Olzhas Rakhimov
​

Re: RFS: scram/0.14.0-1

2017-08-02 Thread Olzhas Rakhimov 
On Wed, Aug 2, 2017 at 6:12 AM, Mattia Rizzolo <mat...@debian.org> wrote:

> On Tue, Aug 01, 2017 at 06:12:36PM -0700, Olzhas Rakhimov wrote:
> > I ended up doing a nasty thing of merging the GUI and command-line into
> one
> > package.
>
> meh.
> don't give up so easily :)
>
> > I really wish there's some debhelper magic for CMake multi-binary builds.
>
> The fact that the package is using cmake is quite irrelevant, really :)
> The difference is on how dh_auto_install(1) works when you are building
> one or mulitple binaries: when you build only one binaries the "make
> install" installs everything in the debian/scram directory, and the
> proceed to create a .deb out of that tree; when you are building
> multiple binaries that "make install" (as invoked by dh_auto_install)
> puts all the files in the debian/tmp directory instead, leaving you the
> job of specifing which files need to go to which directory, usually by
> means of various debian/*.install (see dh_install(1)) files.
>
>
> I believe that was what you were confused about, given that you didn't
> really explain much about what your problems were.
>
> ​Thanks for your patience, Mattia!

I explicitly listed 'to-be-installed' files in scram.install &
scram-gui.install. Reuploaded​

​to mentors and updated alioth.
It seems to work, but I keep my fingers crossed.

Regards,
Olzhas​

Re: RFS: scram/0.14.0-1

2017-08-01 Thread Olzhas Rakhimov 
Hello,

I ended up doing a nasty thing of merging the GUI and command-line into one
package.
It works for now (tested on Ubuntu).
Also, I switched to static builds to free myself from configuring shared
libs.

I really wish there's some debhelper magic for CMake multi-binary builds.

Olzhas
​

Re: RFS: scram/0.14.0-1

2017-08-01 Thread Olzhas Rakhimov 
On Tue, Aug 1, 2017 at 6:10 AM, Mattia Rizzolo <mat...@debian.org> wrote:

> On Tue, Aug 01, 2017 at 03:08:01PM +0200, Mattia Rizzolo wrote:
> > On Mon, Jul 31, 2017 at 09:21:05PM -0700, Olzhas Rakhimov wrote:
> > > There are two major changes since the last packaging:
> > >
> > > 1. The GUI front-end with Qt5
> >
> > So you want this in a separate binary (as you did)?
> >
> > > 2. Shared libraries (core & gui)
> > >(meant to be private and used only by the SCRAM GUI and
> command-line)
> >
> > umh, I wonder whether this should be in a separate binary package as
> > well.
> >
> > > I updated the control file, but not sure it is setup correctly.
> > > There are a couple of lintian warnings (empty binary)
> > > that I am not sure what to do.
> >
> > empty binary packages are a non-uploadable thing, really.
>
> Besides, I haven't tried to build it, but looking at it I suspect
> neither of the 2 binaries contain anything useful at all: have you
> tested what you build, or did you come for help because you can't manage
> to get something working?  (It was not clear from the first email).
>
> > Please read dh_install(1), debhelper(7) and several things: you have
> > files like debian/install and debian/manpages that are mostly confusing
> > in behaviour when you build more than one binary: I recommend you rename
> > those to $pkg.install and $pkg.manpages, and you'll need to add the
> > equivalent for the other binaries you want to build, each listing what
> > you want to install.
>

​I am really confused with multiple-binary setup with CMake.
I split the manpage & install for scram & scram-gui;
the warning of empty binaries are gone, but I think it is still missing the
libraries.​
I guess I have to put these private libraries explicitly in control.
Also, cmake is doing installation of icons and .desktop.
I hope I don't have to mention them explicitly in packaging scripts.

​It would really help me if there were an example project that I can learn
from.

Thanks,
Olzhas Rakhimov​

Re: RFS: scram/0.11.6-1

2017-02-12 Thread Olzhas Rakhimov 
On Sun, Feb 12, 2017 at 6:38 AM, Mattia Rizzolo <mat...@debian.org> wrote:

> On Sun, Feb 12, 2017 at 06:26:09AM -0800, Olzhas Rakhimov wrote:
> > Ok, let's keep it git only. I will delete the upload on mentors.
>
> Ok, please remember to ask again once stretch is out; it's unlikely
> anybody else will :)
>
​Btw, should every upstream release be uploaded?​
In other words, when does it make sense to update the package with the
upstream releases?

Re: RFS: scram/0.11.6-1

2017-02-12 Thread Olzhas Rakhimov 
On Sun, Feb 12, 2017 at 5:56 AM, Mattia Rizzolo <mat...@debian.org> wrote:

> [ahem, top posting…]
>
> On Sun, Feb 12, 2017 at 05:50:22AM -0800, Olzhas Rakhimov wrote:
> > I think the fixed bugs are not critical to pull the package out of
> testing
> > or unblock it.
>
> Ok, Then your options are:
>
> * upload this update to experimental, move it to unstable once stretch
>   is released
> * keep it in git only, upload to unstable once stretch is released
>
> I'll let you pick your preference :)
>
> ​Ok, let's keep it git only. I will delete the upload on mentors.

​Thanks,
Olzhas​
​

Re: RFS: scram/0.11.6-1

2017-02-12 Thread Olzhas Rakhimov 
Thanks Mattia,

I think the fixed bugs are not critical to pull the package out of testing
or unblock it.

Regards,
Olzhas

On Sat, Feb 11, 2017 at 11:32 PM, Mattia Rizzolo <mat...@debian.org> wrote:

> On Sat, Feb 11, 2017 at 10:27:56PM -0800, Olzhas Rakhimov wrote:
> > this is my first bug-fix update after SCRAM is in testing;
> > Is there anything new I should know?
>
> Yes.
> https://lists.debian.org/debian-devel-announce/2017/02/msg1.html
>
> If you didn't receive that email, please subscribe to the
> debian-devel-announce mailing list.
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>

RFS: scram/0.11.6-1

2017-02-11 Thread Olzhas Rakhimov 
Hi everybody,

I need a sponsor to upload an update to this package.
There's no packaging related changes;

https://anonscm.debian.org/git/debian-science/packages/scram.git/
https://mentors.debian.net/package/scram

By the way,
this is my first bug-fix update after SCRAM is in testing;
Is there anything new I should know?

Thanks all,
Olzhas Rakhimov

Re: Sponsor upload request for new package scram

2016-12-14 Thread Olzhas Rakhimov 
Mattia,
Thanks for reviewing again. I corrected the changelog and uploaded the
package.

Regards,
Olzhas

On Tue, Dec 13, 2016 at 11:56 PM, Mattia Rizzolo <mat...@debian.org> wrote:

> On Mon, Dec 12, 2016 at 03:55:55AM -0800, Olzhas Rakhimov wrote:
> > I've released a bug-fix version incorporating the patches from the
> initial
> > Debian upload
> > and some bug-fixes in the tool itself.
>
> great!
>
> > The new version has already been uploaded to Alioth and mentors.
> > I need a sponsor for upload.
> > Mattia, if you have a little time, there shouldn't be much to review
> since
> > the last upload.
> > I would appreciate anyone's review and sponsorship.
>
> Yeah, that looks great indeed :)
> Just please write a correct debian changelog.  What you did from a
> "Debian point of view" is updating to a new upstream release and
> removing patches (and manpages) that have been incorporated upstream.
> What you wrote is instead from a "upstream point of view" where you
> incorportated changes in the last debian release.
> See this page for more details about debian/changelog and what it should
> contain:
> https://www.debian.org/doc/manuals/developers-reference/
> ch06.en.html#bpp-debian-changelog
>
> Also please `dch -r` it (i.e. s/UNRELEASED/unstable/)
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>

Re: Sponsor upload request for new package scram

2016-12-12 Thread Olzhas Rakhimov 
Hello,
I've released a bug-fix version incorporating the patches from the initial
Debian upload
and some bug-fixes in the tool itself.
The new version has already been uploaded to Alioth and mentors.
I need a sponsor for upload.
Mattia, if you have a little time, there shouldn't be much to review since
the last upload.
I would appreciate anyone's review and sponsorship.

Thank you all,
Olzhas

On Thu, Dec 8, 2016 at 2:16 PM, Olzhas Rakhimov <ol.rakhi...@gmail.com>
wrote:

> Hello everybody, the package has been uploaded!
> Thanks Ghislain, Matttia, Andreas, and James for helping, reviewing, and
> sponsoring this package.
> It was pleasure to work with you.
>
> Thanks,
> Olzhas
>
> On Tue, Dec 6, 2016 at 2:47 AM, Mattia Rizzolo <mat...@debian.org> wrote:
>
>> On Tue, Dec 06, 2016 at 02:44:19AM -0800, Olzhas Rakhimov wrote:
>> > Indeed, the next bug-fix release is coming soon (hopefully by the end of
>> > this month).
>>
>> Now this is going to go to NEW, and it'll have to clear it by the 25th
>> of this month, otherwise your package won't be in testing.  Since we're
>> reaching the freeze the rules for testing migration gets stricter and
>> stricter.  https://release.debian.org/#release-dates
>>
>> --
>> regards,
>> Mattia Rizzolo
>>
>> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
>> more about me:  https://mapreri.org : :'  :
>> Launchpad user: https://launchpad.net/~mapreri  `. `'`
>> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>>
>
>

Re: Sponsor upload request for new package scram

2016-12-08 Thread Olzhas Rakhimov 
Hello everybody, the package has been uploaded!
Thanks Ghislain, Matttia, Andreas, and James for helping, reviewing, and
sponsoring this package.
It was pleasure to work with you.

Thanks,
Olzhas

On Tue, Dec 6, 2016 at 2:47 AM, Mattia Rizzolo <mat...@debian.org> wrote:

> On Tue, Dec 06, 2016 at 02:44:19AM -0800, Olzhas Rakhimov wrote:
> > Indeed, the next bug-fix release is coming soon (hopefully by the end of
> > this month).
>
> Now this is going to go to NEW, and it'll have to clear it by the 25th
> of this month, otherwise your package won't be in testing.  Since we're
> reaching the freeze the rules for testing migration gets stricter and
> stricter.  https://release.debian.org/#release-dates
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>

Re: Sponsor upload request for new package scram

2016-12-06 Thread Olzhas Rakhimov 
Thanks Mattia,
Indeed, the next bug-fix release is coming soon (hopefully by the end of
this month).

Regards,
Olzhas

On Tue, Dec 6, 2016 at 2:39 AM, Mattia Rizzolo  wrote:

> On Thu, Nov 24, 2016 at 08:20:13PM +, Mattia Rizzolo wrote:
> > if nobody beats me (and I really please welcome them to), I can look at
> > this some time over the weekend.
>
> Indeed, this package is just about good to go.
>
> I'm building and will upload (and git push) it as I write.
>
> Given that you're upstream, I hope you'll see about moving the manpage
> and that patch (well, after proper modifications..) on the upstream side
> for the next release :)
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>

Re: Sponsor upload request for new package scram

2016-11-20 Thread Olzhas Rakhimov 
Hi James,
Thanks for taking a look at the code.
​I have tried building without linking to boost:date_time.
In debug mode,
linker errs with asking for
'boost::gregorian::greg_month::as_short_string() const'​.
However, in release mode, it is ok.
I tried with 'BOOST_DATE_TIME_NO_LIB' defined but still has this strange
behavior.

On Sun, Nov 20, 2016 at 2:12 PM, James Clarke <jrt...@jrtc27.com> wrote:

> Hi Olzhas,
> > On 19 Nov 2016, at 04:14, Olzhas Rakhimov <ol.rakhi...@gmail.com> wrote:
> >
> > Hi James,
> >
> >> On Fri, Nov 18, 2016 at 10:01 AM, James Clarke <jrt...@jrtc27.com>
> wrote:
> >>> On 18 Nov 2016, at 02:30, Olzhas Rakhimov <ol.rakhi...@gmail.com>
> wrote:
> >>>
> >>> Hello James,
> >>> Thanks again! I cleaned up things and reuploaded.
> >>>
> >>> Actually, I am not sure how to reproduce 'dpkg-shlibdeps' warnings,
> >>> so I couldn't test the fix.
> >>
> >> I was building with `gbp buildpackage --git-pbuilder` in an up-to-date
> >> sid chroot. I’d rather see the upstream build system stop linking
> >> against the libraries rather than using --as-needed, since there’s no
> >> reason why it needs to.
> >
> > ​Unfortunately, there's no standard 'FindLibXML++' module in CMake. I am
> using one of popular scripts found on many other projects.​
> > ​From that cmake module, I only use a command to link against
> libxml++2.6, but somehow the scripts seem to drag all libxml++2.6
> dependencies with it.
> > I am a bit reluctant to mess with those custom scripts​.
> > I believe those scripts are also setup for static linking, so I guess
> that's the reason it drags all its dependencies along.
> > Currently, I don't have a better solution and couldn't find how other
> projects dealing with it.
> > Can anyone point me into some examples dealing with libxml++ cleanly?
>
> My guess is that the you only need the headers for those libraries, and
> they have all the implementation you need, rather than needing to link
> against the library itself. For example, it seems that the only reason
> you use boost datetime is for the posix_time namespace to calculate
> pt::to_iso_extended_string(pt::second_clock::universal_time()).
> Presumably these are simple enough that they are self-contained in the
> header files. Given this explanation, I’m less concerned about including
> --as-needed, since dropping the libraries could cause build errors in
> future if you need functions that aren’t implemented in the headers.
>
> At this point, I'll really be happy if '--as-needed' solution is accepted.​

Thanks,
Olzhas

Re: Sponsor upload request for new package scram

2016-11-17 Thread Olzhas Rakhimov 
Hello James,
Thanks again! I cleaned up things and reuploaded.

Actually, I am not sure how to reproduce 'dpkg-shlibdeps' warnings,
so I couldn't test the fix.

For some reason, there's 'watch' file warnings. It is taken from
'debian/watch' documentation and works locally with uscan.
I couldn't tell what is wrong.

Thanks,
Olzhas

On Thu, Nov 17, 2016 at 3:50 PM, James Clarke <jrt...@jrtc27.com> wrote:

> > On 17 Nov 2016, at 20:00, Olzhas Rakhimov <ol.rakhi...@gmail.com> wrote:
> >
> > Hello James,
> > Thanks for the prompt feedback. I reuploaded a revised version.
> >
> >> On Thu, Nov 17, 2016 at 11:24 AM, James Clarke <jrt...@jrtc27.com>
> wrote:
> >> Hi Olzhas,
> >>> On 17 Nov 2016, at 18:48, Olzhas Rakhimov <ol.rakhi...@gmail.com>
> wrote:
> >>>
> >>> Hello everybody,
> >>> I uploaded a new version with the repository on alioth.
> >>> I would like to hear your feedback.
> >>
> >> 2. Until you’re ready to upload, leave the distribution as UNRELEASED.
> >>`dch` (and `dch -r` to release) should do this automatically, but
> >>you’ll need to change it manually since the entry already exists
> >>(I think).
>
> You still haven’t done this. Moreover, please stop changing the version
> number on every commit. 0.11.4-1 should be the first version you upload,
> and you should not tag it in git until you upload it. Please delete the
> debian/0.11.4-3 and -4 tags (and make sure to delete them on the remote
> too, not just locally), and don’t create any tags until you get the go-
> ahead from a sponsor. Note that if you upload to mentors.debian.net, you
> can keep uploading modified packages with the same -1 version.
>
> >> 3. Bump d/compat up to 10; debhelper 10 is available in backports.
> >
> > ​It looks like Ubuntu 16.04 still has 9.2, so I am getting warnings from
> lintian.
>
> Indeed, xenial-backports has debhelper 10, but no updated lintian. Just
> ignore any warnings about that. You do, however, need to make sure you
> have the right versioned depends on debhelper (>= 10) (10 not 10.0.0).
>
> >> 6. Does Release include debugging information? I thought there was
> >>RelWithDebInfo or something similar for that? Please make sure
> >>debugging information is included; dh_strip will strip it from the
> >>package and create an automatic scram-dbgsym for it (which should
> >>not be mentioned in d/control), so there are debugging symbols for
> >>those who want it, but no increase in size for those who don’t.
> >
> > ​The global flags are running with RelWithDebInfo : -O2 -g.
> > Release just adds -O3 at the end.
>
> You’re right, -O2 -g is given, but not because of anything to do with
> RelWithDebInfo. They’re coming from the default CFLAGS for Debian
> packages, along with `-fdebug-prefix-map= -fstack-protector-strong
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2`, some
> of which are hardening flags.
>
> 8. There’s a typo in doc/scram.man: Calcualte should be Calculate. Note
>that I got this from `lintian -EI --pedantic`. This can be verbose,
>but I suggest you get in the habit of checking it, since it can pick
>up on things you might otherwise miss.
>
> 9. When building, I get the following:
>
>dpkg-shlibdeps: warning: package could avoid a useless dependency if
> debian/scram/usr/bin/scram was not linked against libglib-2.0.so.0 (it uses
> none of the library's symbols)
>dpkg-shlibdeps: warning: package could avoid a useless dependency if
> debian/scram/usr/bin/scram was not linked against libsigc-2.0.so.0 (it uses
> none of the library's symbols)
>dpkg-shlibdeps: warning: package could avoid a useless dependency if
> debian/scram/usr/bin/scram was not linked against
> libboost_date_time.so.1.62.0 (it uses none of the library's symbols)
>dpkg-shlibdeps: warning: package could avoid a useless dependency if
> debian/scram/usr/bin/scram was not linked against libxml2.so.2 (it uses
> none of the library's symbols)
>
>Given this is the only binary artefact, why are these libraries being
>given in LDFLAGS?
>
> Regards,
> James
>
>

Re: Sponsor upload request for new package scram

2016-11-17 Thread Olzhas Rakhimov 
Hello James,
Thanks for the prompt feedback. I reuploaded a revised version.

On Thu, Nov 17, 2016 at 11:24 AM, James Clarke <jrt...@jrtc27.com> wrote:

> Hi Olzhas,
> > On 17 Nov 2016, at 18:48, Olzhas Rakhimov <ol.rakhi...@gmail.com> wrote:
> >
> > Hello everybody,
> > I uploaded a new version with the repository on alioth.
> > I would like to hear your feedback.
>
> A few suggestions:
>
> 1. I personally don’t see the point of including the history of the
>ubuntu versions in d/changelog.
>
> 2. Until you’re ready to upload, leave the distribution as UNRELEASED.
>`dch` (and `dch -r` to release) should do this automatically, but
>you’ll need to change it manually since the entry already exists
>(I think).
>
> 3. Bump d/compat up to 10; debhelper 10 is available in backports.
>
> ​It looks like Ubuntu 16.04 still has 9.2, so I am getting warnings from
lintian.
​


> 4. Change Vcs-Git to be https too (and in fact I believe it’s currently
>wrong; if you’re using the git:// protocol, the /git/ should not be
>included in the URL).
>
> 5. If you change to compat 10, you can drop the --parallel, since it’s
>now the default.
>
> 6. Does Release include debugging information? I thought there was
>RelWithDebInfo or something similar for that? Please make sure
>debugging information is included; dh_strip will strip it from the
>package and create an automatic scram-dbgsym for it (which should
>not be mentioned in d/control), so there are debugging symbols for
>those who want it, but no increase in size for those who don’t.
>
> ​The global flags are running with RelWithDebInfo : -O2 -g.
Release just adds -O3 at the end.

> 7. d/watch doesn’t look like the suggestion for GitHub in uscan(1);
>perhaps this works, but I’m not a uscan expert.
>
> Regards,
> James
>
>

Re: Sponsor upload request for new package scram

2016-11-17 Thread Olzhas Rakhimov 
Hello everybody,
I uploaded a new version with the repository on alioth.
I would like to hear your feedback.

Thanks,
Olzhas


On Tue, Nov 15, 2016 at 7:30 PM, Olzhas Rakhimov <ol.rakhi...@gmail.com>
wrote:

> Hello,
> I have re-uploaded with your feedback.
> cdbs is gone. It looks even simpler w/o cdbs. Thanks Chis!
>
> The next update is hopefully going to be with the new repo on alioth.
>
> As the upstream author, I probably had a wrong idea of what the packaging
> for Debian would be.
> It looks like the repo on alioth is going to be structured according to
> the Debian Science policies,
> so simple mirroring seems not to make the trick (as I am doing right now).
>
> Thanks,
> Olzhas
>
> On Mon, Nov 14, 2016 at 11:31 PM, Ghislain Vaillant <ghisv...@gmail.com>
> wrote:
>
>> On 15/11/16 06:37, Andreas Tille wrote:
>>
>>> Hi Olzhas,
>>>
>>> On Mon, Nov 14, 2016 at 11:07:24AM -0800, Olzhas Rakhimov wrote:
>>>
>>>> Hi,
>>>> Thanks for the help and feedback.
>>>> I have only a guest account on alioth,
>>>> and AFAIK I would need Debian developer to let me create a project.
>>>>
>>>
>>> The *project* Debian Science exists.  Any member of the Debian Science
>>> team can create git repositories there.  If you are not a member of
>>> this group yet please ask for it.
>>>
>>> Please also do a web search for "Debian Science policy" to get hints how
>>> to do this (sorry, I'm behind a slow connection, thus only this short
>>> hint).
>>>
>>
>> I second Andreas' advice here. Please do read the general Debian policy
>> [1] and the science team specifics [2].
>>
>> [1] https://www.debian.org/doc/debian-policy/
>> [2] https://debian-science.alioth.debian.org/debian-science-policy.html
>>
>> I will be mirroring the GitHub repo on alioth for packaging.
>>>>
>>>
>> Do you intend to use the upstream repository for packaging ?
>>
>> I use CMake for building. It takes only two lines with cdbs: debhelper.mk
>>>> and cmake.mk.
>>>> There's no other code. I am not sure how to do it without cdbs, so any
>>>> reference would be helpful.
>>>>
>>>
>>> There are lots of examples.  Dh is similarly easy.  Others here might
>>> help.
>>>
>>
>> Plenty of examples here:
>>
>> https://codesearch.debian.net/search?q=--buildsystem%3Dcmake=1
>>
>> All you need to do is invoke `dh $@ --buildsystem=cmake` and use
>> overrides target for the specifics of your build system that deviates from
>> the standard. You might just try without overrides at first and iterate
>> from here.
>>
>> Hope this helps.
>>
>> Ghis
>>
>>
>

Re: Sponsor upload request for new package scram

2016-11-15 Thread Olzhas Rakhimov 
Hello,
I have re-uploaded with your feedback.
cdbs is gone. It looks even simpler w/o cdbs. Thanks Chis!

The next update is hopefully going to be with the new repo on alioth.

As the upstream author, I probably had a wrong idea of what the packaging
for Debian would be.
It looks like the repo on alioth is going to be structured according to the
Debian Science policies,
so simple mirroring seems not to make the trick (as I am doing right now).

Thanks,
Olzhas

On Mon, Nov 14, 2016 at 11:31 PM, Ghislain Vaillant <ghisv...@gmail.com>
wrote:

> On 15/11/16 06:37, Andreas Tille wrote:
>
>> Hi Olzhas,
>>
>> On Mon, Nov 14, 2016 at 11:07:24AM -0800, Olzhas Rakhimov wrote:
>>
>>> Hi,
>>> Thanks for the help and feedback.
>>> I have only a guest account on alioth,
>>> and AFAIK I would need Debian developer to let me create a project.
>>>
>>
>> The *project* Debian Science exists.  Any member of the Debian Science
>> team can create git repositories there.  If you are not a member of
>> this group yet please ask for it.
>>
>> Please also do a web search for "Debian Science policy" to get hints how
>> to do this (sorry, I'm behind a slow connection, thus only this short
>> hint).
>>
>
> I second Andreas' advice here. Please do read the general Debian policy
> [1] and the science team specifics [2].
>
> [1] https://www.debian.org/doc/debian-policy/
> [2] https://debian-science.alioth.debian.org/debian-science-policy.html
>
> I will be mirroring the GitHub repo on alioth for packaging.
>>>
>>
> Do you intend to use the upstream repository for packaging ?
>
> I use CMake for building. It takes only two lines with cdbs: debhelper.mk
>>> and cmake.mk.
>>> There's no other code. I am not sure how to do it without cdbs, so any
>>> reference would be helpful.
>>>
>>
>> There are lots of examples.  Dh is similarly easy.  Others here might
>> help.
>>
>
> Plenty of examples here:
>
> https://codesearch.debian.net/search?q=--buildsystem%3Dcmake=1
>
> All you need to do is invoke `dh $@ --buildsystem=cmake` and use overrides
> target for the specifics of your build system that deviates from the
> standard. You might just try without overrides at first and iterate from
> here.
>
> Hope this helps.
>
> Ghis
>
>

Re: Sponsor upload request for new package scram

2016-11-14 Thread Olzhas Rakhimov 
Hello,
The current configuration for packaging is available on 'ppa-deb' branch of
the scram repository at https://github.com/rakhimov/scram
You can checkout it with:
git clone --branch ppa-deb https://github.com/rakhimov/scram

Thanks,
Olzhas

On Mon, Nov 14, 2016 at 11:07 AM, Olzhas Rakhimov <ol.rakhi...@gmail.com>
wrote:

> Hi,
> Thanks for the help and feedback.
> I have only a guest account on alioth,
> and AFAIK I would need Debian developer to let me create a project.
> I will be mirroring the GitHub repo on alioth for packaging.
>
> I use CMake for building. It takes only two lines with cdbs: debhelper.mk
> and cmake.mk.
> There's no other code. I am not sure how to do it without cdbs, so any
> reference would be helpful.
>
> Thanks,
> Olzhas
>
>
>
>
> On Mon, Nov 14, 2016 at 6:09 AM, Andreas Tille <andr...@an3as.eu> wrote:
>
>> Hi Olzhas,
>>
>> On Sun, Nov 13, 2016 at 03:04:28PM -0800, Olzhas Rakhimov wrote:
>> > Hello,
>> > I am new to packaging for debian.
>> > I would appreciate any feedback and sponsorship
>> > for this package:
>> > https://mentors.debian.net/package/scram
>>
>> I have added scram to the engineering (according to your private mail -
>> no idea why you have sent it in private).  This at least fullfills one
>> condition for becoming sponsored via "Sponsering of Blends"[1] but it
>> violates condition 2. (maintained in Debian Science Vcs).  Since it has
>> several advantages to maintain Debian packages on alioth, please use
>> Debian Science git rather than Github for the packaging work.
>>
>> I did not had a deeper look (if I could clone from git.debian.org I
>> would possibly have) but seeing cdbs in Build-Dependencies might scare
>> me away as a sponsor since if all fails I need to step in with
>> maintaining the package and I'm just in the process of getting rid of
>> cdbs in all my packages ...
>>
>> Kind regards
>>
>>   Andreas.
>>
>>
>> [1] https://wiki.debian.org/DebianPureBlends/SoB
>>
>> --
>> http://fam-tille.de
>>
>>
>

Re: Sponsor upload request for new package scram

2016-11-14 Thread Olzhas Rakhimov 
Hi,
Thanks for the help and feedback.
I have only a guest account on alioth,
and AFAIK I would need Debian developer to let me create a project.
I will be mirroring the GitHub repo on alioth for packaging.

I use CMake for building. It takes only two lines with cdbs: debhelper.mk
and cmake.mk.
There's no other code. I am not sure how to do it without cdbs, so any
reference would be helpful.

Thanks,
Olzhas



On Mon, Nov 14, 2016 at 6:09 AM, Andreas Tille <andr...@an3as.eu> wrote:

> Hi Olzhas,
>
> On Sun, Nov 13, 2016 at 03:04:28PM -0800, Olzhas Rakhimov wrote:
> > Hello,
> > I am new to packaging for debian.
> > I would appreciate any feedback and sponsorship
> > for this package:
> > https://mentors.debian.net/package/scram
>
> I have added scram to the engineering (according to your private mail -
> no idea why you have sent it in private).  This at least fullfills one
> condition for becoming sponsored via "Sponsering of Blends"[1] but it
> violates condition 2. (maintained in Debian Science Vcs).  Since it has
> several advantages to maintain Debian packages on alioth, please use
> Debian Science git rather than Github for the packaging work.
>
> I did not had a deeper look (if I could clone from git.debian.org I
> would possibly have) but seeing cdbs in Build-Dependencies might scare
> me away as a sponsor since if all fails I need to step in with
> maintaining the package and I'm just in the process of getting rid of
> cdbs in all my packages ...
>
> Kind regards
>
>   Andreas.
>
>
> [1] https://wiki.debian.org/DebianPureBlends/SoB
>
> --
> http://fam-tille.de
>
>

Sponsor upload request for new package scram

2016-11-13 Thread Olzhas Rakhimov 
Hello,
I am new to packaging for debian.
I would appreciate any feedback and sponsorship
for this package:
https://mentors.debian.net/package/scram

ITP:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842766

RFS:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842884

Regards,
Olzhas Rakhimov