Re: Knowing the release names in advance
Hi Thomas and everybody, and « bonne année » ! It seems to me that the main technical arguments advocating predictable or sortable release names have been given, so I think that the next step would be to make sure that they get to the right ears at the right time. While this discussion on -devel may help to strenghten your proposition, I have the impression that the current contributors to the discussion are not the persons who will decide. How about a DEP to organise the discussion ? It would help for the pros and cons to be recorded in a synthethic way in a document easy to find, which will be very useful if the persons in charge estimate that currently it is a development that has a lower priority than focusing on Wheezy's release. http://dep.debian.net/deps/dep0/ Cheers, -- Charles -- 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/20130101082136.ga23...@falafel.plessy.net
[RFC] Go (golang) packaging
Hi, I am co-maintainer of the golang package and spent a few hours on trying to figure out how to best create Debian packages for libraries and programs which are implemented in Go. I have documented my thoughts, conclusions and example packaging on: http://wiki.debian.org/MichaelStapelberg/GoPackaging Essentially, I propose that /usr/lib/gocode is used on Debian to store the “src” and “pkg” folders which contain the .go files and compiled versions (respectively) of Go libraries. Furthermore, the package names should be e.g. “golang-codesearch” for the library code.google.com/p/codesearch (and of course just “codesearch” for the binaries). To make go(1) find libraries when compiling, one normally sets the environment variable $GOPATH to ~/gocode or similar. I propose to patch Go in Debian so that it always appends /usr/lib/gocode when reading the list of paths from $GOPATH. Any feedback is appreciated. Please read the wiki page before you comment, it contains more rationale than this email. Thanks. -- 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/x68v8dow53@midna.zekjur.net
Re: [RFC] Go (golang) packaging
On Tue, Jan 1, 2013 at 9:44 PM, Michael Stapelberg wrote: > Any feedback is appreciated. Please read the wiki page before you > comment, it contains more rationale than this email. Thanks. Since golang apparently doesn't support dynamic linking, every package built against a golang library will have to include an appropriate Built-Using header. You will probably also want a lintian test for this to autoreject anything without this header. Upstream should switch to using the GNU triplet instead of linux_arm, which is clearly not unique enough. Is it possible to: Support dynamic linking? That would avoid the whole rebuild-the-world thing that statically-linked languages have. Not require the full source code for libraries? C and other libraries only require the interface 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/caktje6h1ijosmhd1o23ou9qvhv_jjp3ocvobxjdwxxfqsk1...@mail.gmail.com
Re: Knowing the release names in advance
On 01/01/2013 04:21 PM, Charles Plessy wrote: > Hi Thomas and everybody, and « bonne année » ! > > It seems to me that the main technical arguments advocating predictable or > sortable release names have been given, so I think that the next step would be > to make sure that they get to the right ears at the right time. While this > discussion on -devel may help to strenghten your proposition, I have the > impression that the current contributors to the discussion are not the persons > who will decide. > > How about a DEP to organise the discussion ? It would help for the pros and > cons to be recorded in a synthethic way in a document easy to find, which will > be very useful if the persons in charge estimate that currently it is a > development that has a lower priority than focusing on Wheezy's release. > > http://dep.debian.net/deps/dep0/ > > Cheers, > Hi Charles! Maybe it's a bit overkill to do a DEP just for that no? Otherwise, I can make a sum-up of what has been said in the list, if you see fit. (Though probably, it would be best to find someone to do it that has a less strong point of view on the mater, and with better English skills than me...) Also, I do like the fact that the release team decides for the name, I think that's a very nice reward for their huge work. However, I think everyone in the project should have equal rights as to discuss and decide *when* we need such names (and, as always, best is to have a consensus). 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/50e2f209.9080...@debian.org
Re: [RFC] Go (golang) packaging
Hi Paul, > Since golang apparently doesn't support dynamic linking, every package > built against a golang library will have to include an appropriate > Built-Using header. You will probably also want a lintian test for > this to autoreject anything without this header. Thanks, I was not aware of this yet. Will have a closer look and integrate it into my Wiki page. > Upstream should switch to using the GNU triplet instead of linux_arm, > which is clearly not unique enough. I think so, too. Not sure if they think that’s doable at this point, will ask them. > Is it possible to: > > Support dynamic linking? That would avoid the whole rebuild-the-world > thing that statically-linked languages have. Only when not using the “official” compiler (gc), e.g. gccgo has support for dynamic linking. > Not require the full source code for libraries? C and other libraries > only require the interface headers. AFAIK not, but I will add this to the list of questions I want to ask on the Go mailing lists. -- 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/x6fw2kop7h@midna.zekjur.net
Re: [RFC] Go (golang) packaging
On 1 January 2013 15:44, Michael Stapelberg wrote: > Hi, > > I am co-maintainer of the golang package and spent a few hours on trying > to figure out how to best create Debian packages for libraries and > programs which are implemented in Go. > > I have documented my thoughts, conclusions and example packaging on: > http://wiki.debian.org/MichaelStapelberg/GoPackaging > > Essentially, I propose that /usr/lib/gocode is used on Debian to store > the “src” and “pkg” folders which contain the .go files and compiled > versions (respectively) of Go libraries. > What about multiarch? /usr/lib/gocode/ for sources /usr/lib/$triplet/gocode/ for compiled versions This assumes that sources are identical across all architectures. Regards, Dmitrijs. -- 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/canbhluhh_c35qr3hqkha2apkxhps-9rsqmgqbrqufx8xwt4...@mail.gmail.com
Re: [RFC] Go (golang) packaging
Hi Dmitrijs, Dmitrijs Ledkovs writes: > What about multiarch? I tried to address this on the wiki page, see http://wiki.debian.org/MichaelStapelberg/GoPackaging#Multi-Arch.2Fcross-compiling Essentially, I currently believe that multi-arch does not make sense for go, since we are only dealing with static binaries. E.g. to run an i386 program, you don’t need any additional libraries: $ file helloworld helloworld: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped $ uname -a Linux midna 3.5.0 #1 SMP Sun Jul 22 11:15:13 CEST 2012 x86_64 GNU/Linux $ ./helloworld hello > /usr/lib/gocode/ for sources > /usr/lib/$triplet/gocode/ for compiled versions Go’s directory layout already includes the architecture, see http://wiki.debian.org/MichaelStapelberg/GoPackaging#Resulting_package_file_lists I have a feeling that you have not actually read the wiki page :-). -- 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/x6d2xookwt@midna.zekjur.net
Re: [RFC] Go (golang) packaging
On 01/01/13 16:14, Michael Stapelberg wrote: > Hi Paul, >> Support dynamic linking? That would avoid the whole rebuild-the-world >> thing that statically-linked languages have. > Only when not using the “official” compiler (gc), e.g. gccgo has support > for dynamic linking. Where does gccgo look for Go sources (src)? Where does gccgo look for Go "static libraries" (pkg)? Where does gccgo look for Go dynamic libraries? (Presumably the same places where gcc looks for C dynamic libraries?) >> Not require the full source code for libraries? C and other libraries >> only require the interface headers. > AFAIK not, but I will add this to the list of questions I want to ask on > the Go mailing lists. If a significant amount of code is going to be written in Go, it would be useful to understand the classes of source change that do and don't constitute an API break (well-understood for C, somewhat well-understood for C++), and the classes of source change that do and don't constitute an ABI break for gccgo. Michael additionally wrote: > I propose to patch > Go in Debian so that it always appends /usr/lib/gocode when reading > the list of paths from $GOPATH. Add /usr/local/lib/[$TUPLE/]gocode as "more important than" /usr/lib/[$TUPLE/]gocode, perhaps? That's how /usr/local usually works in Debian. > Essentially, I currently believe that multi-arch does not make sense > for go, since we are only dealing with static binaries. For multi-arch runtime libraries (in-scope for wheezy), sure, it's not useful because there are no runtime libraries. For multi-arch headers and development libraries (not formally in-scope for wheezy, but some simpler packages already support it, and it's likely to be a goal for jessie), it's useful to be multiarch so an i386/amd64 system can have both golang-libhello:amd64 and golang-libhello:i386, so that it can build both helloworld:amd64 and helloworld:i386. If golang has its own partial solution for multiarch but that solution is actually insufficient for what we need (linux_arm for both armel and armhf, etc.) and upstream are unwilling to make it sufficient, then I don't see anything particularly wrong with /usr/lib/arm-linux-gnueabi/golang/linux_arm/libhello.a. Sure, it's redundant, but it works... [Dmitrijs wrote:] >> /usr/lib/gocode/ for sources /usr/[local/]share/gocode if they're arch-indep, surely? Or if they *can* vary by arch but usually don't (like C headers), /usr/local/lib/$TUPLE/gocode:/usr/local/share/gocode:/usr/lib/$TUPLE/gocode:/usr/share/gocode or something? > Furthermore, the package names should be e.g. “golang-codesearch” for > the library code.google.com/p/codesearch (and of course just > “codesearch” for the binaries). Should the package with the "headers" and "static library" be golang-codesearch-dev or something, in the hope that when Go grows the ability to build dynamic libraries, the dynamic libraries can be called golang-codesearch? > For cross-compiling, it doesn’t matter which pre-compiled packages > you have installed (e.g. linux_amd64) because the .go source files > are shipped, too. go build will just re-compile the libraries then: How "cheap" is recompiling everything? If it's sufficiently cheap, you could just ship complete source and ignore the "static libraries" entirely; or if it isn't, you'll benefit from proper multiarch. S -- 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/50e33e9c.4000...@debian.org
Re: [RFC] Go (golang) packaging
Hi Simon, Simon McVittie writes: > Where does gccgo look for Go sources (src)? > Where does gccgo look for Go "static libraries" (pkg)? > Where does gccgo look for Go dynamic libraries? (Presumably the same > places where gcc looks for C dynamic libraries?) I can’t really answer these questions in depth, but the way I usually invoke it is by using go(1)’s -compiler option, in which case the lookup works the same as with the “original” go compiler. I’m not sure whether Debian should support gccgo at all. Will ask the Go mailing lists on what they think. > Michael additionally wrote: >> I propose to patch >> Go in Debian so that it always appends /usr/lib/gocode when reading >> the list of paths from $GOPATH. > > Add /usr/local/lib/[$TUPLE/]gocode as "more important than" > /usr/lib/[$TUPLE/]gocode, perhaps? That's how /usr/local usually works > in Debian. Mentioning /usr/local is a good point, but I’m not sure whether it’s really a good idea: in the Go community, setting $GOPATH to a directory within your home directory (e.g. ~/gocode) is normal and what everyone uses. To install a third-party library, you just “go get” its URL, e.g. go get code.google.com/p/codesearch Which will then download the library to ~/gocode/src/code.google.com/p/codesearch. Nobody will have libraries in /usr/local, because there is no facility (no Makefiles) to install them there. The local directory is rather specified by the user in $GOPATH — that is the idiomatic way. > For multi-arch headers and development libraries (not formally in-scope > for wheezy, but some simpler packages already support it, and it's > likely to be a goal for jessie), it's useful to be multiarch so an > i386/amd64 system can have both golang-libhello:amd64 and > golang-libhello:i386, so that it can build both helloworld:amd64 and > helloworld:i386. You cannot currently cross-compile an i386 binary on an amd64 host with the Go packages we have in Debian. I consider this a separate issue. Essentially, when we have a golang-go package that contains a version of the compiler which has been built to support cross-compiling for a particular architecture (say golang-go-i386), you can cross-compile using the source code of the libraries, a pre-compiled version is not necessary. To state this clearly: The benefit of shipping the pkg/ files in Debian packages at all is to avoid re-compilation every time the user builds code that depends on the library. We could just as well leave out the pkg/ files and everything would still work — just slower. > Should the package with the "headers" and "static library" be > golang-codesearch-dev or something, in the hope that when Go grows the > ability to build dynamic libraries, the dynamic libraries can be called > golang-codesearch? Yeah, I suppose we should name them -dev. AFAICT, there is some movement into the shared library direction, see https://groups.google.com/d/msg/golang-nuts/VS-Pt38097Q/MXMRFc7G26IJ https://codereview.appspot.com/6926049/ > How "cheap" is recompiling everything? If it's sufficiently cheap, you > could just ship complete source and ignore the "static libraries" > entirely; or if it isn't, you'll benefit from proper multiarch. See above. We could ship without the static libraries, but having them speeds up compilation noticably in big projects. -- 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/x6a9ssocx8@midna.zekjur.net
Bug#697137: RFA: whohas -- query multiple distributions' package archives
Package: wnpp Severity: normal I request adoption of whohas, a command line tool that allows you to query several package collections at once. Regrettably I no longer have the time nor perl-fu to properly look after this tool (though I will do so where possible for Wheezy). It needs care from time to time to keep up with distribution changes, but more importantly it needs someone to drive upstream development forwards, either through patches or a fork. Upstream is pleasant but often unresponsive, though there are occasional upstream releases. There is no upstream repository, you just get a tarball from time to time. I have the packaging and upstream history in git. I'd like to see it go to a good home, it's a handy tool even though I don't use it so much any more. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature
Re: Knowing the release names in advance
Le Tue, Jan 01, 2013 at 10:26:17PM +0800, Thomas Goirand a écrit : > > Maybe it's a bit overkill to do a DEP just for that no? For simple propositions, a DEP is not much more than giving a number to a wiki page, and keeping track if the proposition is under discussion, accepted or rejected. The goal is not to make the proposition more formal, but to provide a frame that helps to limit the repetition of the same arguments accross years. The DEP index at http://dep.debian.net/ is a ikiwiki page managed with Subversion, that is straightforward to modify. Every Debian Developer should have write access to it (svn+ssh://svn.debian.org/svn/dep/web/index.mdwn). In case of problems, do not hesitate to contact the DEP admins (https://lists.alioth.debian.org/mailman/listinfo/dep-plumbing). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20130101221806.gb15...@falafel.plessy.net
Bug#697145: ITP: wit -- manipulate Wii and GameCube ISO images and WBFS containers
Package: wnpp Severity: wishlist Owner: Michael Stapelberg * Package name: wit Version : 2.10a Upstream Author : Dirk Clemens * URL : http://wit.wiimm.de/ * License : GPL-2+ Programming Lang: C Description : manipulate Wii and GameCube ISO images and WBFS containers Wiimms ISO Tools is a set of command line tools to manipulate Wii and GameCube ISO images and WBFS containers. The toolset consists of the following tools: . wit (Wiimms ISO Tool): This is the main ISO manipulation tool : It can list, analyze, verify, convert, split, join, patch, mix, extract, compose, rename and compare Wii and GameCube discs. It can create and dump different other Wii file formats. . wwt (Wiimms WBFS Tool): This is the main WBFS manipulation tool (WBFS manager) : It can create, check, repair, verify and clone WBFS files and partitions. It can list, add, extract, remove, rename and recover ISO images as part of a WBFS. . wdf (Wiimms WDF Tool): wdf is a support tool for WDF, WIA and CISO archives. It convert (pack and unpack), compare and dump WDF, WIA (dump and cat only) and CISO archives. The default command depends on the program file name (see command descriptions). Usual names are wdf, unwdf, wdf-cat, wdf-cmp and wdf-dump (with or without minus signs). »wdf +CAT« replaces the old tool wdf-cat and »wdf +DUMP« the old tool wdf-dump. . wfuse (Wiimms FUSE Tool): Mount a Wii or GameCube image or a WBFS file or partition to a mount point using FUSE (Filesystem in USErspace). Use 'wfuse --umount mountdir' for unmounting. -- 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/20130101223556.30811.5878.report...@midna.zekjur.net
ITP: sphinx -- Speech recognition tool base
Hello, I've just noticed that sphinx2 was orphaned some time ago, and thus unfortunately dropped from Wheezy. I'd like to reupload it for jessie, here are the ITPs of the 3 modules: - Forwarded message from Samuel Thibault - Package: wnpp Severity: wishlist Owner: Samuel Thibault * Package name: sphinxbase Version : 0.8 Upstream Author : Evandro Gouvêa Arthur Chan Mosur Ravishankar Yitao Sun David Huggins-Daines * URL : http://cmusphinx.sourceforge.net/ * License : BSD Programming Lang: C Description : Speech recognition tool Sphinx is a real-time, speaker-independent speech recognition system. This contains the common base code. - End forwarded message - - Forwarded message from Samuel Thibault - Package: wnpp Severity: wishlist Owner: Samuel Thibault * Package name: pocketsphinx Version : 0.8 Upstream Author : Fil Alleva Robert Brennan Hsiao-wen Hon Ravishankar Mosur Eric Thayer Kevin Lenzo Alan W Black Evandro Gouvea David Huggins-Daines * URL : http://cmusphinx.sourceforge.net/ * License : BSD Programming Lang: C Description : Speech recognition tool Sphinx is a real-time, speaker-independent speech recognition system. This contains the end-user tools. - End forwarded message - - Forwarded message from Samuel Thibault - Package: wnpp Severity: wishlist Owner: Samuel Thibault * Package name: sphinxtrain Version : 1.0.8 Upstream Author : Alan W Black (a...@cs.cmu.edu) Evandro Gouvea (egouv...@cs.cmu.edu) Ricky Houghton (ricky.hough...@cs.cmu.edu) David Huggins-Daines (dhugg...@cs.cmu.edu) Kevin Lenzo (le...@cs.cmu.edu) Ravi Mosur Long Qin (l...@cs.cmu.edu) Rita Singh (rsin...@cs.cmu.edu) Eric Thayer * URL : http://cmusphinx.sourceforge.net/ * License : BSD Programming Lang: C Description : Speech recognition tool Sphinx is a real-time, speaker-independent speech recognition system. This contains the training tools. - End forwarded message - -- Samuel je sens venir la fonte 14 pour le rapport -+- #ens-mim -+- -- 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/20130101234630.gc29...@type.youpi.perso.aquilenet.fr
Re: [RFC] Go (golang) packaging
On Wed, Jan 2, 2013 at 12:14 AM, Michael Stapelberg wrote: > Only when not using the “official” compiler (gc), e.g. gccgo has support > for dynamic linking. Then we should use gccgo until the official compiler supports this. > AFAIK not, but I will add this to the list of questions I want to ask on > the Go mailing lists. Ok, please let us know about the results. -- 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/CAKTje6G3V1NCPyKnZt7By=sydcn_qh-kwnbsveenjkkhmuc...@mail.gmail.com
Re: [RFC] Go (golang) packaging
On Tue, Jan 1, 2013 at 6:54 PM, Paul Wise wrote: > On Wed, Jan 2, 2013 at 12:14 AM, Michael Stapelberg wrote: > > > Only when not using the “official” compiler (gc), e.g. gccgo has support > > for dynamic linking. > > Then we should use gccgo until the official compiler supports this. > go also doesn't support building as a shared library, because #1 the go scheduler would have to have differn't bootstrapping code hooked up (for gccgo it would be in libgo) and #2 go uses split stacks[1]. But when it doesn't support building as a shared library, it will probably be done with gccgo first. > > > AFAIK not, but I will add this to the list of questions I want to ask on > > the Go mailing lists. > > Ok, please let us know about the results. > Henceforth when a go program depends on a go library, those go libraries are ALWAYS compiled in statically. Static linking causes many problems for distributions like Debian, and therefore this presents a significant hurdle to quality packaging of go in Debian. Source-only distribution is perhaps possible, but then AFAIK go library writers are not necessarily as careful as C library writers to maintain source compatibility. [1] http://gcc.gnu.org/wiki/SplitStacks > > -Shawn Landden
Re: [RFC] Go (golang) packaging
* Michael Stapelberg [130101 14:45]: > Furthermore, the package names should be e.g. “golang-codesearch” for > the library code.google.com/p/codesearch Please also consider "codesearch-golang". Especially with longer package names not everything can show the full name so the beginning should be the more important information. > (and of course just “codesearch” for the binaries). I assume s/binaries/sources/? And I'd suggest to just not policy the source package names at all (as there really is no "one rule who fits them all" and there is no reason to have a rule there at all). Another question: Have you considered asking for a archive Section for those packages? I guess with no special section yet all those packages would be section libdevel as they are for static linking only, wouldn't they? Bernhard R. Link -- 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/20130102071555.ga3...@client.brlink.eu
Re: [RFC] Go (golang) packaging
On Wed, Jan 2, 2013 at 3:15 PM, Bernhard R. Link wrote: > Another question: Have you considered asking for a archive Section for > those packages? I guess with no special section yet all those packages > would be section libdevel as they are for static linking only, wouldn't > they? http://wiki.debian.org/MichaelStapelberg/GoPackaging#TODO -- 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/CAKTje6FiyuoNc-GyaoO=jnygh2prp2pasb7qvkhh5whqp+q...@mail.gmail.com
