Re: Go (golang) packaging, part 2

[Michael Stapelberg]

Hi Chow,

Chow Loong Jin  writes:
>  1. If software that depends on native packages is installed using "go get"
> or whatever other language-specific package manager, e.g. pip for Python 
> or
> gem for Ruby is installed, there is no way to declare a dependency on
> those. For example, the Python mysql bindings require some MySQL C headers
> which are available in Apt, but you won't know until your pip install run
> fails due to missing headers. After you're done, you move on to your next
> dependency which also fails due to missing headers, and the next, and the
> next…
True.

>  2. If something installed from your language-specific package manager is in a
> path that a Debian package overrides, dpkg is going to barf because it
> doesn't know where those files come from. This of course applies to
> randomly ./configure-ing stuff with --prefix=/usr and running make
> install.
Not going to happen in case of go. “go get” _always_ installes into a
user-defined path with ~/gocode being the recommendation.

>  3. Software packages from Apt cannot declare dependencies against
> language-specific packages, for the same reasons highlighted in
> #1.
Irrelevant argument in our case, as outlined earlier in the discussion.

-- 
Best regards,
Michael


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/x6wquvm66j@midna.zekjur.net

Re: No native packages?

[Ian Campbell]

On Wed, 2013-01-30 at 17:58 +1100, Joey Hess wrote:
> Julien Cristau wrote:
> > > Maybe I forgot the answer, but at least in terms of git and the dpkg
> > > 3.0 (git) format, why can't we simply make use of shallow cloning?
> > 
> > At which point you have lost all the advantages of shipping the
> > repository that Tollef mentioned, as far as I can tell.  You're back to
> > needing an external repository that's kept up to date if you ever need
> > to get at the history.
> 
> You can shallow clone at depth one each ref in the repository, which gets you
> all tags (filter to released versions to avoid needing any further license
> review).

Is it also possible to say "everything in branch A which isn't in branch
B", so that you could include everything from the "debian" branch but
not the "upstream" branch? That might be useful when you aren't 100%
certain of the DFSG freeness of the upstream history, whereas you might
well be happy that the versions incorporated into the debian branch were
ok.

Also, I wonder if it is possible to arrange that having unpacked a git
format source package that the remotes for debian and upstream are
already prepopulated in the repo such that "git remotes update" would
fetch all of the missing history without having to "git remotes add
etc".

Ian.

-- 
Ian Campbell


In Newark the laundromats are open 24 hours a day!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1359535095.10403.14.ca...@dagon.hellion.org.uk

Re: Go (golang) packaging, part 2

[Paul Wise]

On Tue, Jan 29, 2013 at 7:55 PM, Iustin Pop wrote:

> I would add one thing here: Haskell/GHC also (currently) doesn't create
> shared libraries, and instead builds the program statically, but the
> Debian Haskell group still tries to package as best as they can the
> development libraries, for all the reasons above (which are very good
> reasons, IMHO).
>
> So, take this as an example of another language which doesn't do shared
> linking but for which libraries are still packaged in Debian.

Do all Haskell packages add Built-Using headers?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Go (golang) packaging, part 2

[Paul Wise]

On Wed, Jan 30, 2013 at 11:15 AM, Chow Loong Jin wrote:

> Having multiple package managers which don't know about each other on a system
> is evil™ (but in some cases, can be managed properly).

Some integration between dpkg and domain-specific package managers
could be useful. With DEP-11, we could have 'cpan install Foo::Bar'
tell you "Foo::Bar is available in your distribution's package
manager, you can install it with apt-get install libfoo-bar-perl.".

Also, GoboLinux apparently have a more advanced system for integration
between their package manager and others like rubygems/cpan.
Unfortunately the video for the presentation about it at LCA 2010 was
lost, but maybe folks who are interested in this could take a look at
the implementation.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6gj9wo5gdv_exc5y7b-d_kbdse+bfgiyfxj66j-unk...@mail.gmail.com

Re: Go (golang) packaging, part 2

[Thibaut Paumard]

Le 30/01/2013 09:55, Paul Wise a écrit :
> On Wed, Jan 30, 2013 at 11:15 AM, Chow Loong Jin wrote:
> 
>> Having multiple package managers which don't know about each other on a 
>> system
>> is evil™ (but in some cases, can be managed properly).
> 
> Some integration between dpkg and domain-specific package managers
> could be useful. With DEP-11, we could have 'cpan install Foo::Bar'
> tell you "Foo::Bar is available in your distribution's package
> manager, you can install it with apt-get install libfoo-bar-perl.".
> 
> Also, GoboLinux apparently have a more advanced system for integration
> between their package manager and others like rubygems/cpan.
> Unfortunately the video for the presentation about it at LCA 2010 was
> lost, but maybe folks who are interested in this could take a look at
> the implementation.
> 

FWIW, in the case of the Yorick language, I have proposed a developed
with upstream a solution which works reasonably well for the Yorick
community:

 - the yorick internal package manager can install (by default) files
either in /usr/local or in the user home directory;

 - Debian packages for an add-on drop a file somewhere under /usr/lib so
that the yorick internal package manager knows what version of which
add-ons are installed and does not unnecessarily install another version
of an add-on for solving a dependency.

However, the internal package manager only knows what is installed, not
what is available, and dpkg of course has no idea of what the yorick
internal package manager has installed.

Kind regards, Thibaut.



signature.asc
Description: OpenPGP digital signature

Re: No native packages?

[Thomas Goirand]

On 01/29/2013 08:29 AM, Russ Allbery wrote:
> Benjamin Drung  writes:
>
>> Other distributions gain from your extra work. Image the opposite. You
>> want to package a software that is only available in a downstream
>> distribution (e.g. Ubuntu or Linux Mint). Do you prefer to have a
>> non-native format or a native format?
> I'm not sure I see how it makes any difference.  Either way, I would start
> with their package and add Debian packaging files for Debian.  The only
> difference is some minor variation in what commands I run at the very
> start of that process (namely, git-import-dsc for a non-native package
> vs. git-import-orig for a native package).  I have a hard time seeing how
> this choice would make more than thirty seconds of difference to my
> workflow.
>
Well, this happened to me once (a package in Ubuntu), and I asked
upstream to switch to non-native, which he did.

The problem wasn't the work flow, but mainly tracking upstream
version numbers. With a non-native, I can make the difference
between packaging and non-packaging changes just by looking
at the version number in Ubuntu, and I can even make a watch
file to track it for me.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5108e928.10...@debian.org

Re: No native packages?

[Thomas Goirand]

On 01/28/2013 08:59 PM, Gergely Nagy wrote:
> In my opinion, a native package is the wrong choice when your only
>   arguments for it is convenience.
>
>   That's not a strong argument
To the contrary, I think that convenience of one or another
format is the *only* argument.

What you've listed as counter-argument are cases were it isn't
convenient, IMO. And that's why we design packaging tools and
format: so that they are convenient to use. I don't think you
should feel bad because of that kind of laziness. I see it as
an optimization of your work flaw rather than laziness (that's
just different wording for the exact same idea in a more
positive way).

Also, I'm sorry but I don't buy your argument that newbies
would see bad native-package examples and reproduce it. Anyone
who looked a bit into -mentors@l.d.o (and I know you do) will
be able to tell that they do use native packages anyway by
simple mistake and lack of knowledge. Repeatedly, we have to
explain anyway.

Also, I don't understand why you think an NMU becomes awkward
if it deals with a native package. Could you explain?

On 01/28/2013 08:59 PM, Gergely Nagy wrote:
> There are good arguments *for* a native package, as Joey listed, and
> they can work well if upstream == maintainer. But as soon as that
> relationship breaks, for whatever reason, care needs to be taken both
> upstream and both in packaging to ensure a smooth transition. I've seen
> that fail before, though, not with native packages.

I fail to understand why this would be a problem for the 2 native
package I maintain (eg: debpear and openstack-pkg-tools). The
new maintainer would just take over the work (as usual?)...

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5108e999.8030...@debian.org

Re: Go (golang) packaging, part 2

[Tollef Fog Heen]

]] Michael Stapelberg 

> I am not familiar with the Ruby situation, I only know that many Ruby
> developers seem to be very angry at Debian people. Is there a summary of
> the events that I could read?

Debian's rubygems package installed gems to a directory not in $PATH,
meaning most documentation from upstreams on how to use the gems didn't
actually work.  This has since been fixed and newer rubygems install
gems to /usr/local.

[...]

> Sysadmins are not developers and therefore don’t need to learn any new
> commands.

If you believe this is true, you should read up on the whole idea of
devops.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ip6f7zyo@qurzaw.varnish-software.com

Haskell and Built-Using (Was: Go (golang) packaging, part 2)

[Joachim Breitner]

Hi,

Am Mittwoch, den 30.01.2013, 16:52 +0800 schrieb Paul Wise:
> On Tue, Jan 29, 2013 at 7:55 PM, Iustin Pop wrote:
> > I would add one thing here: Haskell/GHC also (currently) doesn't create
> > shared libraries, and instead builds the program statically, but the
> > Debian Haskell group still tries to package as best as they can the
> > development libraries, for all the reasons above (which are very good
> > reasons, IMHO).
> >
> > So, take this as an example of another language which doesn't do shared
> > linking but for which libraries are still packaged in Debian.
> 
> Do all Haskell packages add Built-Using headers?

no, not yet (it is a relatively young addition to the Debian policy). I
have filed a bug against haskell-devscripts to remember that (#699329).

Maybe dh_buildinfo can be extended to output its results as a substvar?
After all, it already collects a (safe approximation) to the data
expected in the Built-Using header:

„This script is designed to be run at build-time, and registers
in a file the list of packages declared as build-time
dependencies, as well as build-essential packages, together with
their versions, as installed in the build machine.“

So all that seems to be missing is to look up the source name and
versions of these packages.

Greetings,
Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: No native packages?

[Thomas Goirand]

On 01/30/2013 04:38 PM, Ian Campbell wrote:
> Also, I wonder if it is possible to arrange that having unpacked a git
> format source package that the remotes for debian and upstream are
> already prepopulated in the repo such that "git remotes update" would
> fetch all of the missing history without having to "git remotes add
> etc".
Yeah, I would love to have this as well. Currently, I do:
./debian/rules get-vcs-source

which adds upstream repository, does a "git fetch upstream" and create
the orig.tar.xz for me.

It's not as nice as what you describe (which I would like to have too),
but it is a nice workaround.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51090cc6.5010...@debian.org

Re: Go (golang) packaging, part 2

[Stefano Zacchiroli]

On Wed, Jan 30, 2013 at 04:52:33PM +0800, Paul Wise wrote:
> On Tue, Jan 29, 2013 at 7:55 PM, Iustin Pop wrote:
> > So, take this as an example of another language which doesn't do shared
> > linking but for which libraries are still packaged in Debian.

FWIW, OCaml is another such example.

> Do all Haskell packages add Built-Using headers?

The OCaml toolchain in Debian doesn't either, #699330 has now been filed
to address that.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Go (golang) packaging, part 2

[Paul Wise]

On Wed, Jan 30, 2013 at 8:07 PM, Stefano Zacchiroli wrote:
> On Wed, Jan 30, 2013 at 04:52:33PM +0800, Paul Wise wrote:
>> On Tue, Jan 29, 2013 at 7:55 PM, Iustin Pop wrote:
>> > So, take this as an example of another language which doesn't do shared
>> > linking but for which libraries are still packaged in Debian.
>
> FWIW, OCaml is another such example.
>
>> Do all Haskell packages add Built-Using headers?
>
> The OCaml toolchain in Debian doesn't either, #699330 has now been filed
> to address that.

Could folks who are familiar with these languages submit bugs against
lintian about detecting packages for these languages that should have
Built-Using but don't?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Go (golang) packaging, part 2

[Marcelo E. Magallon]

On Wed, Jan 30, 2013 at 09:22:12AM +0100, Michael Stapelberg wrote:

> >  3. Software packages from Apt cannot declare dependencies against
> > language-specific packages, for the same reasons highlighted in
> > #1.
> Irrelevant argument in our case, as outlined earlier in the
> discussion.

 That's not quite true.

 If a Debian package uses a service (think database, webserver,
 etc) provided by a laguage-specific package, you cannot declare
 such dependency because Apt doesn't have visibility into the
 other system's information.

 At that point you are in the Rubygems situation, where you have
 to start packaging the language-specific packages for Debian.
 You get into trouble when rubygems sees package-0.0.1 installed
 (and managed by dpkg) and the user installs (via gems)
 application-1.0.0 which declares a dependency on package-0.1.0.

 Now what would you expect to happen?

 rubygems tells dpkg to upgrade package-0.0.1?  What about the
 other stuff managed by dpkg which depends on package-0.0.1?

 rubygems installs package-0.1.0 on its own?  What happens to
 package-0.1.0 managed by dpkg?

 What happens if application-1.0.0 gets packaged for dpkg?
 Should it be handed over from one system to the other?

 Should rubygems packages be hidden from dpkg, let the two
 systems coexist in parallel?

 This situation gets so messy, that some Ruby developers prefer
 to _not_ install ruby via dpkg at all.  And they get mad when
 something in the dependency chain pulls Ruby into the system.

 Marcelo


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130130123335.GA30105@esk

Re: Go (golang) packaging, part 2

[Hilko Bengen]

* Michael Stapelberg:

> Hilko Bengen  writes:
>> This is a pity for those of us who don't really subscribe to "get
>> everything from github as needed" model of distributing software.
> Yes, but at the same time, it makes Go much more consistent across
> multiple platforms.

Apparently, upstream's idea about the role of library code does not
really match the ideas that have been built into Debian and other Linux
distributions. This has happened before: Ruby (1.8, 1.9, ironruby,
rubinius, etc.), Java (we have multiple JRE implementations, Maven),
even Perl (perlbrew, local::lib, etc.) and will happen again.

This in itself is not a problem. We jsut have to figure out where the
diverging ideas are enscribed (I guess: primarily the "go" tool that was
introduced with Go 1.0) and see if we can tweak them to a compromise
that does not cause surprise and confusion.

>> Since one of the stated goals of the Go language and also the golang
>> compiler are fast builds: How about using the Emacs / Common-Lisp /
>> Python approach: Ship only source files in the .deb packages and build
>> object files during post-install?
> What advantage would that have? It won’t change the fact that we will
> only distribute Go libraries for building Debian binary packages.

Architecture: all packages.

>> How does gccgo fit into this picture, apart from the problem that object
>> files generated using gccgo are not compatible with those generated
>> using golang-go?
> I tried to explain that one cannot use gccgo to create dynamically
> linked shared libraries from Go libraries. At least not at the moment.
> All it can do is dynamically linked executables.

I drew a different conclusion from Ian's messages the thread you
mentioned (see the quotes below). Apparently, one *can* build shared
libraries using gccgo, but they are not currently usable using dlopen().
My impression was that this means that regular use of shared libraries
*is* possible with gccgo. And, indeed, my attempts at building
codesearch using gccgo was sucessful -- with the sparse, index, and
regexp packages compiled as shared libraries.

Ian just recommends against using shared libraries pretty much for
"consistency" reasons.

Cheers
-Hilko

* Ian Lance Taylor:
> The gccgo compiler is just like gcc.  To build a shared library:
>
> gccgo -shared -o lib.so file.go
>
> There is no way to use the go tool to build a shared library.

(http://article.gmane.org/gmane.comp.lang.go.general/81686)

* Ian Lance Taylor:
> When using gccgo you can create and use shared libraries.  Loading new
> code via dlopen doesn't really work; the Go initialization code for
> the dlopen'ed shared library will not be run.

(http://article.gmane.org/gmane.comp.lang.go.general/81567)

* Ian Lance Taylor:
> I don't really recommend providing packages as shared libraries even
> when using gccgo, it's not what Go programmers expect.

(http://article.gmane.org/gmane.comp.lang.go.general/81687)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sj5iaj9e@msgid.hilluzination.de

Re: Go (golang) packaging, part 2

[Hilko Bengen]

* Wouter Verhelst:

> On Tue, Jan 29, 2013 at 08:25:38AM +0100, Michael Stapelberg wrote:
>> Hi Hilko,
>> 
>> Hilko Bengen  writes:
>> > This is a pity for those of us who don't really subscribe to "get
>> > everything from github as needed" model of distributing software.
>> Yes, but at the same time, it makes Go much more consistent across
>> multiple platforms.
>
> "consistency across multiple platforms" has been claimed as a benefit
> for allowing "gem update --system" to replace half of the ruby binary
> package, amongst other things. It wasn't a good argument then, and it
> isn't a good argument now.

I think that "Consistency across multiple platforms" can be a useful
argument. But if either upstream's or the distribution's view of How
Things Ought To Work are ignored for the sake of consistency, something
has gone wrong. (Which is my impression of what happened with Ruby.)

> The problem with having a language-specific "get software" command is
> that it introduces yet another way to get at software. There are many
> reasons why that's a bad idea, including, but not limited to: [...]

On the other hand it gives users the power to get things done, without
having to care how they can build "proper" distro packages.

People expect upstream's "get software" command to Just Work, just as
they expect "./configure && make && sudo make install" or "perl
Makefile.PL && make && make test && sudo make install" to Just Work. In
my experience autoconf and perl-based build systems usually don't write
all over the parts of the system that dpkg is responsible for -- they
put their stuff into /usr/local and I can even override that using
documented environment variables or command line parameters.

This is exactly the kind of behavior I would expect when running "go
install" on a Debian system. It should be useful as intended by its
authors but leave certain parts of the system alone that are off-limits
by convention.

Cheers,
-Hilko


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehh2ahtn@msgid.hilluzination.de

Ruby community and Debian (was: Go (golang) packaging, part 2)

[Marc Haber]

On Tue, 29 Jan 2013 22:57:03 +0100, Michael Stapelberg
 wrote:
>Wouter Verhelst  writes:
>> "consistency across multiple platforms" has been claimed as a benefit
>> for allowing "gem update --system" to replace half of the ruby binary
>> package, amongst other things. It wasn't a good argument then, and it
>> isn't a good argument now.
>I am not familiar with the Ruby situation, I only know that many Ruby
>developers seem to be very angry at Debian people. Is there a summary of
>the events that I could read?

In my past experience it is the usual case where and upstream and/or
its community takes at as a personal offense when a user is not using
the latest and greatest software version[1] and does not understand
that one might be mandated to use what a third party (here: Debian)
found fit to freeze for a release a year or more ago.

This attitude can be found upon many upstreams communities (for
example, in Open/LibreOffice and KDE), but is even harder with ruby
since ruby packages seem to be so small that there are so many of
them, that they have something resembling a release process for a
rubygems bundle package, introducing the time lag caused by releases
once for them and once for us, and that our packaging of their softwae
was done in a way that ruby packages are the biggest nightmare to
backport that I have ever seen[2] (gem2deb, 'nuff said).

I do sincerely hope that most of those things will be history when
wheezy is released.

Greetings
Marc

[1] up to "what, you're only using what we released last week? Please
upgrade to our git head and check back.
[2] I think it was between woody and sarge when more and more package
began to rely on a debhelper version that wasn't backportable because
it used a perl language construct that was not available in the past's
stable perl
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1u0xwu-0004cg...@swivel.zugschlus.de

Bug#699347: ITP: stdsyslog -- tool to log a program's output to the system log

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: stdsyslog
  Version : 0.02
  Upstream Author : Peter Pentchev 
* URL : http://devel.ringlet.net/sysutils/stdsyslog/
* License : BSD-2
  Programming Lang: C
  Description : tool to log a program's output to the system log

The stdsyslog utility executes a program, reads everything that it
outputs to a set of file descriptors (by default the standard output and
standard error streams) and logs it to the system log.  Its command-line
options include specifications of the syslog facility and the priorities
that messages on the various file descriptors should be logged as.

--- cut description, start a bit of comment on the reason for this

Yes, I am indeed aware that this may be accomplished using logger(1) and
skillful output-redirection-to-a-program in some shells, but somehow:

  stdsyslog -f local4 sprog args

...strikes me as a bit easier to type than:

  sprog args >(logger -p local4.info) 2>(logger -p local4.err)

...not to mention a bit more portable and also easier to use in
automated program invocations :)

G'luck,
Peter


signature.asc
Description: Digital signature

Re: Go (golang) packaging, part 2

[Michael Stapelberg]

Hi Hilko,

Hilko Bengen  writes:
> I drew a different conclusion from Ian's messages the thread you
> mentioned (see the quotes below). Apparently, one *can* build shared
> libraries using gccgo, but they are not currently usable using dlopen().
> My impression was that this means that regular use of shared libraries
> *is* possible with gccgo. And, indeed, my attempts at building
> codesearch using gccgo was sucessful -- with the sparse, index, and
> regexp packages compiled as shared libraries.
Can you please list the full instructions you did to accomplish building
sparse/index/regexp as a shared library?

I have asked numerous times in various places and nobody could give me
instructions on how to build shared libraries.

-- 
Best regards,
Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/x6txpyn2p9@midna.zekjur.net

Fwd: HBA QLogic en Debian

[Tony Peña]

tranquilo.. metele sin lio
esta en el non-free aqui se usa . es el paquete firmware-qlogic

saludos


El 30 de enero de 2013 10:42, andres cespedes escribió:

Buenos días a tod@s,
>
> Quisiera consultar con todos ustedes si alguno ha llegado a implementar
> Tarjetas HBA QLogic en Debian Stable ya que estuve buscando y pude ver que
> estaban soportadas oficialmente en RedHat y Suse y en algunos blogs vi la
> instalación y el uso de alien , lo cual me
> hace dudar de su correcto funcionamiento. Por ello quisiera tener certeza
> que Debian soporta algún modelo QLogic para poder realizar la compra de
> esta.
>
> Muchas gracias.
>
> --
> Cordialmente,
> Administrador de Redes de Computo
> Linux User Number 497825
>
>


-- 
Antonio Peña
Secure email with PGP 0x8B021001 available at http://pgp.mit.edu
 Fingerprint: 74E6 2974 B090 366D CE71  7BB2 6476 FA09 8B02 1001



-- 
Antonio Peña
Secure email with PGP 0x8B021001 available at http://pgp.mit.edu
 Fingerprint: 74E6 2974 B090 366D CE71  7BB2 6476 FA09 8B02 1001

Re: HBA QLogic en Debian

[Tony Peña]

tranquilo.. metele sin lio
esta en el non-free aqui se usa . es el paquete firmware-qlogic

saludos


El 30 de enero de 2013 10:42, andres cespedes escribió:

> Buenos días a tod@s,
>
> Quisiera consultar con todos ustedes si alguno ha llegado a implementar
> Tarjetas HBA QLogic en Debian Stable ya que estuve buscando y pude ver que
> estaban soportadas oficialmente en RedHat y Suse y en algunos blogs vi la
> instalación y el uso de alien , lo cual me
> hace dudar de su correcto funcionamiento. Por ello quisiera tener certeza
> que Debian soporta algún modelo QLogic para poder realizar la compra de
> esta.
>
> Muchas gracias.
>
> --
> Cordialmente,
> Administrador de Redes de Computo
> Linux User Number 497825
>
>


-- 
Antonio Peña
Secure email with PGP 0x8B021001 available at http://pgp.mit.edu
 Fingerprint: 74E6 2974 B090 366D CE71  7BB2 6476 FA09 8B02 1001

Re: Go (golang) packaging, part 2

[Steve McIntyre]

Marcelo wrote:
>
> This situation gets so messy, that some Ruby developers prefer
> to _not_ install ruby via dpkg at all.  And they get mad when
> something in the dependency chain pulls Ruby into the system.

To be fair, it's similar in reverse. Some Debian developers prefer to
_not_ install Ruby *at all*. Given how utterly awful the internals of
the language implementation are, I'd happily support dropping Ruby
from Debian altogether. Maybe that's just me...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1u0ati-00067a...@mail.einval.com

Re: Bootstrappable Debian - proposal of needed changes

[Wookey]

+++ Michael Biebl [2013-01-25 15:31 +0100]:
> Hi,
> 
> looking over your proposal, I was missing a few things (sorry if this
> was mentioned in one of the replies, I've only skimmed over the thread).
> 
> a/ It's good practice to explicitly enable/disable features via
> configure switches, to have reliable build results in tainted build
> environments. What's the plan to annotate such optional features and
> manage the configure switches in debian/rules?

Build profiles can be viewed as being (to a large degree) a mapping of
configure options into debian packaging. So we get some of the
flexibility that configure provides exposed in the packaging.

We don't want the feature that stuff will get randomly skipped if
support is not found, just the ability to turn some things off for
reasons like bootstraping and crossbuilding, and potentially embedding
and other downstream distro variation. As you say: explicit
enabled/disable is good, because determinsitic builds are wanted.

So a typical rules snippet looks like this: 

ifeq ($(DEB_STAGE),stage1)
DH_OPTIONS += -Nlibdb5.1-sql
  CONFIGURE_SWITCHES += --disable-sql
else
  CONFIGURE_SWITCHES += --enable-sql
fi

so that explicitly sets whether to enable the sql bindings and skips
building the package if not. 

> b/ You mentioned documentation (gtk-doc) as optional build dependency.
> Same packages do not ship the documentation in a separate binary
> package, but as part of the -dev package. Is there an idea to annotate
> optional files in .install files, so dh_install will not fail if files
> are missing when building certain profiles or is there an alternative
> idea how to handle this?

No, there is no plan for this. Anything is possible in rules files. On
some packages we can turn off -fail-missing to avoid build failures.
Ultiately you can do what you like in the packaging, but it helps a
lot if it's neat and not intrusive, which is why -N in
debhelper options is great.

I'm not aware of a nice neat way of using a different .install file,
or concatenating segments of .install files but it would be nice to
have a declarative way of specifying this. It has not been a
significant issue so far, but I expect you are right that there will
places where it's pretty ugly. 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130130165517.gr5...@stoneboat.aleph1.co.uk

Re: Bootstrappable Debian - proposal of needed changes

[Wookey]

+++ Ian Jackson [2013-01-16 13:50 +]:

>  * The concrete syntax in build-depends should not use < > but rather
>reuse the architecture qualification syntax.

I have just been told of a specific reason to avoid using '< >' :
DEP-11 proposes to use '< >' for Component metadata in binary packages 
http://wiki.debian.org/DEP-11


Should this profile stuff be written up as a 'DEP'? 

I think I missed the creation of DEPs somewhere along the way, but I
keep seeing mentions of them. Aha: 'Debian Enhancement Proposals'. I
guess that fits the bill. 


Just today we got patches to give apt (build-dep) profile support using 
-o APT::Build-Profile and sbuild to use that, so the missing piece to
enable
sbuild --host  --profile  _

arrived. Which means that a bootstrap up to a buildd chroot can
consist of nothing but a series of sbuild commands.

(This doesn't quite work yet due to a a few missing bits of
multiarchness, and a few packages that don't cross successfully yet
(most notably perl).

See my update at FOSDEM, and we'll do a summary from this thread in
the not-too-distant.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130130172713.gt5...@stoneboat.aleph1.co.uk

Re: Go (golang) packaging, part 2

[Marc Haber]

On Wed, 30 Jan 2013 16:25:12 +, Steve McIntyre 
wrote:
>To be fair, it's similar in reverse. Some Debian developers prefer to
>_not_ install Ruby *at all*. Given how utterly awful the internals of
>the language implementation are, I'd happily support dropping Ruby
>from Debian altogether. Maybe that's just me...

Ruby is actually a pretty nice language, and it is needed by the two
major Configuration Management tools that are both widely used in
business, puppet and chef.

I have never looked into Ruby's internals, aber I happen to like its
outside.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1u0dsc-0005y5...@swivel.zugschlus.de

Re: Go (golang) packaging, part 2

[Thorsten Glaser]

Paul Wise  debian.org> writes:

> On Wed, Jan 30, 2013 at 11:15 AM, Chow Loong Jin wrote:
> 
> > Having multiple package managers which don't know about each other on a 
system
> > is evil™ (but in some cases, can be managed properly).

Meh, it’s evil, period.

> Some integration between dpkg and domain-specific package managers
> could be useful. With DEP-11, we could have 'cpan install Foo::Bar'
> tell you "Foo::Bar is available in your distribution's package
> manager, you can install it with apt-get install libfoo-bar-perl.".

That would be nice but not need integration, just replacement of
cpan with a small script ;-)

And, of course, having all of CPAN packaged properly. Which comes to…

> Also, GoboLinux apparently have a more advanced system for integration
> between their package manager and others like rubygems/cpan.

… something like that. Not quite. I don’t think it’s worth the pain;
it may be manageable for Perl, and maybe PEAR, and with even bigger
pain maybe even pypi, but not for Ruby and similarily hostile upstreams.

My co-developer (on the MirBSD side) benz has written a script that
almost automates creation of a port (source package) from/for a CPAN:
http://www.slideshare.net/bsiegert/painless-perl-ports-with-cpan2port
(It looks even MacPorts has adopted it!)

Of course, it needs some manual review (and someone’d have to convert
its output to Debian source packages, or merge it into the already
existing dh-make-perl which also somewhat worked when I tried it), but
it would make achieving this goal possible (and let running dpkg require
128 MiB of RAM or so, to fit the list of packages into it, I guess, but
even those Amigas have that).

bye,
//mirabilos (with his Synergy hat)
PS: Steve is not alone in thinking to kick it…


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20130130t221150-...@post.gmane.org

Re: Ruby community and Debian

[Thorsten Glaser]

Marc Haber  zugschlus.de> writes:

> In my past experience it is the usual case where and upstream and/or
> its community takes at as a personal offense when a user is not using
> the latest and greatest software version[1] and does not understand

I think the Ruby case involved more:

“What, you’re not running version x of the dependency y but a newer
one? Ignore the fact that version x is vulnerable, because that’s
the one you *must* be using for my code! Ah, and no, the dependency
of package z of version x+1 of package y is not a problem, because
with out cool package manager you can install them in parallel!”

(Somewhat remembering and paraphrasing what I read on the Planet.)

bye,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20130130t221904-...@post.gmane.org

Re: Go (golang) packaging, part 2

[Russ Allbery]

Thorsten Glaser  writes:

> My co-developer (on the MirBSD side) benz has written a script that
> almost automates creation of a port (source package) from/for a CPAN:
> http://www.slideshare.net/bsiegert/painless-perl-ports-with-cpan2port
> (It looks even MacPorts has adopted it!)

> Of course, it needs some manual review (and someone’d have to convert
> its output to Debian source packages, or merge it into the already
> existing dh-make-perl which also somewhat worked when I tried it), but
> it would make achieving this goal possible (and let running dpkg require
> 128 MiB of RAM or so, to fit the list of packages into it, I guess, but
> even those Amigas have that).

Do you think there's something substantial missing from the existing
Debian packaging of Perl modules?  I'm quite happy with what Debian is
doing already and am somewhat dubious there is any point in changing
anything.  Most of what's available in CPAN that isn't already packaged is
either new or quite obscure, and much of what's available but obscure
probably *shouldn't* be packaged: it's buggy, abandoned, an inferior
version of something that's already packaged, or otherwise just not of
general interest.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fw1iz79o@windlord.stanford.edu

Re: Issue 9 (golang) packaging, part 2

[Thorsten Glaser]

Russ Allbery  debian.org> writes:

> Do you think there's something substantial missing from the existing
> Debian packaging of Perl modules?  I'm quite happy with what Debian is

(Oops. Forgot to fix a spelling mistake in the Subject in my
first reply. It’s not Go!) (Hello GMane, no I was *not* top-posting…
but apparently I have to move this paragraph down.)

I’m not versed enough in the ways of Perl to be able to comment
on this. I meant no slight in any way to the existing packages.
I was just speculating on missing things that need to be packaged…

> anything.  Most of what's available in CPAN that isn't already packaged is
> either new or quite obscure, and much of what's available but obscure
> probably *shouldn't* be packaged: it's buggy, abandoned, an inferior
> version of something that's already packaged, or otherwise just not of
> general interest.

… but apparently, there’s no need to do anything more ;-)

That is, of course, even better. Then, just use the packaged things.

(Side note: not that I like PHP even one bit, but at least it doesn’t
make actually packaging its thingies hard. With my FusionForge developer
hat on, we generally have everything needed already in Debian or can
easily add it, so that we can really say what the DDs in the upstream
team prefer: if it’s not in Debian, it doesn’t exist.)

bye,
//mirabilos

PS: Please do not call golang “Go”, it’s a hostile name take-over that
could have easily been fixed (instead of becoming hostile; I’m sure
it was just an oversight initially) when Issue 9 was filed. I follow
the tradition to call the language “Issue 9” in reference to both that
bug and Plan 9 instead, but “golang” is probably fine. Or “go-nuts”…


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20130130t224109-...@post.gmane.org

Re: Go (golang) packaging, part 2

[Игорь Пашев]

2013/1/30 Marc Haber :
> On Wed, 30 Jan 2013 16:25:12 +, Steve McIntyre 
> wrote:
>>To be fair, it's similar in reverse. Some Debian developers prefer to
>>_not_ install Ruby *at all*. Given how utterly awful the internals of
>>the language implementation are, I'd happily support dropping Ruby
>>from Debian altogether. Maybe that's just me...
>
> Ruby is actually a pretty nice language, and it is needed by the two
> major Configuration Management tools that are both widely used in
> business, puppet and chef.

Don't forget vim-addon-manager!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CALL-Q8z3oV07uzY8TO9fwspykacihOTmspB79V3yV0JOYQ=m...@mail.gmail.com

Re: Bug#698656: ITP: adequate -- Debian package quality testing tool

[Jakub Wilk]

* Jakub Wilk , 2013-01-21, 22:17:

adequate checks quality of installed packages.

can it be used on chroots without being installed in the chroot?
like
  adequate --root=/some/chroot mypkg


You can't do that currently, and I'm afraid it won't be easy to 
implement.


adequate 0.4 has the --root option, but it's implemented by 
chroot(2)ing, so it's only slightly better than this hack:



cat /usr/bin/adequate | chroot /some/chroot perl - mypkg


--
Jakub Wilk


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

Re: Go (golang) packaging, part 2

[Lennart Sorensen]

On Wed, Jan 30, 2013 at 09:16:59PM +, Thorsten Glaser wrote:
> Meh, it’s evil, period.

Absolutely.  As a user I have a nice package management system that I
know how to use and which works well.  I don't need another one.

It is not the job of a language developer to invent yet another bloody
package distribution and installation system.  Just because windows
doesn't have a decent way to handle software installations doesn't mean
other systems don't know how to do it well.

> That would be nice but not need integration, just replacement of
> cpan with a small script ;-)
> 
> And, of course, having all of CPAN packaged properly. Which comes to…

I think having the useful bits done is fine, and dh-make-perl is pretty
good for the few times you want to try something that isn't already
packaged (and probably just long enough to find out it wasn't worth
using in the first place).

> … something like that. Not quite. I don’t think it’s worth the pain;
> it may be manageable for Perl, and maybe PEAR, and with even bigger
> pain maybe even pypi, but not for Ruby and similarily hostile upstreams.

Much as I like PHP, I really hate PEAR.  I don't want another add on
system to manage.

> My co-developer (on the MirBSD side) benz has written a script that
> almost automates creation of a port (source package) from/for a CPAN:
> http://www.slideshare.net/bsiegert/painless-perl-ports-with-cpan2port
> (It looks even MacPorts has adopted it!)
> 
> Of course, it needs some manual review (and someone’d have to convert
> its output to Debian source packages, or merge it into the already
> existing dh-make-perl which also somewhat worked when I tried it), but
> it would make achieving this goal possible (and let running dpkg require
> 128 MiB of RAM or so, to fit the list of packages into it, I guess, but
> even those Amigas have that).

Poor old Amigas.  Not that any of mine have enough CPU to run linux. :(

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130130234635.ga1...@csclub.uwaterloo.ca

Re: Go (golang) packaging, part 2

[Russ Allbery]

"Lennart Sorensen"  writes:

> Absolutely.  As a user I have a nice package management system that I
> know how to use and which works well.  I don't need another one.

> It is not the job of a language developer to invent yet another bloody
> package distribution and installation system.  Just because windows
> doesn't have a decent way to handle software installations doesn't mean
> other systems don't know how to do it well.

My upstream experience is that people generally use the package management
properties of things like CPAN in two main cases: when using operating
systems with deficient package management or scope of packages, or when
using old systems that can't be updated for some reason.

CPAN is hugely popular with Solaris admins, for example, because good luck
finding real Solaris packages of most of the things you care about.  Red
Hat is similar; a lot of common Perl modules are packaged, but far fewer
than are packaged for Debian, and it's common to need something that isn't
part of the base Red Hat distribution.

The problem with the general feeling that they're inferior versions of
real package management is that the above use cases mean that the
packaging components of something like CPAN aren't ever going to go away,
since upstream will continue to support users on those platforms, or users
who are on lenny and refuse to upgrade for some reason.  And since those
components exist and people get used to using them to get their jobs done
on Red Hat, they'll naturally use them on Debian as well without being
aware there are better alternatives.  Or when they're on squeeze and want
to do some sort of cutting-edge development.

Thankfully, at least with Perl, they co-exist fairly well, although people
get bitten by having outdated versions of things installed in /usr/local
from an old CPAN run that should have been, but weren't, supplanted by
better versions available through the package manager.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gmuxlfy@windlord.stanford.edu

Re: Go (golang) packaging, part 2

[Chow Loong Jin]

On 31/01/2013 05:16, Thorsten Glaser wrote:
>> On Wed, Jan 30, 2013 at 11:15 AM, Chow Loong Jin wrote:
>> > 
>>> > > Having multiple package managers which don't know about each other on a 
> system
>>> > > is evil™ (but in some cases, can be managed properly).
> Meh, it’s evil, period.
> 

Well, really, the manageable case I was talking about was pip/easy_install
inside a Python virtualenv, which is basically a Python installation that is
kept completely distinct from the system's installation and doesn't touch
anything dpkg is supposed to be managing.

It's useful for installing crap from PyPI in a more or less standard,
distro-agnostic manner.

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Bug#699403: ITP: xorg-gtest -- X.Org dummy testing environment for Google Test

[Stephen M. Webb]

Package: wnpp
Severity: wishlist
Owner: "Stephen M. Webb" 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: xorg-gtest
  Version : 0.7.0
  Upstream Author : Peter Hutterer 
* URL : http://cgit.freedesktop.org/xorg/test/xorg-gtest/
* License : MIT/X
  Programming Lang: C++
  Description : X.Org dummy testing environment for Google Test

Provides a Google test environment for starting and stopping a dummy X server
for headless testing purposes.



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJRCddvAAoJEAoP+EW32zQnyhkQAJ91an5owjjHurpDghmbHj/c
LxtvkIUXMW8aLV9HoWVhuOufTz7pjFwWj6gcbrDPWLgspAuEq6tpt84JoFv3IW27
9NCaBnpzJz+GhO74MkmcJdYwLk/IC74JfiTRXO64AeDlESTBlBnLcx8SI+kSZdx+
izqoyhCg7zsgTSaPSuAeSZq0l3iOD4+XvUIpd24Ji9WyIVVezqGdylM8r5tdKydH
r2wwSf9Qd5LJYXe6R85HWZzZ/Y1Zu6i9iqeNKKh5LIjDNHs7mW0P23QMSNO3yt+F
vtK+KN0+9z+8si5pEbj20g+tDDpBoy2a9h1q5zUhbF1I7YlDKRz8GZhRQa39X+uS
dvuvLiybonIzabw7GaJDiYMVT7JzGGoWpO5rbofwFqXnFQIJk7ew0uI0hJxjmXqn
LB8wrmRezEvbKlB9GW6YTWrGd/gxC66M/W3sMTmhvYYQoXONgkoY96Z6S1W243Fj
SXukw1nvUCjjL8tGL08fLBS3Q6kYbN8y9eFisZ7QSwK05kj1EvosdY/Jlmk8Aj0/
UkK8JFTD0Ec83ngIEk6Qkuk20W+USIgGQYTSKpi8GJKrcmMS6ldpgIzFyFR+kBTm
83lCfalOLptJBP6t2JktYrVFPl98t/WIsHKYDfg5C/d9kg9t+lBtCNSFWcc08Ayp
Ogc2zfyTU9H4qHAr8huM
=02CA
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130131023111.1688.6434.reportbug@localhost6.localdomain6

bash readline

[Jack Andrews]

hi dd,

i really like the readline in bash - it seems bash is "vi complete" in vi mode.

now, i haven't looked closely, but i think the good vi mode is a patch
on (bash?) readline in debian?
in centos, i can't "df;" and delete up to next semicolon.

but on ubu^H^H^Hdebian, rlwrap uses the vanilla readline and it's
really annoying that i can't get the same line editing features with
rlwrap (and, i expect, readline).

what are my options?  patch readline?


ta, jack.


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

Re: Ruby community and Debian

[Antonio Terceiro]

On Wed, Jan 30, 2013 at 09:21:08PM +, Thorsten Glaser wrote:
> Marc Haber  zugschlus.de> writes:
> 
> > In my past experience it is the usual case where and upstream and/or
> > its community takes at as a personal offense when a user is not using
> > the latest and greatest software version[1] and does not understand
> 
> I think the Ruby case involved more:
> 
> “What, you’re not running version x of the dependency y but a newer
> one? Ignore the fact that version x is vulnerable, because that’s
> the one you *must* be using for my code! Ah, and no, the dependency
> of package z of version x+1 of package y is not a problem, because
> with out cool package manager you can install them in parallel!”

That was a bit of both issue, but that happens in pretty much every
language community out there.

I just tried installing some cool thing in Perl, and installing it from
CPAN into $HOME blew up because of incompatibilities with some Perl
package installed via dpkg, and could only test the said package when I
tried installing it from CPAN in a clean chroot.

There is always impedance mismatch between those who want to build
stable, dependable, predictable systems and those who want to live in
the bleeding edge, and as said elsewhere in this thread, that's not
exclusive to the Ruby people.

IMO the noise caused by "the Ruby situation" was amplified by the
concurrent development of two different of factors:

- a lot of leading (and very vocal) Ruby developers were using a system
  that had no proper package management (MacOS X), so they didn't care
  enough to understand the requirements "from our side". But the Ruby
  packages in Debian implemented those requirements.

- that also happened during the boom of Ruby development outside of
  Japan -- skyrocketed by the boom of Rails -- where everything was new
  and everyone was experimenting like crazy. That led to the
  lack-of-stables-API and let's-break-our-reverse-dependencies
  bandwagons.

Today, the situation is improving from our side, if not by discussing
the relationship, at least by writing the proper code. With Rubygems
moving into the core -- what makes sense, because we cannot fight
against the fact that several users of the language won't have proper
package managers provided by their OS, we had to deal with it.  As a
sort of technology preview, in Wheezy one will be able to have Rubygems
detect dpkg-installed packages¹.

¹ http://packages.debian.org/rubygems-integration

Also, switching the default Ruby version on a per-user/pre-project² or
even on a per-system² basis was made easier.

² http://packages.debian.org/rbenv
³ update-alternatives --config ruby

From the Ruby community side the situation is a lot better. You will
even see the occasional "don't you break a stable API" rant within the
Ruby community.

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Re: Go (golang) packaging, part 2

[Jean-Christophe Dubacq]

On 30/01/2013 22:23, Игорь Пашев wrote:
> 2013/1/30 Marc Haber :
>> On Wed, 30 Jan 2013 16:25:12 +, Steve McIntyre 
>> wrote:
>>> To be fair, it's similar in reverse. Some Debian developers prefer to
>>> _not_ install Ruby *at all*. Given how utterly awful the internals of
>>> the language implementation are, I'd happily support dropping Ruby
>> >from Debian altogether. Maybe that's just me...
>>
>> Ruby is actually a pretty nice language, and it is needed by the two
>> major Configuration Management tools that are both widely used in
>> business, puppet and chef.
> 
> Don't forget vim-addon-manager!
> 
> 
Don't forget package.el for emacs!

-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature

Bug#699411: ITP: python-statsdpy -- event based statsd implementation

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-statsdpy
  Version : 0.0.10
  Upstream Author : Florian Hines 
* URL : https://github.com/pandemicsyn/statsdpy
* License : Presumably Apache-2 (currently checking with upstream)
  Programming Lang: Python
  Description : event based statsd implementation

 Statsdpy is an event based statsd implementation written in Python using
 eventlet with support for reporting to graphite using the pickle protocol.
 Statsdpy supports counters, timers, gauges, combined events and sampling.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130131064522.6564.71393.report...@buzig.gplhost.com

Re: Bug#699411: ITP: python-statsdpy -- event based statsd implementation

[Thomas Goirand]

On 01/31/2013 02:45 PM, Thomas Goirand wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Thomas Goirand 
>
> * Package name: python-statsdpy
>   Version : 0.0.10
>   Upstream Author : Florian Hines 
> * URL : https://github.com/pandemicsyn/statsdpy
> * License : Presumably Apache-2 (currently checking with upstream)
>   Programming Lang: Python
>   Description : event based statsd implementation
>
>  Statsdpy is an event based statsd implementation written in Python using
>  eventlet with support for reporting to graphite using the pickle protocol.
>  Statsdpy supports counters, timers, gauges, combined events and sampling.
>
>
FYI, I think I'll call the package statsdpy and not python-statspy,
because that's not a python module, but a server thing...

Still pending words from upstream about licensing though.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/510a21df.6010...@debian.org