Re: berlios closing; where should my projects escape to?

[Adam Borowski]

On Tue, Oct 18, 2011 at 07:22:15AM +0100, Paul McEnery wrote:
> On 18 October 2011 06:02, Paul Elliott  wrote:
> > Any suggestions?
> 
> GitHub?

What about Gitorious?  They provide a bit less, but without any obnoxious
restrictions.  And they release their server software freely.

-- 
1KB // Yo momma uses IPv4!


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111018083126.ga28...@angband.pl

Re: berlios closing; where should my projects escape to?

[Paul Elliott]

On Tuesday, October 18, 2011 01:22:15 AM Paul McEnery wrote:
> On 18 October 2011 06:02, Paul Elliott  wrote:
> > [...]
> > 
> > Any suggestions?
> 
> GitHub? I use them for my package repos, and I see that MythTV recently (in
> the last few months) switched to them. Not sure about the "full" project
> experience, I.e. mailing lists, website etc, but they do appear to have
> these features, although I've not used it to that extent.
> 
> Paul.

I don't want to learn GIT right now. Is there someplace I could stay with svn?

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: This is a digitally signed message part.

Re: berlios closing; where should my projects escape to?

[Boris Pek]

Hi,

In my personal experience free hosting services by the degree of convenience
arranged in this order:
1) GitHub. Best of the best, really. =) You can use svn2git or git-svn to import
the history of your commits from Subversion:
http://help.github.com/import-from-subversion/
2) Google Code. Subversion, Git and Mercurial are available. The most
comfortable things are: issues list, wiki, downloads and admin settings section.
3) SourceForge. Hosting is very flexible and functional. But their site is a
little bit slow. And some features can not be switched off.
4) Gitorious (used just as mirror of GitHub repo in our projects)

Good luck.


18.10.2011, 08:02, "Paul Elliott" :
> Perhaps this is offtopic, but there are so many packagers here, perhaps I can
> find an answer.
>
> Berlios is closing, I have two small projects, GPLed, that use subversion and
> publish tarballs, where should I go?
>
> I looked at sourceforge, but they are always sending me adds. Too comercial
> for my taste.
>
> I signed up at savanah, but they have not even assigned my two create project
> requests even though their automated system says they should have been done 5
> days ago. No one responds to me.
>
> I must move my projects before berlios closes.
>
> Any suggestions?
>
> Thank You.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/548101318927...@web73.yandex.ru

Re: berlios closing; where should my projects escape to?

[Manuel A. Fernandez Montecelo]

Sending the reply to the list too, maybe there are other people
interested and nobody mentioned it yet...

2011/10/18 Manuel A. Fernandez Montecelo :
> 2011/10/18 Paul Elliott :
>> On Tuesday, October 18, 2011 01:22:15 AM Paul McEnery wrote:
>>> On 18 October 2011 06:02, Paul Elliott  wrote:
>>> > [...]
>>> >
>>> > Any suggestions?
>>>
>>> GitHub? I use them for my package repos, and I see that MythTV recently (in
>>> the last few months) switched to them. Not sure about the "full" project
>>> experience, I.e. mailing lists, website etc, but they do appear to have
>>> these features, although I've not used it to that extent.
>>>
>>> Paul.
>>
>> I don't want to learn GIT right now. Is there someplace I could stay with 
>> svn?
>
> http://gna.org/ -- the source from when savannah-gnu comes from.
>
> I've been happily using it for years for not-very-demanding projects,
> haven't been using it in the last couple of years.  It seems to me
> that they don't have much working-force behind the scenes.
>
> Cheers.
>


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/capq4b8k7qayzgszbbfanfa84dret68pss27yqx1mkt--wz4...@mail.gmail.com

Re: berlios closing; where should my projects escape to?

[Patrick Matthäi]

Am 18.10.2011 10:42, schrieb Paul Elliott:

On Tuesday, October 18, 2011 01:22:15 AM Paul McEnery wrote:

On 18 October 2011 06:02, Paul Elliott  wrote:

[...]

Any suggestions?


GitHub? I use them for my package repos, and I see that MythTV recently (in
the last few months) switched to them. Not sure about the "full" project
experience, I.e. mailing lists, website etc, but they do appear to have
these features, although I've not used it to that extent.

Paul.


I don't want to learn GIT right now. Is there someplace I could stay with svn?



Sourceforge?


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e9d3c64.20...@debian.org

Re: berlios closing; where should my projects escape to?

[Boris Pek]

>  I don't want to learn GIT right now. Is there someplace I could stay with 
> svn?

Maybe it was the sign to learn something new? =)

Git and Mercurial are really great DVCS. They are very suitable for small
projects with small developers group.

Subversion is more suitable for extremely big projects with strict hierarchy.
Or for repos with a lot of binary files.

Bazaar is something terrible designed. But some people use it...

Also do not ignore the Wikipedia:
http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/494441318928...@web85.yandex.ru

RFS: ptex2tex (3rd try)

[Johannes Ring]

Dear mentors, debian-python,

I am looking for a sponsor for my package "ptex2tex".

* Package name: ptex2tex
 Version : 0.4-1
 Upstream Author : Hans Petter Langtangen and Ilmar Wilbers
* URL : http://ptex2tex.googlecode.com
* License : BSD-3-clause
 Section : text

It builds one binary package:
ptex2tex - easy generation of (possibly complex) LaTeX environments

The package appears to be lintian clean.

The upload would fix this bug: 641304 (ITP)

The package is available in the PAPT's Subversion repository:
- svn://svn.debian.org/python-apps/packages/ptex2tex/trunk
- http://svn.debian.org/viewsvn/python-apps/packages/ptex2tex/trunk/

I would be very happy if someone uploaded this package for me.

Kind regards,

Johannes Ring


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CALjQY_HcVF5Z5K5Ed=km+CmnKm_0m2tH-_GEtZYhoUGa=he...@mail.gmail.com

Python: Including Nosetest

[Ole Streicher]

Dear lists,

I am working on a package (python-pywcs) that may include a "nosetest"
which I want to run before installation.

For this, I put the following line into debian/rules (for debhelper):

override_dh_auto_test:
nosetest

However, when I try to build the package, I get the error

==
ERROR: Failure: ImportError (No module named _pywcs)
--
Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/nose/loader.py", line 390, in
loadTestsFromName
addr.filename, addr.module)
  File "/usr/lib/pymodules/python2.7/nose/importer.py", line 39, in
importFromPath
return self.importFromDir(dir_path, fqname)
  File "/usr/lib/pymodules/python2.7/nose/importer.py", line 86, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
  File
"/home/oles/Projects/2010/launchpad-cpl/build/sid/pywcs-1.10-4.7/tests/test.py",
line 8, in 
import pywcs
  File
"/home/oles/Projects/2010/launchpad-cpl/build/sid/pywcs-1.10-4.7/lib/pywcs.py",
line 71, in 
import _pywcs
ImportError: No module named _pywcs

--

This error comes from the fact, that the nosetest uses the current
directory as the first entry in the path and so tries to read the source
directory (pywcs/...) and not the build-and-not-installed-yet version in
build/lib.linux-x86_64-2.6/ (and ...2.7). Since I assume that it is not
very clean just to include that path (or chdir there before running the
test), I guess there is another solution on how to run nosetest during
package build?

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e9d4c20.6030...@liska.ath.cx

Time delay between RFS messages

[Boris Pek]

Hi everyone,

I have a question about time delay between RFS messages.

Situation #1:
1) I send RFS message at first.
2) Nobody answer me.
3) Nobody upload my package.

Situation #2:
1) I send RFS message at first.
2) Someone reply me with notes how I can improve a package.
3) I update a package in m.d.n.
4) I send reply to mailing list.
5) Nobody answer me.
6) Nobody upload my package.

So how long I should wait to sent repeated message in these cases?
(Since last message or since first message in that thread)

I didn't use RFS before and I didn't find this info in the FAQ.

Now I have 5 packages which are waiting upload:
http://mentors.debian.net/packages/uploader/tehnick-8%40mail.ru
3 updated packages already in Debian and 2 packages close ITP bug reports.

Also I hope that my regular sponsor will back to developing Debian in the
nearest future and I will work with him again.

But I think this question can be added somewhere in documentation.

Best regards,
Boris


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/581921318936...@web106.yandex.ru

Re: Python: Including Nosetest

[Yaroslav Halchenko]

well -- if you discover some other way -- please let me know.

Otherwise -- I have been doing exactly that -- cd build and run tests
from there and where permits against the installed version under
debian/tmp or debian/python-MODULE, e.g.:

http://anonscm.debian.org/gitweb/?p=pkg-exppsy/brian.git;a=blob;f=debian/rules;hb=HEAD#l44

On Tue, 18 Oct 2011, Ole Streicher wrote:
> This error comes from the fact, that the nosetest uses the current
> directory as the first entry in the path and so tries to read the source
> directory (pywcs/...) and not the build-and-not-installed-yet version in
> build/lib.linux-x86_64-2.6/ (and ...2.7). Since I assume that it is not
> very clean just to include that path (or chdir there before running the
> test), I guess there is another solution on how to run nosetest during
> package build?
-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111018131054.gb32...@novo.onerussian.com

Re: RFS: xz-utils (updated package)

[Jakub Wilk]

* Jonathan Nieder , 2011-10-17, 23:49:

- 
http://alioth.debian.org/~jrnieder-guest/temp/xz-utils_5.1.1alpha+20110809-3.dsc


In debian/patches/abi-liblzma2-compat you wrote:

| Applications linked directly to liblzma2 and indirectly to liblzma5 use
| the implementation from liblzma5

I don't claim to be an expert on symbol versioning, but I did some 
experiments, and it doesn't seem to be the case. If a program is linked 
to two versions of a library, one of which doesn't use versioned 
symbols, then the symbols from the directly-linked one shadows the 
other.


|   $ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/liblzma.so.5 xz README
|   xz: README: Unsupported options

Well, that's not really a simulation of an application linked directly 
to liblzma2 and indirectly to liblzma5...


| Unfortunately one cannot even get lucky and find the symbol from
| liblzma2 used from time to time: versioned symbols take precedence over
| unversioned ones when resolving unversioned references.

As far as I can tell, this is not the case.

All in all, while the patch probably have merits (I didn't have time to 
look closely), the rationale seems flawed to me.



In debian/symbols there is:
| (symver)XZ_5.0 5.1.1alpha+20110809

To be pedantically correct, that should be:
| (symver)XZ_5.0 5.1.1alpha+20110809-3~

On the other hand, since you've just bumped SONAME, it doesn't matter at 
all. You could have used even 0 here.


I am not entirely happy about your "liblzma_private_symbols" hack. It 
might work well for now, but I wouldn't be surprised if it'll make your 
package FTBFS with a future version of dpkg-dev, if it becomes stricter 
at validating input.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111018132822.ga8...@jwilk.net

Re: Python: Including Nosetest

[Ole Streicher]

Am 18.10.2011 15:10, schrieb Yaroslav Halchenko:
> well -- if you discover some other way -- please let me know.

>From elsewhere , I got the hint
to try

 python setup.py build_ext -i

which builds the extension in-place. So my debian/rules looks like

override_dh_auto_test:
python setup.py build_ext -i && nosetests tests/test.py

This works fine for me, and I hope it will survive the review :-)

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e9d8df8.4060...@liska.ath.cx

Re: Python: Including Nosetest

[Yaroslav Halchenko]

well, yeah -- but I would advise to run tests against "installed"
version of the software -- who knows what was missing from their
MANIFEST.in or setup.py files... although might require few more custom
lines, testing against installed version IMHO provides better QA.
Moreover some modules/projects even forbid (or discourage) in-source
testing (e.g. IIRC numpy)

also, depending on the setup, it might be wasting CPU while building
extensions multiple times -- first in-place, then for installation

Just my 0.1 cents

On Tue, 18 Oct 2011, Ole Streicher wrote:
>  python setup.py build_ext -i

> which builds the extension in-place. So my debian/rules looks like

> override_dh_auto_test:
>   python setup.py build_ext -i && nosetests tests/test.py

> This works fine for me, and I hope it will survive the review :-)

-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111018144710.gg10...@onerussian.com

Re: berlios closing; where should my projects escape to?

[Pietro Battiston]

Il giorno mar, 18/10/2011 alle 10.44 +0200, Patrick Matthäi ha scritto:
> Am 18.10.2011 10:42, schrieb Paul Elliott:
> > On Tuesday, October 18, 2011 01:22:15 AM Paul McEnery wrote:
> >> On 18 October 2011 06:02, Paul Elliott  
> >> wrote:
> >>> [...]
> >>>
> >>> Any suggestions?
> >>
> >> GitHub? I use them for my package repos, and I see that MythTV recently (in
> >> the last few months) switched to them. Not sure about the "full" project
> >> experience, I.e. mailing lists, website etc, but they do appear to have
> >> these features, although I've not used it to that extent.
> >>
> >> Paul.
> >
> > I don't want to learn GIT right now. Is there someplace I could stay with 
> > svn?
> >
> 
> Sourceforge?
> 


Maybe it's only my (long) unfortunate esperience, but Sourceforge seems
to me really awful from the users and potential contributors point of
view.
It's cluttered with ads and unused (in most projects) functions, with a
bad antispam check which basically obliges projects admins to close
ticket reporting/submitting to unregistered users (not that that's
terrible, but it just vanishes the openness of the system). In general,
I really thing it has a terrible user interface.

Just to give an example of something which is similar but "nicer", let
me mention Launchpad, which I tend to avoid because I don't like bazaar,
but in one case I find very convenient (for the team-related features)
coupled with an external git repository.

Pietro


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1318949679.2937.60.ca...@demporaneo.pietrobattiston.it

Re: not installing files...(with cdbs)

[IOhannes m zmoelnig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-13 02:10, Charles Plessy wrote:
>  
>> - - removing the files right after the "install" target.
> 
> Dear IOhannes,
> 
> I tend to exclude files by removing them.  This way, it is self-documenting
> (but a comment on why they are removed may be very useful sometimes).  I do 
> not
> use the --force option of rm, so that it is immediately noticed when the file
> to remove is not installed anymore at a later upstream update.
> 


thanks for your confirmation (and sorry for the long delay)

fgmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6dl+cACgkQkX2Xpv6ydvQmJwCgkl78EH0a1+9//qykJiItre3s
aFMAoOlWvL+r4yAm7GKGdEilf33N4fGs
=Mzha
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature

Re: berlios closing; where should my projects escape to?

[Barry Warsaw]

On Oct 18, 2011, at 12:00 PM, Boris Pek wrote:

>>  I don't want to learn GIT right now. Is there someplace I could stay with
>> svn?
>
>Maybe it was the sign to learn something new? =)
>
>Git and Mercurial are really great DVCS. They are very suitable for small
>projects with small developers group.
>
>Subversion is more suitable for extremely big projects with strict hierarchy.
>Or for repos with a lot of binary files.
>
>Bazaar is something terrible designed. But some people use it...

Of course, I'll disagree about Bazaar there.  I think it's actually the most
user friendly of the bunch, and totally up to the task of hosting your
projects.  I use it for almost all of mine.  I also think that it has
workflows and command lines that will feel fairly natural and similar to you
as a Subversion user.  Don't dismiss it out of hand.  (It also has a bzr-svn
plugin for bridging between the two vcs's.)

I am most definitely *not* interested in getting into a flame war about
version control systems.  If you don't like Bazaar, fine, YMMV.  If you have
technical questions, I'm happy to answer them as best I can, or point you to
other forums that can help you.

Cheers,
-Barry


signature.asc
Description: PGP signature

RFS: python-pywcs

[Ole Streicher]

Dear mentors,

I am looking for a sponsor for my package "python-pywcs".

 * Package name: python-pywcs
   Version : 1.10-1
   Upstream Author : Michael Droettboom 
 * URL : https://trac6.assembla.com/astrolib
 * License : BSD
   Section : python

It builds those binary packages:

python-pywcs - Set of routines for handling the FITS WCS standard

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/python-pywcs

Alternatively, one can download the package with dget using this command:

  dget -x
http://mentors.debian.net/debian/pool/main/p/python-pywcs/python-pywcs_1.10-1.dsc

I would be glad if someone uploaded this package for me.

Best regards,

Ole Streicher


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e9db1fd.7090...@liska.ath.cx

Re: RFR: blogofile -- Static website compiler and blog engine

[Andreas Rütten]

Hi Ben,

thanks for your comments, I will look into it in the next few days.


Kind regards,
Andreas



Am Tue, 18 Oct 2011 10:19:09 +1100
schrieb Ben Finney :

> Andreas Rütten  writes:
> 
> > this is a RFR (Request For Review) for my blogofile package. 
> 
> Thank you for working on this package, I am looking forward to its
> addition to Debian.
> 
> > - Since a few days the watch file included isn't working. Probably
> > this is because of a change of the GitHub frontend on October 12th
> > (see https://github.com/blog/958-the-code-tab). I informed Gunnar
> > Wolf about this because he is the maintainer of githubredir.d.n.
> 
> I don't understand the redirector. I also don't use Github.
> 
> Here is a watchfile that worked for me to get the latest tag as a
> tarball:
> 
> # watch control file for uscan
> version=3
> 
> opts=filenamemangle=s/.+\/tarball\/(.+)$/blogofile-$1\.tar\.gz/ \
> https://github.com/EnigmaCurry/blogofile/tags/ 
> /EnigmaCurry/blogofile/tarball/(.+)
> 
> Someone else here may suggest a better configuration. Or maybe the
> redirector will be fixed soon.
> 
> > - There is no upstream changelog file. Lintian complains about it. 
> >- Is it right, that a missing upstream changelog file is not a
> >  strict must have and it will not preventing the package to be
> >  included into Debian?
> 
> Correct. You should explicitly acknowledge the lack of a changelog by
> adding a Lintian override for that warning. Explain why in a comment
> to the override.
> 
> > - Lintian complains about an extra-license-file. I included this
> > file because the upstream LICENSE.txt contains beside the actual
> > Expat (MIT) license some thoughts from the Author about his view on
> > the license an Free Software in general.
> >- Should it be included or removed from the package?
> 
> Good question. Sadly the author has decided to use that file for some
> non-license information. You could make a request to the upstream
> developers to put that non-license information in a separate file.
> 
> > - The package builds fine with debuild respectively dpkg-buildpacke
> > but not with pbuilder or cowbuilder. That's sound for me that there
> > are missing build dependencies but unfortunately I couldn't identify
> >   which one until now.
> 
> The failures should tell you what the dependencies are. You might want
> to discuss them on the Python forum for Debian.
> 
> > - My resulting package contains a blogofile.egg-info directory. I'm
> > not sure if it's needed for the runtime of blogofile or only during
> > the build of the package. I ask on #debian-mentors and got that
> > there is no clear answer to this. Sometimes a package need
> > the .egg-info directory at runtime and sometimes not.
> >- Do you know if it's needed or not?
> >- Can somebody explain my how to identify this point?
> 
> Ask that question on the Debian Python forum also. There is a standard
> way to instruct the build system to install the package
> Debian-friendly.
> 
> > - Suggest or recommend a VCS, or explicitly git?
> >   Blogofile itself will greatly work without any Version Control
> >   System, but there are these two points:
> 
> I think you should not favour any particular VCS.
> 
> Since you say the package is useable without any VCS, there should be
> none in the Depends field. The Recommends field should list them all
> as alternatives (so it is satisfied by any one of them), and the
> Suggests field should list all of them together.
> 
> > - What do you think about shipping the example site as .zip file in
> > the Debian package?
> 
> Perhaps unpack it, and install it as a separate binary package (maybe
> ‘blogofile-examples’).
> 
> > - Should they go into a separate -data package?
> 
> Not that name, that would imply that it's *necessary* data for the
> package, which is not true.
> 
> > Thank you for keep reading up to here. Again any review, comment,
> > help or hints are really welcome.
> 
> Thanks for your perseverence.
> 



-- 
Andreas Rütten
mailto : andreasruet...@gmx.de
PGP, 6C9DFFB2, 8394 99DA 59BD BCE2 3FC8  3A9E 6633 0089 6C9D FFB2
--


signature.asc
Description: PGP signature

Re: RFS: xz-utils (updated package)

[Jonathan Nieder]

Jakub Wilk wrote:

> I don't claim to be an expert on symbol versioning, but I did some
> experiments, and it doesn't seem to be the case. If a program is linked to
> two versions of a library, one of which doesn't use versioned symbols, then
> the symbols from the directly-linked one shadows the other.

Thanks.  I made the same experiment (application X linked directly to
library A and linked via library C to library D) last year and got a
different result, but it's likely some detail was different.  The
dynamic linker behavior might have even changed.

> |   $ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/liblzma.so.5 xz README
> |   xz: README: Unsupported options
>
> Well, that's not really a simulation of an application linked directly to
> liblzma2 and indirectly to liblzma5...

Yes, that was just the quickest way I could find to demonstrate the
behavior when the symbol is taken from liblzma2.

> | Unfortunately one cannot even get lucky and find the symbol from
> | liblzma2 used from time to time: versioned symbols take precedence over
> | unversioned ones when resolving unversioned references.
>
> As far as I can tell, this is not the case.

Could you post your testcase somewhere?  I'll do the same as well.

> In debian/symbols there is:
> | (symver)XZ_5.0 5.1.1alpha+20110809
>
> To be pedantically correct, that should be:
> | (symver)XZ_5.0 5.1.1alpha+20110809-3~
>
> On the other hand, since you've just bumped SONAME, it doesn't matter at
> all. You could have used even 0 here.

Yes.

> I am not entirely happy about your "liblzma_private_symbols" hack. It might
> work well for now, but I wouldn't be surprised if it'll make your package
> FTBFS with a future version of dpkg-dev, if it becomes stricter at
> validating input.

Well, yes, it's a hack.  I watch dpkg development closely, so if I am
still maintainer at the time, dpkg or the package could be adjusted
appropriately to avoid fallout.

Hopefully when introducing such a change, dpkg-dev would provide a
more appropriate syntax for what is really intended there:
.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111018222849.ga10...@elie.hsd1.il.comcast.net

Re: RFS: xz-utils (updated package)

[Jonathan Nieder]

Jakub Wilk wrote:
> * Jonathan Nieder , 2011-10-17, 23:49:

>>- 
>>http://alioth.debian.org/~jrnieder-guest/temp/xz-utils_5.1.1alpha+20110809-3.dsc
[...]
> I don't claim to be an expert on symbol versioning, but

I forgot to say: thanks a lot for your careful review!  If
lzma_code@Base turns out not to be needed after all, that would make
me very happy.

[...]
> All in all, while the patch probably have merits (I didn't have time to look
> closely), the rationale seems flawed to me.

I'll try to get time to run some more tests and reroll with a more
careful explanation tonight.

Cheers,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111018225433.ga11...@elie.hsd1.il.comcast.net

RFS: likewise-open

[Richard Sellam]

Dear mentors,

I am looking for a sponsor for my package "likewise-open".

 * Package name: likewise-open
   Version : 6.1.0.62018-1
   Upstream Author : Scott Salley 
 * URL : likewiseopen.org
 * License : GPL-3
   Section : net

It builds those binary packages:

likewise-open - Authentication services for Active Directory domains
likewise-open-gui - Desktop utility for joining Active Directory domains

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/likewise-open

Alternatively, one can download the package with dget using this
command:

  dget -x
http://mentors.debian.net/debian/pool/main/l/likewise-open/likewise-open_6.1.0.62018-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards,

Richard Sellam


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1318977877.2208.14.camel@acer

Re: RFS: xplanet

[Ruben Molina]

El lun, 03-10-2011 a las 18:13 +0200, Jakub Wilk escribió:
> * Ruben Molina , 2011-10-02, 02:27:
> >  http://mentors.debian.net/package/xplanet
> >
> >Alternatively, one can download the package with dget using this
> >command:
> >
> >  dget -x 
> > http://mentors.debian.net/debian/pool/main/x/xplanet/xplanet_1.2.2-1.dsc
> >
> 
> The new versions removes a few files from /etc. This is all right 
> (assuming that these should have been in /etc in the first place), but 
> note that dpkg won't remove conffiles on upgrade just because they 
> disappeared from .deb. Please see 
> http://wiki.debian.org/DpkgConffileHandling for details.
> 

Thanks.  I restored the files previously removed.

> Your package doesn't respect DEB_BUILD_OPTIONS=noopt. Please consider 
> using dpkg-buildflags to fix this issue. :)
> 

Thanks. I added dpkg-dev to Build-Depends,
included /usr/share/dpkg/buildflags.mk, and addded a
DPKG_EXPORT_BUILDFLAGS=1 in debian/rules
  
> -- 
> Jakub Wilk

Thank you very much!
A new revision was uploaded to the same place.
http://mentors.debian.net/debian/pool/main/x/xplanet/xplanet_1.2.2-1.dsc


Best regards,
Ruben


signature.asc
Description: This is a digitally signed message part