Re: autoconf 2.72 to unstable?
Hi Gürkan, On Fri, Jun 14, 2024 at 12:03 PM Gürkan Myczko wrote: > > Have never done mass bug filings, any easy way, preferably something > copy pastable, > non-interactive. Concerning erlang, I've already prepared an upload which builds with autoconf 1.72, so you may skip it when reporting bugs. Cheers! -- Sergei Golovan
Bug#1065256: ITP: node-fontsource-merriweather -- Merriweather font self-hostable for Node.js
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: node-fontsource-merriweather Version : 5.0.11 Upstream Contact: Ayuhito * URL : https://github.com/fontsource/font-files * License : MIT, SIL-OFL-1.1 Programming Lang: CSS Description : Merriweather font self-hostable for Node.js The node-fontsource-merriweather package contains the Merriweather font and CSS files suitable for self-hosting with Node.js. The NPM package with this font is used by the elixir-ex-doc [1] documentation generator. In fact, elixir-ex-doc sources include precompiled assets (set of templates, Javascript libraries and fonts, see [2]), including Merriweather, but I reckon it's better to rebuild the assets from their sources. The Merriweather NPM package is maintained upstream as a part of a huge monorepository (with more than 1600 fonts), so I decided not to package all of them for Debian, but only those which are to be used by elixir-ex-doc. The package will be maintained by me personally. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795495 [2] https://github.com/elixir-lang/ex_doc/tree/main/formatters/html/dist
Bug#1065254: ITP: node-fontsource-lato -- Lato font self-hostable for Node.js
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: node-fontsource-lato Version : 5.0.18 Upstream Contact: Ayuhito * URL : https://github.com/fontsource/font-files * License : MIT, SIL-OFL-1.1 Programming Lang: CSS Description : Lato font self-hostable for Node.js The node-fontsource-lato package contains the Lato font and CSS files suitable for self-hosting with Node.js. The NPM package with this font is used by the elixir-ex-doc [1] documentation generator. In fact, elixir-ex-doc sources include precompiled assets (set of templates, Javascript libraries and fonts, see [2]), including Lato, but I reckon it's better to rebuild the assets from their sources. The Lato NPM package is maintained upstream as a part of a huge monorepository (with more than 1600 fonts), so I decided not to package all of them for Debian, but only those which are to be used by elixir-ex-doc. The package will be maintained by me personally. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795495 [2] https://github.com/elixir-lang/ex_doc/tree/main/formatters/html/dist
Bug#1065253: ITP: node-fontsource-inconsolata -- Inconsolata font self-hostable for Node.js
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: node-fontsource-inconsolata Version : 5.0.16 Upstream Contact: Ayuhito * URL : https://github.com/fontsource/font-files * License : MIT, SIL-OFL-1.1 Programming Lang: CSS Description : Inconsolata font self-hostable for Node.js The node-fontsource-inconsolata package contains the Inconsolata font and CSS files suitable for self-hosting with Node.js. The NPM package with this font is used by the elixir-ex-doc [1] documentation generator. In fact, elixir-ex-doc sources include precompiled assets (set of templates, Javascript libraries and fonts, see [2]), including Inconsolata, but I reckon it's better to rebuild the assets from their sources. The Inconsolata NPM package is maintained upstream as a part of a huge monorepository (with more than 1600 fonts), so I decided not to package all of them for Debian, but only those which are to be used by elixir-ex-doc. The package will be maintained by me personally. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795495 [2] https://github.com/elixir-lang/ex_doc/tree/main/formatters/html/dist
Bug#1064822: ITP: elixir-makeup-erlang -- Makeup lexer for the Erlang language
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: elixir-makeup-erlang Version : 0.1.3 Upstream Contact: Tiago Barroso * URL : https://github.com/elixir-makeup/makeup_erlang * License : BSD-2-clause Programming Lang: Elixir Description : Makeup lexer for the Erlang language A lexer to highlight Erlang code using Makeup, which is a syntax highlighter written in Elixir. This package is a dependency for elixir-ex-doc, which is used by the Erlang upstream developers to generate documentaion from sources (starting from Erlang 27, which is to be released and uploaded to Debian soon). The package will be maintained by the Erlang team.
Bug#1064821: ITP: elixir-makeup-elixir -- Makeup lexer for the Elixir language
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: elixir-makeup-elixir Version : 0.16.1 Upstream Contact: Tiago Barroso * URL : https://github.com/elixir-makeup/makeup_elixir * License : BSD-2-clause Programming Lang: Elixir Description : Makeup lexer for the Elixir language A lexer to highlight Elixir code using Makeup, which is a syntax highlighter written in Elixir. This package is a dependency for elixir-ex-doc, which is used by the Erlang upstream developers to generate documentation from sources (starting from Erlang 27, which is to be released and uploaded to Debian soon). The package will be maintained by the Erlang team.
Bug#1064820: ITP: elixir-makeup -- Generic syntax highlighter written in Elixir
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: elixir-makeup Version : 1.1.1 Upstream Contact: Tiago Barroso * URL : https://github.com/elixir-makeup/makeup * License : BSD-2-clause Programming Lang: Elixir Description : Generic syntax highlighter written in Elixir Makeup is a generic syntax highlighter written in Elixir. It is suitable for use in code hosting, forums, wikis or other applications that need to prettify source code similar to Pygments. This package is a dependency of elixir-ex-doc which is now used by Erlang developers to generate documentaion from sources (starting from Erlang 27, which is to be released and uploaded to Debian soon). It will be maintained by the Erlang team.
Bug#1064819: ITP: elixir-makeup-c -- Makeup lexer for the C language
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: elixir-makeup-c Version : 0.1.1 Upstream Contact: Boyd Multerer * URL : https://github.com/elixir-makeup/makeup_c * License : BSD-2-clause Programming Lang: Elixir Description : Makeup lexer for the C language A lexer to highlight C code using Makeup, which is a syntax highlighter written in Elixir. This package is a dependency for elixir-ex-doc which is now used by Erlang upstream to generate documentation from sources (starting from Erlang 27, which is to be uploaded to Debian soon). The package will be maintained by the Erlang team.
Bug#1064817: ITP: elixir-earmark-parser -- Pure Elixir Markdown Parser
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: elixir-earmark-parser Version : 1.4.39 Upstream Contact: Robert Dober , Dave Thomas * URL : https://github.com/RobertDober/earmark_parser * License : Apache-2.0 Programming Lang: Elixir Description : Pure Elixir Markdown Parser EarmarkParser is a Markdown parser used by Earmark, which is an Elixir library intended for converting Markdown to HTML. It is a dependency for elixir-ex-doc documentation generator, which is used in Erlang to build documetation from sources starting from Erlang 27. The package will be maintained by the Erlang team.
Bug#1057700: ITP: tk9.0 -- Tk toolkit for Tcl and X11, v9.0
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: tk9.0 Version : 9.0b1rc1 Upstream Contact: Tcl Core Team * URL : https://www.tcl-lang.org/ * License : BSD Programming Lang: C, Tcl Description : Tk toolkit for Tcl and X11, v9.0 Tk is a cross-platform graphical toolkit which provides the Motif look-and-feel and is implemented using the Tcl scripting language. This is a new upstream release with some potential incompatibilities with the older ones, so it's as usual packaged separately. The package will be maintained under Debian Tcl/Tk team. Version 9.0 is in pre-beta stage yet, so I'm planning to upload this package to experimental.
Re: using uscan with Fossil SCM
Hi Romain,
On Sat, May 1, 2021 at 1:26 AM Romain Porte wrote:
>
> Hi fellow Debianites,
>
> I am currently in the process of packaging grammalecte [1] that relies
> on the Fossil SCM [2]. However on the taglist page [3] the links are
> directing to Fossil HTML pages, but not .tar.xz files. When browsing out
> the 2.1.2 tag HTML page [4], one has to follow the "check-in" link [5]
> before being able to download an archive from the resulting page [6].
With Fossil you don't have to know the exact artifact hash in order to download
tagged revisions. Knowing the tag name is sufficient. You can construct the
download URL yourself given the tag name. The following debian/watch seems
to work, it uses filenamemangle and downloadurlmangle to manualy specify
the filename and URL to download:
=
version=4
opts="searchmode=plain, \
filenamemangle=s//grammalecte-$1.tar.gz/,
\
downloadurlmangle=s//http:\/\/code.grammalecte.net:8080\/tarball\/Grammalecte.tar.gz?r=v$1/"
\
http://code.grammalecte.net:8080/taglist \
=====
Cheers!
--
Sergei Golovan
Bug#963700: ITP: lua-readline -- GNU readline bindings for the Lua language
Package: wnpp Severity: wishlist Owner: Sergei Golovan * Package name: lua-readline Version : 2.7 Upstream Author : Peter Billam * URL : https://pjb.com.au/comp/lua/readline.html * License : Expat (the same as for Lua itself) Programming Lang: C, Lua Description : GNU readline bindings for the Lua language This Lua module offers a simple calling interface to the GNU Readline/History Library. This package will become a dependency for the Prosody XMPP server strting from the next 0.12 release. It will be maintained under the Debian Lua Team umbrella.
Bug#946670: ITP: tcl9.0 -- Tcl (the Tool Command Language) v9.0
Package: wnpp Severity: wishlist Owner: Sergei Golovan * Package name: tcl9.0 Version : 9.0a1 Upstream Author : Tcl Core Team * URL : http://www.tcl.tk/ * License : (BSD) Programming Lang: (C, Tcl) Description : Tcl (the Tool Command Language) v9.0 Tcl is a powerful, easy-to-use, embeddable, cross-platform interpreted scripting language. It's a new upstream release with major incompatibilities with the earlier ones (8.X), so it has to be packaged separately. The package will be maintained under the Debian Tcl/Tk team. Version 9.0 is in alpha stage yet, so I intend to upload it to experimental at the moment.
Bug#932316: ITP: lua5.4 -- lightweight, embeddable scripting language
Package: wnpp Severity: wishlist Owner: Sergei Golovan * Package name: lua5.4 Version : 5.4.0-alpha Upstream Author : Lua Team * URL : https://www.lua.org/ * License : Expat Programming Lang: C Description : lightweight, embeddable scripting language It's the next major release of Lua. Currently only alpha version is released upstream, so I intend to keep it in experimental for a while. The maintenance will take place under the Lua Team umbrella. -- Sergei Golovan
Bug#892157: ITP: itk4 -- [incr Tk] OOP extension version 4 for Tk
Package: wnpp Severity: wishlist Owner: Sergei Golovan * Package name: itk4 Version : 4.1.0 Upstream Author : Tcl Core Team * URL : http://incrtcl.sourceforge.net/itk/index.html * License : BSD (the same as Tcl) Programming Lang: C, Tcl Description : [incr Tk] OOP extension version 4 for Tk This is the next major version of [incr Tk] - a companion of [incr Tcl] (an OOP extension for Tcl) suitable for building complex widgets. It will replace the itk3 package after all the reverse dependencies switch to it. The package is to be maintained under Debian Tcl/Tk team.
Bug#892155: ITP: itcl4 -- [incr Tcl] OOP extension for Tcl
Package: wnpp Severity: wishlist Owner: Sergei Golovan * Package name: itcl4 Version : 4.1.1 Upstream Author : Tcl Core Team * URL : http://incrtcl.sourceforge.net/itcl/ * License : BSD (the same as for Tcl itself) Programming Lang: C, Tcl Description : [incr Tcl] OOP extension for Tcl This is the next major version of the [incr Tcl] Tcl extension with object oriented paragigm support. It will eventually replace the itcl3 package. This package is planned to be maintained under the Debian Tcl/Tk team.
Fading out Tcl/Tk 8.5 from Debian
Hi fellow developers, Since Tcl/Tk 8.5 is currently at its End of Life (see [1]) I would like to start a campaign on removing it from Debian. There's a wiki page [2] with all binary packages which depend on Tcl/Tk 8.5 directly or indirectly, and with all packages which build-depend on tcl8.5-dev or tk8.5-dev. (Not all of them need patching, it's still a rough list) I'm planning to start filing bugs with suggestions on how to switch to Tcl/Tk 8.6 or may be to the currently default Tcl/Tk (which is now 8.6, but 8.7 is coming soon with fewer incompatibilities with respect to 8.6 than for 8.6 against 8.5). As for now the bugs severity will be 'important', but I plan to bump it to 'serious' before the buster's release. If there are comments or suggestions on what should I do before starting filing the bugs, please tell. [1] https://core.tcl.tk/tcl/wiki?name=Index [2] https://wiki.debian.org/Teams/DebianTclTk/TclTk85Removal Cheers! -- Sergei Golovan
Bug#886982: ITP: tk8.7 -- Tk toolkit for Tcl and X11, v8.7
Package: wnpp Severity: wishlist Owner: Sergei Golovan * Package name: tk8.7 Version : 8.7a1 Upstream Author : Tcl Core Team * URL : http://www.tcl.tk/ * License : BSD Programming Lang: C, Tcl Description : Tk toolkit for Tcl and X11, v8.7 Tk is a cross-platform graphical toolkit which provides the Motif look-and-feel and is implemented using the Tcl scripting language. This is a new upstream release with some potential incompatibilities with the older ones, so it's as usual packaged separately. The package will be maintained under Debian Tcl/Tk team. Version 8.7 is in alpha stage yet, so I'm planning to upload this package to experimental.
Bug#886981: ITP: tcl8.7 -- Tcl (the Tool Command Language) v8.7
Package: wnpp Severity: wishlist Owner: Sergei Golovan * Package name: tcl8.7 Version : 8.7a1 Upstream Author : Tcl Core Team * URL : http://www.tcl.tk/ * License : BSD Programming Lang: C, Tcl Description : Tcl (the Tool Command Language) v8.7 Tcl is a powerful, easy-to-use, embeddable, cross-platform interpreted scripting language. It's a new upstream release with some incompatibilities with the earlier ones (8.6, 8.5), so it's traditionally packaged separately. The package will be maintained under the Debian Tcl/Tk team. Version 8.7 is in alpha stage yet, so I intend to upload it to experimental at the moment.
Re: auto-removal and alternative dependencies
Hi! On Thu, Dec 8, 2016 at 3:22 PM, Emilio Pozuelo Monfort wrote: > On 08/12/16 13:02, Daniel Pocock wrote: >> I have two packages that depend on: nagios3 | icinga >> >> nagios3 is being removed[1], but icinga[2] is still available, so why >> can't my packages continue to list nagios3 as a possible dependency for >> the convenience of those people who continue to use it? > > I would need to check the code, but the auto-remover probably checks the first > dependency and ignores the rest (just like e.g. wanna-build and britney). So > you > could just swap them and make that: icinga | nagios3. Looks like there's another consequence of this: libtk-img and itk3 are now marked for autoremoval from stretch because they depend on the virtual package libtk which is provided by libtk8.4, libtk8.5 and libtk8.6, and likely only the first dependency in lexicographic order is checked. Should I report a bug? Where? Cheers! -- Sergei Golovan
Revised plans from the Tcl/Tk team
Hi fellow developers! Following the previous discussion [1] in these lists, I'd like to present a slightly changed plans for Tcl/Tk in jessie. First of all, thank you all for comments and suggestions, especially for keeping me from doing something non-constructive (like renaming the development packages from tcl8.5-dev to libtcl8.5-dev). We've almost finished reporting bugs, so the amount of work becomes more clear. The progress is being tracked in [2], [3] and [4]. Let me remind you the revised tasks and prospective changes in Tcl/Tk packages. 1) Dropping Tcl/Tk 8.4. There are 21 packages which build-depend on Tcl/Tk 8.4 and 7 additional binary packages which depend on Tcl/Tk 8.4 for now. Also, 6 packages depend on tk8.4|wish, so they will work after the change as they are. 2) Dropping alternatives for /usr/bin/tclsh and /usr/bin/wish, and use plain symlinks shipped in the tcl and tk packages respectively. There are 12 packages which build-depend on Tcl/Tk 8.5 and use tclsh or wish during the build process (I haven't finished to analyze all build logs yet, so there might be a few more). Also, there's 13 binary packages which use tclsh or wish in scripts in /usr/bin. 3) Multiarchifying Tcl/Tk. Appears that there are 9 packages which cannot find Tcl/Tk libraries in the /usr/lib/ location during the build process (more than I'd expected, but still a one-digit number). 4) Updating the default Tcl/Tk version to 8.6. There are 10 packages which build process breaks because of not-always-backward-compatible changes in Tcl/Tk 8.6. The most frequent problem is using a long time deprecated fields in the Tcl_Interp structure. They were hidden in 8.6, but can be made visible by defining a macro (which is suitable for a short term fix or for dead projects, but not for a long term solution). 5) There are a few other breaks (an example is blt which parses libtcl's shlibs file by hands, so switching to symbols breaks it). We've already reported almost all these issues, mostly with patches. Looks like all the tasks are fairly doable, so I'd propose the following plan: 1) Bump severity of bugs concerning Tcl/Tk 8.4 (see [2]) to serious. 2) Perform NMU if necessary to fix them. 3) Drop Tcl/Tk 8.4 from the Debian archive. 4) Bump severity of bugs concerning removing /usr/bin/tclsh and /usr/bin/wish (see [3]) to serious. 5) Perform NMU if necessary to fix them. 6) Upload new tcl/tk8.5, tcl/tk8.6, tcl/tk (upgrade default to 8.6). 7) Help fixing build failures from [4] and other problems which definitely will show up. [1] http://lists.debian.org/debian-devel/2013/09/msg00500.html [2] https://wiki.debian.org/Teams/DebianTclTk/TclTk84Removal [3] https://wiki.debian.org/Teams/DebianTclTk/DropTclshWishAlternatives [4] https://wiki.debian.org/Teams/DebianTclTk/UpgradeDefaultTclTkTo86 Cheers! -- Sergei Golovan -- 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/caoq2pxeee8saukbp8jou3qvsesb8f0xd_ezmb8cme+jmyyn...@mail.gmail.com
Re: Upcoming changes in Tcl/Tk packaging
Hi Matthias, On Wed, Sep 25, 2013 at 5:12 PM, Matthias Klose wrote: > Am 25.09.2013 14:52, schrieb Sergei Golovan: >> >> There are 17 packages which build when 8.5 is the default version but >> fail to build >> after switching to 8.6. Most of them are patchable, though I'm not >> sure if they will >> work properly after that. > > would be nice to track these in some place. I've created two pages on the wiki: https://wiki.debian.org/Teams/DebianTclTk/UpgradeDefaultTclTkTo86 and https://wiki.debian.org/Teams/DebianTclTk/TclTk84Removal and started to report FTBFS bugs (with fixes if I can propose a fix). The first page contains more than just tracking upgrade to 8.6. It contains FTBFS due to various reasons, sometimes pretty unexpected. Cheers! -- Sergei Golovan -- 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/CAOq2pXGPHJx=fyq3he8ftazz8kc14fyk4p1k+e1bequl15_...@mail.gmail.com
Re: Upcoming changes in Tcl/Tk packaging
Hi Wookey,
On Wed, Sep 25, 2013 at 7:04 PM, Wookey wrote:
> +++ Sergei Golovan [2013-09-25 12:25 +0400]:
>> Hi fellow developers,
>>
>> I would like to introduce a few significant changes into Debian Tcl/Tk
>> packages.
>
> Thank you for doing this work, and for this clear summary.
>
>> 1. Multiarchifying Tcl/Tk. This means splitting out the libtcl8.5
>> package with libraries moved to /usr/lib/ and with common Tcl
>> code in /usr/share/tcltk/tcl8.5.
>>
>
>> Any questions, comments. Anything I've missed?
>
> Yes, the other multiarch-related change needed in tcl is making
> tclConfig.sh and tkConfig.sh cross-friendly.
>
> This is not strictly tied to the above changes, but because
> tclConfig.sh is arch-specific, and revdeps are affected by the other
> changes it makes sense to fix this now whilst we are making a mess.
>
> The existing (ubuntu) patches add a compat script at
> /usr/lib/tcl8.6/tclConfig.sh which calls
> /usr/lib/${DEB_HOST_MULTIARCH}/tcl8.6/tclConfig.sh
Yes, I used changes from Ubuntu as a basis, so exactly this compat
script is included into (lib)tcl8.6-dev package.
>
> which enables backwards compatibility and will usually work, so long
> as whatever called it really did want the host-arch version. Fixing
> rdeps to actually call the arch wanted during the build is better
> because it will always work. Providing -tclConfig.sh links
> would be consistent with the way this has been made config-system
> friendly and distro-agnostic in other packages.
What's -tclConfig.sh links and how are they better then just
/usr/lib//tcl8.6/tclConfig.sh?
>
> Migrating tcl to use pkgconfig instead would remove the need for this
> to be arch-specific, which is an even better solution, but I don't
> know how enthused upstream is about doing that.
I'm not sure if it's an option. There're tons of existing extensions
which use tclConfig.sh, many of them are abandoned and will never
migrate to pkgconfig, but they are still useful.
>
> So have you included this change too? Doing so does not require
> revdeps changes so long as they only need the host arch version. We
> could force them to actually choose the one they want by not including
> the compatibility layer, but that seems like too big a hammer. There
> are 246 packages that build-dep on {tcl|tk}(8.[456])*-dev
I've included the compatibility script. You're right, requiring all
the packages to use /usr/lib//tcl8.6/tclConfig.sh is
impractical.
Cheers!
--
Sergei Golovan
--
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/CAOq2pXEKuw=yewtmjfqxchq9hpmpeobgtssbrs2km1g8sbm...@mail.gmail.com
Re: Upcoming changes in Tcl/Tk packaging
Hi Matthias, On Wed, Sep 25, 2013 at 1:39 PM, Matthias Klose wrote: > Am 25.09.2013 10:25, schrieb Sergei Golovan: >> Hi fellow developers, >> >> I would like to introduce a few significant changes into Debian Tcl/Tk >> packages. Some of them have quite significant impact on their reverse >> dependencies which will need a transition, I think. The proposed >> changes are already in the experimental branch, so anyone could try >> and break things. >> >> The changes are (I use Tcl/Tk 8.5 as an example, but the same changes >> are applied to 8.4 and 8.6 as well): > > would it be possible to drop 8.4 first? There are about 30 packages left which unconditionally depend on tcl8.4 or tk8.4. We have to do some research and find how to port them to 8.5 or 8.6. > >> 1. Multiarchifying Tcl/Tk. This means splitting out the libtcl8.5 >> package with libraries moved to /usr/lib/ and with common Tcl >> code in /usr/share/tcltk/tcl8.5. The same is for Tk (libtk8.5 is the >> new package name). This change doesn't cause any impact on the reverse >> dependent packages. > > Is this just the shared library, or -dev and -dbg packages as well? Will it > be > possible to cross-build Tcl/Tk extensions? -dev packages contain static libraries which go to the multiarch directory too. Includes are the same for all arches. As for -dbg, I never tried to build them. Though I wasn't quite right when said that multiarchifying is not intrusive. In fact, a few packages (3 at least) FTBFS because they try to find libtcl8.5.so in /usr/lib. > >> Also, current stable upstream Tcl/Tk version is 8.6.1, but I wouldn't >> like to switch to it now because it'll complicate the process of >> removing alternatives a lot. But later I'd like to have another >> transition (switching to 8.6 as default Tcl/Tk version). > > Do you have numbers what will break with 8.6? There are 17 packages which build when 8.5 is the default version but fail to build after switching to 8.6. Most of them are patchable, though I'm not sure if they will work properly after that. -- Sergei Golovan -- 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/caoq2pxhjkrojuuaot1byntj2+85owihzrmp04xcdw_nati8...@mail.gmail.com
Re: Upcoming changes in Tcl/Tk packaging
Hi Cyril, On Wed, Sep 25, 2013 at 1:38 PM, Cyril Brulebois wrote: > Hi Sergei, > > (replying to the first part only since it strikes me) > > Sergei Golovan (2013-09-25): >> 2. Renaming tcl8.5-dev and tk8.5-dev into libtcl8.5-dev and >> libtk8.5-dev respectively (the latter packages still provide the >> former as virtual packages to break as few packages as it could be). >> This change is not strictly necessary, but the new names follow the >> common convention for development libraries. > > please don't. Renaming without having a reason is a bad idea, that means > creating a lot of work for no benefit. (Besides having to adjust a few > packages in unstable, which you mentioned already, imagine someone > backporting her packages to previous releases, she gets to carry a diff > because of “cosmetics”, which isn't nice.) You are right. The old names tcl8.5-dev and tk8.5-dev are not pretty given they accompany libtcl8.5 and libtk8.5, but fully replacing them by libtcl8.5-dev and libtk8.5-dev will take a lot of work. Okay, I'll return the old names for the -dev packages. > >> 3. Renaming tcl-dev and tk-dev into libtcl-dev and libtk-dev. Since >> too many packages have versioned build-dependencies on tcl-dev or >> tk-dev, I chose to retain tcl-dev and tk-dev packages (as >> meta-packages which depend on libtcl-dev and libtk-dev). Switching to >> libtcl-dev and libtk-dev can be gradual. Would adding a lintian >> warning discouraging to use the old names possible? > > Same as above: creating work for no actual benefit. Nice package name is a benefit to me, though it might not exceed the costs of moving. > > If that was triggered by some lintian warnings, just override them and > be done with it. Lintian isn't here to generate work. I meant a lintian warning which softly encourages to switch to libtcl-dev from tcl-dev. -- Sergei Golovan -- 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/caoq2pxf-wpfndlb53rseubndw_j9xosj0rjcf8xvtt+tkjz...@mail.gmail.com
Upcoming changes in Tcl/Tk packaging
Hi fellow developers, I would like to introduce a few significant changes into Debian Tcl/Tk packages. Some of them have quite significant impact on their reverse dependencies which will need a transition, I think. The proposed changes are already in the experimental branch, so anyone could try and break things. The changes are (I use Tcl/Tk 8.5 as an example, but the same changes are applied to 8.4 and 8.6 as well): 1. Multiarchifying Tcl/Tk. This means splitting out the libtcl8.5 package with libraries moved to /usr/lib/ and with common Tcl code in /usr/share/tcltk/tcl8.5. The same is for Tk (libtk8.5 is the new package name). This change doesn't cause any impact on the reverse dependent packages. 2. Renaming tcl8.5-dev and tk8.5-dev into libtcl8.5-dev and libtk8.5-dev respectively (the latter packages still provide the former as virtual packages to break as few packages as it could be). This change is not strictly necessary, but the new names follow the common convention for development libraries. Only 4 packages break because of this change. They either have versioned depends or build-depends on tcl8.*-dev or tk8.*-dev. (cableswig, netgen, tix, tkdesk). 3. Renaming tcl-dev and tk-dev into libtcl-dev and libtk-dev. Since too many packages have versioned build-dependencies on tcl-dev or tk-dev, I chose to retain tcl-dev and tk-dev packages (as meta-packages which depend on libtcl-dev and libtk-dev). Switching to libtcl-dev and libtk-dev can be gradual. Would adding a lintian warning discouraging to use the old names possible? And the last but the most significant change: 4. Dropping /usr/bin/tclsh and /usr/bin/wish alternatives. Currently, any tcl8.* package offers /usr/bin/tclsh and any tk8.* package gives /usr/bin/wish via alternatives mechanism. I want to drop it and provide /usr/bin/tclsh and /usr/bin/wish as symlinks in tcl and tk packages respectively (similar to python packages). This change is very invasive. It makes about 40 packages FTBFS, and I don't know how many packages will break silently. The problem is that currently packages which depend on tcl8.5 (or tcl8.4, or tcl8.6) assumes that /usr/bin/tclsh exists (and the same is for tk8.5 and /usr/bin/wish). Though for many of them (those which depend on tcl8.5 or tk8.5) the fix will be trivial - to change dependency to tcl or tk, which provide /usr/bin/tclsh and /usr/bin/wish symlinks. These changes will require revision for the Debian Tcl/Tk policy. The new draft isn't published yet. It's still preparing in SVN: svn+ssh://svn.debian.org/svn/pkg-tcltk/policy/trunk (Is there anonymous access to it?) So, I'd like to start reporting bugs on found FTBFS and #!/usr/bin/tclsh or #!/usr/bin/wish shebangs without tcl or tk dependencies. Then I'll upload the changed Tcl/Tk packages to unstable. Also, current stable upstream Tcl/Tk version is 8.6.1, but I wouldn't like to switch to it now because it'll complicate the process of removing alternatives a lot. But later I'd like to have another transition (switching to 8.6 as default Tcl/Tk version). Any questions, comments. Anything I've missed? Cheers! -- Sergei Golovan -- 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/caoq2pxggdhzwm0z8dgd3zqoaepjdtofbk9l29b13vrdu_f0...@mail.gmail.com
Re: multiarch and interpreters/runtimes
Hi! On Thu, Apr 18, 2013 at 9:56 PM, Andrew Shadura wrote: > > Hello, > > > By the way, have you contacted Sergei on this? I saw the bugreports and I'm planning to start working on them after wheezy release. > > > Personally, I'm not yet convinced about this interpreter > > multiarchification, but hey Debian is a Universal OS ;-) and I don't > > see any reason to not do this. > > Well, it may make sense, but really there will be not many people > running foreign interpreters at all, in my opinion. > > Is there a wiki page on Tcl/Tk multiarchification? Not yet. > > To Sergei (added to Cc): I'd like to join the effort in packaging Tcl/Tk > and stuff, as I said before; but as you've been the most active person > on the team for quite some time I'm a bit hesitant about interrupting > the process by committing things :) I guess, we need some > co-ordination; also, in my opinion, the mailing list needs revival. There's pkg-tcltk-de...@lists.alioth.debian.org mailing list for that. Cheers! -- Sergei Golovan -- 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/caoq2pxeaan9odnwhwtrtoaacsotabvwh3ppwmgurjmrkk9o...@mail.gmail.com
Re: Creating symlinks to manpages
Hi! On Mon, Feb 11, 2013 at 5:14 PM, Arno Töll wrote: > Hi, > > On 11.02.2013 14:00, Игорь Пашев wrote: >> If you look at dh_installman, you will see that it replaces such dummy pages >> with symlinks. > > Which solves your problem, doesn't it? And no, I don't think that's ugly > - it's a pragmatic workaround. No, it doesn't. The original problem was that it's hard to create symlink if you don't know the manpage section (dh_installman takes section from the header inside manpages and doesn't use the filename). To create the 'source' manpage (.so file.section) one has to know the section. It's the same problem. Cheers! -- Sergei Golovan -- 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/caoq2pxgrwnyrgaq_9zng5fnot2njr021ovu2o7kigzxpmwd...@mail.gmail.com
Bug#674247: ITP: tktray -- Freedesktop system tray icon support for Tcl/Tk on X11
Package: wnpp Severity: wishlist Owner: Sergei Golovan * Package name: tktray Version : 1.3.9 Upstream Author : Anton Kovalenko * URL : http://code.google.com/p/tktray/ * License : BSD Programming Lang: C Description : Freedesktop system tray icon support for Tcl/Tk on X11 Tktray is an extension that is able to create system tray icons. It follows http://www.freedesktop.org specifications. This protocol is supported by modern versions of KDE and GNOME panels, and by some other panel-like application. -- 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/20120524041053.26572.33295.report...@jupiter.golovan.home
Bug#674166: ITP: tkinspect -- Tk application inspector for developing in Tcl
Package: wnpp Severity: wishlist Owner: Sergei Golovan * Package name: tkinspect Version : 5.1.6p10 Upstream Author : Sam Shen , John Robert Loverso , Pat Thoyts * URL : http://tkcon.sourceforge.net/ * License : Public domain. Includes parts with BSD license Programming Lang: Tcl/Tk Description : Tk application inspector for developing in Tcl Tkinspect is a tool to permit one to inspect the contents of a separate running Tk application. It has views for the variables, arrays, procedures and other objects in the inspectee and communicates using the Tk send or tcllib comm commands. -- 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/20120523144037.25209.81145.report...@jupiter.golovan.home
Bug#670539: general: error in shell script: 0208: value too great for base (error token is "0208")
Hi Steffen. On Thu, Apr 26, 2012 at 5:58 PM, Steffen Erlecke wrote: > ../t.sh: line 15: 0208: value too great for base (error token is "0208") > ../t.sh: line 16: 0209: value too great for base (error Error: XXX: > Test-Error > /* RESULT END */ > > The questions now are: What is the difference from 0208 and 0209 to all other > indices, and why is 0210 and above OK if 0209 is a "too large" value? bash interprets numbers starting with 0 as octal numbers, but 8 and 9 aren't octal digits. It's documented in the bash manpage. So, I would hardly called this a bug in Debian. Cheers! -- Sergei Golovan -- 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/caoq2pxhcccea5dg5xp3q1ovlupzwqf_yymcuzvhgb6rehcz...@mail.gmail.com
Re: Erlang transition to R15B
On Wed, Dec 21, 2011 at 6:12 PM, Cyril Brulebois wrote: > Sergei Golovan (21/12/2011): >> Erlang R15B is already in experimental, so please, test and modify >> your packages if necessary. I'd like to upload R15B into unstable by >> the end of December. > > I suggest you get in touch with the release team to plan this > transition. Sorry, I'll write message to the release team shortly. Cheers! -- Sergei Golovan -- 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/caoq2pxfh_8hzb_7grx7d6b2-6f2wbnh5d7vx3j9bvgqhwfx...@mail.gmail.com
Erlang transition to R15B
Hi! As the new Erlang R15B is out I'd like to upload it to unstable. There are a few backwardly incompatible changes, so it's better to test whether the packages which reverse-depend on Erlang work successfully with R15B. The packages which require testing are: ejabberd (certainly will not work, requires at least patching external drivers and getting rid of 'regexp' module usage). couchdb (could work after rebuild, but likely will require patching external driver, see http://www.erlang.org/doc/man/erl_driver.html for details). erlang-guestfs from libguestfs sources (should just work after rebuild). rabbitmq-server (should not require any changes or rebuild). tsung (uses 'regexp' in its build script) uwsgi-plugin-erlang from uwsgi sources (should work as is) Erlang R15B is already in experimental, so please, test and modify your packages if necessary. I'd like to upload R15B into unstable by the end of December. Cheers! -- Sergei Golovan -- 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/caoq2pxe_2rtxxgype4qurkwd4enhz4tv9kbusba_18qrnoo...@mail.gmail.com
Generating SSL certificates in postinst
Hi! A few days ago I've received a bug report for the prosody package which says that if an admin changes OpenSSL config file then generating a selfsigned certificate may no longer work because it requires filling a different set of fields, so simply sending 7 lines to the stdin of openssl isn't sufficient (see [1]). I've searched through the archive and found several packages which suffer from the same bug (listing source packages): boxbackup dovecot dtc-xen ejabberd netkit-telnet-ssl openswan prosody rinputd stone strongswan uw-imap xmail yaws I see two ways of fixing this bug: either use -batch option which means that the certificate will be without common name (this approach is used in quassel), or supply an own OpenSSL config file along with the postinst script (or generate it in the postinst script as it is used in openvas-server). Is there a more reasonable way to generate self-signed certificate with common name (preferably without involving temporary OpenSSL configs)? Or may be using such certificates is not a good idea at all and it's better to disable SSL instead of giving selfsigned ones to users? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596433 Cheers! -- Sergei Golovan -- 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/aanlktimka_nej5b+vvoqn8jm6s=ronauw=tusq89b...@mail.gmail.com
Re: x11proto-core 7.0.13 will break Tk
On Sun, Feb 15, 2009 at 10:21 PM, wrote: > * Sergei Golovan [Sun, 15 Feb 2009 21:52:42 +0300]: > >> Yes. Tk 8.5 (and 8.6) are fixed by upstream, and the fix is ported to >> Tk 8.4 and 8.3. Though I don't know if another packages which ships >> their own Tk copies (Tkinter, Perl-Tk) have this bug fixed. > > Hm, they ship & compile a separate copy of Tk? python-tk depends on tk8.4, so I assume that it doesnt (my mistake). perl-tk doesn't depend on tk, so it does (but it seems that it can't use separate Tk). -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: x11proto-core 7.0.13 will break Tk
On Sun, Feb 15, 2009 at 9:24 PM, Julien Cristau wrote: > On Fri, 2008-07-11 at 14:07 +0400, Sergei Golovan wrote: >> I'd like to ask if there are plans to update x11proto-core to version >> 7.0.13 before lenny release? > > I'm about to upload 7.0.14 to sid now. Is there a tk fix by now? Yes. Tk 8.5 (and 8.6) are fixed by upstream, and the fix is ported to Tk 8.4 and 8.3. Though I don't know if another packages which ships their own Tk copies (Tkinter, Perl-Tk) have this bug fixed. -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: x11proto-core 7.0.13 will break Tk
On 7/20/08, Florian Weimer <[EMAIL PROTECTED]> wrote: > * Sergei Golovan: > > > Certainly affected packages are tk8.3, tk8.4, tk8.5, blt, tile. Also > > perl-tk and ruby are likely to break after possible upgrade of > > x11proto-core. (May be other packages which use Tk.) > > > What about statically-linked, proprietary applications? Why hasn't this > happened in the past? Tk adds its own X event numbers to a table of events. And puts it just after the last existing event (the following is an excerpt from tk.h): /* *--- * * Extensions to the X event set * *--- */ #define VirtualEvent(LASTEvent) #define ActivateNotify (LASTEvent + 1) #define DeactivateNotify(LASTEvent + 2) #define MouseWheelEvent (LASTEvent + 3) #define TK_LASTEVENT(LASTEvent + 4) #define MouseWheelMask (1L << 28) #define ActivateMask(1L << 29) #define VirtualEventMask(1L << 30) #define TK_LASTEVENT(LASTEvent + 4) It looks that until the last month there were exactly 35 events (LASTEvent equals 35), so the Tk core library, all extensions linked to it (which use event numbers directly) and all statically linked propriatory binaries were binary compatible. Now X people have added another event number (GenericEvent), which means that in the former excerpt LASTEvent changes to 36. So, if two extensions use the same tk.h but different x11proto-core versions (7.0.12 and 7.0.13) they will not be binary compatible. Statically linked proprietory binaries should be fine if they never receive GenericEvent from X (I'm not an expert, so I realy don't know if its possible to receive X event if an application doesn't know about it). -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Clarification about bug #463538 is needed
On 7/19/08, Russ Allbery <[EMAIL PROTECTED]> wrote:
> It's missing either setsid or ioctl("/dev/tty", TIOCNOTTY). The
> semi-standard daemon() function does the right thing. Here's a public
> domain replacement (which assumes you have an Autoconf probe for whether
> setsid is available). It depends on a wrapper around standard system
> headers, but I expect you get the idea and could fix that.
Huge thanks to all of you who took your time to answer! Indeed if I
add a call to setsid() the services become starting and daemonizing
fine. So, it's really a bug in Erlang and I'm going to report it
upstream (together with fixing in current version in unstable and
eventually in testing).
--
Sergei Golovan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Clarification about bug #463538 is needed
On 7/19/08, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
>
> Umm, if that patch fixes it (removing the TIOCSCTTY) then it seems to
> me that the erlang-based service will instead exit when the user who
> installed the server logs out. Evidently the services in erlang are
> not properly disassociating themselves from the terminal and this
> patch just makes it more obvious...
Erlang does exactly the following when detaches from a terminal:
if (start_detached) {
int status = fork();
if (status != 0)
return 0;
status = fork();
if (status != 0)
return 0;
close(0);
open("/dev/null", O_RDONLY);
close(1);
open("/dev/null", O_WRONLY);
close(2);
open("/dev/null", O_WRONLY);
}
{
execv(emu, Eargsp); /* executing the main Erlang emulator */
}
Is this behavior incorrect?
--
Sergei Golovan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Clarification about bug #463538 is needed
Hi! Currently APT fails to start all services which are based on Erlang (see bug #463538, [1]). It starts the service successfully but after apt-get finishes the service process get killed. I've found a one-line-patch which fixes this bug (see [2]) but I'm not sure if it's correct and doesn't break something else. Could someone review the patch and either apply it to the next APT version or may be help to fix this in some other way? (It might be an Erlang fault but I can't find anything wrong in how it detaches from a controlling terminal.) [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463538 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=tty.diff;att=1;bug=463538 Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: x11proto-core 7.0.13 will break Tk
On 7/11/08, Julien Cristau <[EMAIL PROTECTED]> wrote: > On Fri, Jul 11, 2008 at 14:07:02 +0400, Sergei Golovan wrote: > > I'd like to ask if there are plans to update x11proto-core to version > > 7.0.13 before lenny release? > > No, x11proto-core in lenny will be 7.0.12. OK. Then there's no hurry in fixing Tk. Thanks! -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
x11proto-core 7.0.13 will break Tk
Hi! I'd like to ask if there are plans to update x11proto-core to version 7.0.13 before lenny release? Upstream maintainers have added a new event GenericEvent which breaks Tk toolkit because Tk uses hardcoded event numbers and adds its own events (see [1]). Gentoo system is already affected (see [2]). As far as I can see there's no fix which would retain binary compatibility yet. Certainly affected packages are tk8.3, tk8.4, tk8.5, blt, tile. Also perl-tk and ruby are likely to break after possible upgrade of x11proto-core. (May be other packages which use Tk.) So, if the upgrade of x11proto-core is planned then we have to find an acceptable fix for Tk now. Otherwise we have some time to wait for a solution from upstream. [1] http://sourceforge.net/tracker/index.php?func=detail&aid=2010422&group_id=12997&atid=112997 [2] http://bugs.gentoo.org/show_bug.cgi?id=225999 Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488655: ITP: tk8.6 -- Tk toolkit for Tcl and X11, v8.6
Package: wnpp Severity: wishlist Owner: Sergei Golovan <[EMAIL PROTECTED]> * Package name: tk8.6 Version : 8.6a1 Upstream Author : Tcl Core Team * URL : http://www.tcl.tk/ * License : BSD Programming Lang: C, Tcl Description : Tk toolkit for Tcl and X11, v8.6 Tk is a cross-platform graphical toolkit which provides the Motif look-and-feel and is implemented using the Tcl scripting language. Version 8.6 is in alpha stage yet, so I'm planning to upload this package to experimental. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=ru_RU.CP1251, LC_CTYPE=ru_RU.CP1251 (charmap=CP1251) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488653: ITP: tcl8.6 -- Tcl (the Tool Command Language) v8.6
Package: wnpp Severity: wishlist Owner: Sergei Golovan <[EMAIL PROTECTED]> * Package name: tcl8.6 Version : 8.6a1 Upstream Author : Tcl Core Team * URL : http://www.tcl.tk/ * License : BSD Programming Lang: C, Tcl Description : Tcl (the Tool Command Language) v8.6 Tcl is a powerful, easy-to-use, embeddable, cross-platform interpreted scripting language. Version 8.6 is in alpha stage yet, so I intend to upload it to experimental. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=ru_RU.CP1251, LC_CTYPE=ru_RU.CP1251 (charmap=CP1251) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477699: general: No read permission for /usr/include/GL directory
On 4/24/08, Heikki Orsila <[EMAIL PROTECTED]> wrote: > On Thu, Apr 24, 2008 at 08:53:06PM +0400, Sergei Golovan wrote: > > > > root is not a usual user. His only purpose is to serve other users, > > and the results of his work should be accessible by them. So, it isn't > > wise to set root's umask to something different from 0022. > > > I disagree. Perhaps I'm paranoid because I use umask 0077 to avoid > leaking files to other users. This doesn't seem to affect OTHER packages > in the Debian system. At least, make this policy consistent. In my > opinion, package system should not depend on root users umask. To > compare with "make install" systems, they usually set the permissions > correctly. The point is that root must not own any file to hide from the other users (with a few exceptions). If you don't use root account as your working account then setting root umask to 0077 is unnecessary and creates more harm than solves problems. -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477699: general: No read permission for /usr/include/GL directory
On 4/24/08, Heikki Orsila <[EMAIL PROTECTED]> wrote: > > My root user has default umask 0077. root is not a usual user. His only purpose is to serve other users, and the results of his work should be accessible by them. So, it isn't wise to set root's umask to something different from 0022. -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Erlang on UltraSparc III (again)
On 2/24/08, Jurij Smakov <[EMAIL PROTECTED]> wrote: > > I can confirm that there is some serious problem. I've tried to > rebuild Erlang on SunBlade 1000 (which is Ultrasparc III) and I keep > getting non-reproducible falures (two "Bus Errors" in different > places, once aborted saying that the file is missing, and once just > hanged). > > Unfortunately, I don't have a clue on how to even start debugging > something like this. I think it could be easier to debug using older erlang version (11.b.5). It doesn't start a thread for every physical processor by default. So, its behavior should be more predictable. Bernd Zeimetz did look at this bug once (see http://www.mail-archive.com/[EMAIL PROTECTED]/msg02147.html) but due to lack of time he couldn't fix it. -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On 2/24/08, William Pitcock <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-02-24 at 14:00 +, Ian Jackson wrote:
> > John H. Robinson, IV writes ("Re: dash bug which is affecting release
> goal"):
> > > Pierre Habouzit wrote:
> > > > echo() { /bin/echo "$@" }
> > >
> > > echo() { /bin/echo ${1+"$@"}; }
> > >
> > > I believe you mean.
> >
> > Why ?!
>
>
> Because stand-alone $@ is undefined when used in this case. By using ${1
> +"$@"}, it is ensured that $@ always starts with $1.
Expression ${1+"$@"} means "if $1 exists use "$@", otherwise nothing".
It's a workaround for a bug in some old bash version which erroneously
converted "$@" in case of empty command line into a single empty
argument. I think in new releases it isn't necessary to account for
this.
--
Sergei Golovan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage now reorganizing debian/control Depends field??
On 2/22/08, Otavio Salvador <[EMAIL PROTECTED]> wrote: > > As I said, for APT, the order has meaning _always_. > > apt-get install foo bar > > Is completely different of > > apt-get install bar foo Then having a unique, well-defined order of packages in Depends is a good idea. If packages aren't sorted their order is undefined (not all of the dependencies are added by hands, many of them come from substitution variables). So, the order may change from build to build. Since it is important for APT then this situation should be avoided. -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Erlang on UltraSparc III (again)
Hi! It looks like Erlang still routinely fails to build on lebrun buildd (sparc architecture, dual UltraSparc III). Though the were some changes because instead of bus error (http://buildd.debian.org/fetch.cgi?&pkg=erlang&ver=1%3A12.b.1-dfsg-1&arch=sparc&stamp=1202857177&file=log) it reported internal compiler error (http://buildd.debian.org/fetch.cgi?&pkg=erlang&ver=1%3A12.b.1-dfsg-2&arch=sparc&stamp=1203250875&file=log). The code compiled was the same, the toolchain versions were the same too, so I suppose the change was caused by kernel upgrade. Also, Mikael Pettersson (an Erlang developer) said that Erlang is successfully built and working on [EMAIL PROTECTED] III. This almost convinced me that it's not a bug in Erlang but a bug in Linux kernel on UltraSparc III (maybe it's SMP-related). I don't have an access to USIII hardware to confirm this hypothesis. USII works fine (sperger runs USII, I tried to build erlang there. It builds.) If it's really a bug in kernel than I'd like to move erlang package and all package which build-depend on erlang to build at spontini on sparc architecture. Anyway, I need help to confirm (or reject) that it isn't an Erlang bug and to decide what to do with Erlang packaging on sparc architecture. It's very inconvenient to upload new versions to unstable knowing that they will never go to testing. -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tcl/Tk release goals
On 2/14/08, Cyril Brulebois <[EMAIL PROTECTED]> wrote: > On 13/02/2008, Francesco P. Lovergine wrote: > > [A] Removing /usr/lib in $auto_path [3]. That has been already > > announced in the past message with motivations for that, and > > experimental packages are available in experimental for testing. > > We are going to release a non-/usr/lib Tcl/Tk in unstable… > > Any timeframe for that? I noted the "ASAP" some words later, but > having an idea of the #days might help coordinating uploads. We're planning to file bugreports during the next week or two. > > > … and preparing a few NMUs for packages which need fixed > > pkgIndex.tcl for that. That will happen as soon as possible. > > What about first reporting bugs (with eventually the NMU patches that > are already prepared)? See gcc folks' advanced warnings, that looks > like the way to go, instead of NMUing in the wild. You're right. The procedure will be the following: 1) Reporting bug with proposed patch; 2) After some time period (a week?) NMUing. -- Sergei Golovan
Re: Correct spelling/capitalisation of project names
TCL -> Tcl tcl -> Tcl TK -> Tk tk -> Tk -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: How to debug FTBFS of erlang on sparc (UltraSPARC III)?
On 1/8/08, Michael Shuler <[EMAIL PROTECTED]> wrote: > On 01/07/2008 04:29 PM, Sergei Golovan wrote: > > I can't build it on UltraSPARC III because I don't have an access to > > it. > > Have you gotten access to a machine, Sergei? If not, let me know, I > would be happy to give you a login. I successfully (slowly) built > erlang_11.b.5dfsg-12 last night with pbuilder on my SunFire V120. Which kernel version do you have installed? But anyway, if the build is successful then this machine is useless for me :) For now several builds were tried (on Solaris and Debian sid) and all were successful. So, I suspect that the problem is in kernel on lebrun and titan. -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: How to debug FTBFS of erlang on sparc (UltraSPARC III)?
On 1/8/08, brian m. carlson <[EMAIL PROTECTED]> wrote: > On Tue, Jan 08, 2008 at 12:53:36AM +0300, Sergei Golovan wrote: > >Hi! > > > >After lebrun (which run on UltraSPARC III) became a sparc buildd host, > >erlang package started to FTBFS on sparc. Logs are available at > >http://buildd.debian.org/build.php?pkg=erlang but thay aren't very > >informative. They show "bus error" which can't help to fix the bug. > > A bus error is usually an unaligned access. I understand that. > > >I'd be happy to find the bug but I don't have an access to UltraSPARC > >III hardware. The only available to me Debian developer sparc machine > >(sperger) runs UltraSPARC II which doesn't reveal the bug. > > > >Is there a way to debug this bug? > > You should probably ask [EMAIL PROTECTED] if there's a > machine meeting those requirements that someone will let you use. The initial message was crossposted to [EMAIL PROTECTED] too. > > You might also determine whether the bug occurs when you build on > UltraSPARC III, but run on UltraSPARC II; IOW, whether the problem is > the build or execution environment. I can assist with that, if you send > me a gpg-signed binary. I can't build it on UltraSPARC III because I don't have an access to it. The binaries that are built on UltraSPARC II don't work on UltraSPARC III (It can be concluded from FTBFS of erlang-based packages (e.g. ejabberd which FTBFS too currently). I guess you might start building erlang on UltraSPARC III and after virtual machine is built (executables beam*) you could simply replace existing binaries from erlang-base (version 11.b.5-8) and try it on UltraSPARC II. But I'm afraid it's too complicated. -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFH: How to debug FTBFS of erlang on sparc (UltraSPARC III)?
Hi! After lebrun (which run on UltraSPARC III) became a sparc buildd host, erlang package started to FTBFS on sparc. Logs are available at http://buildd.debian.org/build.php?pkg=erlang but thay aren't very informative. They show "bus error" which can't help to fix the bug. I'd be happy to find the bug but I don't have an access to UltraSPARC III hardware. The only available to me Debian developer sparc machine (sperger) runs UltraSPARC II which doesn't reveal the bug. Is there a way to debug this bug? -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from Tcl/Tk team
On 10/16/07, Felipe Sateler <[EMAIL PROTECTED]> wrote: > Francesco P. Lovergine wrote: > > > The new policy tries to be as much as possible backward compatible, but > > there is at least an aspect which will introduce a breakage with the past > > (the removing of /usr/lib among $auto_path list [2]), mainly introduced to > > solve current performance-impacting situation. Tcl/Tk developers should > > refer to possible issues with their own extensions building due to this > > change (see [3]). > > Does this mean that installing a pkgIndex.tcl into /usr/lib/$package is > broken now, and that I should install the module to /usr/lib/tcltk? If so, > is a pkgIndex.tcl still required? No, the Tcl/Tk packages which comply to this policy aren't uploaded to Debian yet. Moreover, /usr/lib in auto_path will be retained until maintainers of all Tcl-based applications and extensions will repackage them. pkgIndex.tcl is still required, but it will be moved into a subdirectory of /usr/lib/tcltk or /usr/share/tcltk (not right now). Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444415: ITP: tklib -- The standard Tk library
Package: wnpp Severity: wishlist Owner: Sergei Golovan <[EMAIL PROTECTED]> * Package name: tklib Version : 0.4.1 Upstream Author : Various people (every module has its own author(s)) * URL : http://sourceforge.net/projects/tcllib/ * License : BSD Programming Lang: Tcl Description : The standard Tk library Tklib, the standard Tk library, is a collection of common utility functions and widgets all written in pure Tcl/Tk. Modules included: autoscroll: automatically maps scrollbars when they are needed; ctext: a text widget with syntax highlighting support; cursor: provides a few cursor routines; datefield: an entry widget for the purpose of date entry; Diagrams: helps drawing diagrams, like flowcharts; getstring: a dialog which prompts for a string input; history: provides a history for mechanism for entry widgets; ico: provides functions for reading and writing windows icons; ipentry: a widget for the entering of an IP address; khim: provides key bindings for entering international characters on a keyboard that does not support them; Plotchart: provides simple plotting and charting commands; style: provides simple theming using Tk options; swaplist: a dialog which allows to move options between two lists; tablelist: a multicolumn listbox widget; tkpiechart: 2D or 3D pie chart object in a canvas; tooltip: provides tooltips for Tk widgets; widget: a set of megawidgets based on snit system. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-amd64 Locale: LANG=ru_RU.CP1251, LC_CTYPE=ru_RU.CP1251 (charmap=CP1251) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443977: ITP: tcl8.5 -- Tcl (the Tool Command Language) v8.5
Package: wnpp Severity: wishlist Owner: Sergei Golovan <[EMAIL PROTECTED]> * Package name: tcl8.5 Version : 8.5b1 Upstream Author : Tcl Core Team (http://www.tcl.tk/community/coreteam/) * URL : http://www.tcl.tk/ * License : BSD Programming Lang: C, Tcl Description : Tcl (the Tool Command Language) v8.5 Tcl is a powerful, easy to use, embeddable, cross-platform interpreted scripting language. Version 8.5 has the following new features: - dict command - new lassign and lrepeat commands - arbitrary-precision integer support - expr ** exponentiation operator - namespace ensembles support - source -encoding switch - unload command - and much, much more This version is still under development, but the final release of 8.5.0 is expected soon. The current version is quite usable. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-amd64 Locale: LANG=ru_RU.CP1251, LC_CTYPE=ru_RU.CP1251 (charmap=CP1251) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443969: ITP: tk8.5 -- Tk toolkit for Tcl and X11, v8.5
Package: wnpp Severity: wishlist Owner: Sergei Golovan <[EMAIL PROTECTED]> * Package name: tk8.5 Version : 8.5b1 Upstream Author : Tcl Core Team (http://www.tcl.tk/community/coreteam/) * URL : http://www.tcl.tk/ * License : BSD Programming Lang: C, Tcl Description : Tk toolkit for Tcl and X11, v8.5 Tk is a cross-platform graphical toolkit which provides the Motif look-and-feel and is implemented using the Tcl scripting language. Version 8.5 has the following new features: - anti-aliased font support on X-Windows (via XFT) - updated look of radiobutton and checkbutton, and tri-state option - updates to the grid geometry manager - fully themed (native) widget set (in addition to classic look) - and much, much more This version is still under development, but it's quite usable, and the release of 8.5.0 is expected soon (when it will be done). -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-amd64 Locale: LANG=ru_RU.CP1251, LC_CTYPE=ru_RU.CP1251 (charmap=CP1251) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: many packages FTBFS, if $TAPE is set
On 9/10/07, Steve Greenland <[EMAIL PROTECTED]> wrote: > On 09-Sep-07, 02:26 (CDT), Sergei Golovan <[EMAIL PROTECTED]> wrote: > > But OK, I'll try to fix the package (setting HOME inside debian/rules > > should help). > > That's fixing a symptom, not the bug. What possible justification is > there for a package looking at the contents of $HOME during the build? Erlang compiler reads $HOME/.erlang if it exists. It's contents may have impact on the package. If the compiler cannot read $HOME it reports an ugly error message (though it still works). But an additional tool which is used in wings3d crashes if it cannot read $HOME. So, setting HOME to something like $(CURDIR)/debian makes package buildable and consistent (it doesn't depend on $HOME/.erlang anymore). So, I think that at least for erlang-based packages it's better to redefine HOME environment varibles. Is there a better solution? -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: many packages FTBFS, if $TAPE is set
On 9/9/07, Steve Langasek <[EMAIL PROTECTED]> wrote: > On Sun, Sep 09, 2007 at 11:08:19AM +0400, Sergei Golovan wrote: > > > One of the packages co-maintained by me FTBFS if HOME environment > > variable points to an existing inaccessible directory. (See > > http://buildd.debian.org/fetch.cgi?&pkg=wings3d&ver=0.98.36-4&arch=mipsel&stamp=1189251602&file=log) > > > Should this be treated as a bug in buildd configuration or package > > maintainers should take into account the possibility of so unusual > > HOME behavior? > > It's a bug in your package. Packages should not rely on anything in $HOME > for building, and should definitely not write anything to $HOME, as packages > are not supposed to modify anything outside of the build directory during > build. It would be sufficient (for this particular package) to point HOME to a truly unexistent directory. Is there a reason why /unexistent exists in buildd chroot? But OK, I'll try to fix the package (setting HOME inside debian/rules should help). > > The reason the mipsel buildd has a non-writable home is precisely because it > previously /did/ have a writable home, and various packages would in the > process of building pollute it with contents that would break subsequent > package builds. This way, all packages that depend on reading from /or/ > writing to $HOME break equally. So, mipsel buildd is a test station for HOME related bugs? -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: many packages FTBFS, if $TAPE is set
On 8/28/07, Russ Allbery <[EMAIL PROTECTED]> wrote: > I don't have any time to work on this, but it occurred to me reading this > that it might be useful for QA purposes to have a version of debuild that > *unsanitizes* the environment to test robustness. An evil-debuild that > sets every problematic environment variable that it can think of (TAPE, > QUILT_PATCHES, LANG, LC_ALL, PWD, etc.), builds the source in a directory > name containing a space, and otherwise tries all the environmental things > that have broken packages in the past. One of the packages co-maintained by me FTBFS if HOME environment variable points to an existing inaccessible directory. (See http://buildd.debian.org/fetch.cgi?&pkg=wings3d&ver=0.98.36-4&arch=mipsel&stamp=1189251602&file=log) Should this be treated as a bug in buildd configuration or package maintainers should take into account the possibility of so unusual HOME behavior? -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439727: ITP: tcludp -- UDP sockets for Tcl
Package: wnpp Severity: wishlist Owner: Sergei Golovan <[EMAIL PROTECTED]> * Package name: tcludp Version : 1.0.8 Upstream Author : Xiaotao Wu <[EMAIL PROTECTED]>, Pat Thoyts <[EMAIL PROTECTED]> * URL : http://sourceforge.net/projects/tcludp * License : BSD-like Programming Lang: (C, Tcl) Description : UDP sockets for Tcl TclUDP provides a new channel type for UDP and permits the use of packet oriented UDP over stream oriented Tcl channels. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=ru_RU.CP1251, LC_CTYPE=ru_RU.CP1251 (charmap=CP1251) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 'Uploaded' buildd status
On 7/2/07, Goswin von Brederlow <[EMAIL PROTECTED]> buildd.net lists emials for many buildds. Thanks! -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 'Uploaded' buildd status
On 7/2/07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: So if you see something being "uploaded" for a while then something went wrong. e.g. an upload error. The buildd admin has to upload the package again or return it for a rebuild. OK. I understand this. And how to ask buildd admin to upload the package again? -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 'Uploaded' buildd status
On 6/28/07, Ingo Juergensmann <[EMAIL PROTECTED]> wrote: On Thu, Jun 28, 2007 at 09:13:07AM +0400, Sergei Golovan wrote: > Could someone explain me (or point to a manual) what 'Uploaded' means > in http://people.debian.org/~igloo/status.php?packages=erlang ? > The package was initially uploaded for amd64 architecture. It was > built for i386 and stays in 'uploaded' state for several days. I > wonder why it can't become 'installed' as for the rest of > architectures. The same problem for m68k: http://unstable.buildd.net/buildd/m68k_stats.png As I found in http://www.debian.org/devel/buildd/wanna-build-states 'uploaded' state is a short-term state, so any delay longer than an hour should not be. Looking around http://buildd.debian.org/stats/ I've found several packages which stay in 'uploaded' state for a long time (more than 3 days): i386 (there's only one package which stays, others come and go): interpreters/erlang_1:11.b.4-4: Uploaded by buildd_i386-ninsei [optional:out-of-date] Previous state was Built until 2007 Jun 25 02:24:32 ia64 (this one stays for months): admin/gps_1.1.0-6: Uploaded by buildd_ia64-caballero [optional:out-of-date] Previous state was Building until 2006 Nov 23 17:48:17 mips (another very long-stay package): libdevel/mxml_2.2-2: Uploaded by buildd_mips-ball [optional:out-of-date] Previous state was Built until 2006 Oct 16 10:21:24 m68k (very many packages, most of them were uploaded in June 11): utils/strace_4.5.15-1: Uploaded by buildd_m68k-crest [standard:out-of-date] Previous state was Building until 2007 Jun 25 17:30:21 net/portmap_6.0-1: Uploaded by buildd_m68k-crest [standard:out-of-date] Previous state was Building until 2007 Jun 11 12:56:48 libs/guichan_0.6.1-3: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 25 17:29:37 libs/libarchive_2.2.3-1: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:50:32 libs/libgtksourceviewmm_0.3.1-1: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 13:24:31 libs/libspf2_1.2.5.dfsg-2: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:51:11 devel/debreaper_0.2.1: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:46:49 devel/haddock_0.8-2: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:48:35 devel/syslog-ocaml_1.3-4: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:58:26 shells/mksh_29.6-2: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:51:50 graphics/mkvtoolnix_2.0.2-1: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:52:20 admin/menu_2.1.34: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:51:30 admin/sg3-utils_1.24-1: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:58:08 utils/xosview_1.8.2-13: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 13:01:55 x11/kdeaddons_4:3.5.7-2: Uploaded by buildd_m68k-aahz [optional:out-of-date] Previous state was Building until 2007 Jun 10 10:41:01 net/libpam-afs-session_1.4-2: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:50:49 net/mrd6_0.9.5-rev3.dfsg-0.2: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:53:01 net/pidgin-extprefs_0.7-2: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:56:30 net/radvd_1:1.0-2: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:57:43 net/traffic-vis_0.34-19: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:59:51 net/twisted_2.5.0-2: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 13:00:42 mail/dbmail_2.2.5-1: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:46:31 mail/tart_3.07-2: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:59:02 gnome/deskbar-applet_2.18.1-2: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:47:08 kde/kaffeine_0.8.4-4: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was Building until 2007 Jun 11 12:50:08 libdevel/ocaml-sqlite_0.3.5.arch.4-9: Uploaded by buildd_m68k-crest [optional:out-of-date] Previous state was
'Uploaded' buildd status
Hi! Could someone explain me (or point to a manual) what 'Uploaded' means in http://people.debian.org/~igloo/status.php?packages=erlang ? The package was initially uploaded for amd64 architecture. It was built for i386 and stays in 'uploaded' state for several days. I wonder why it can't become 'installed' as for the rest of architectures. Best wishes! -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Help] Autoconf problems when trying to build WordNet 3.0 package
On 6/27/07, Ben Pfaff <[EMAIL PROTECTED]> wrote: The puzzling thing to me about this situation is what is expected to set TK_PREFIX. "grep TK_PREFIX" in the wordnet directory shows TK_PREFIX being used, but never defined anywhere. "grep TK_PREFIX" in /usr/share/aclocal shows no hits at all. Ditto for TCL_INCLUDE_SPEC. What do you expect to set TK_PREFIX and TCL_INCLUDE_SPEC? If you look at line 20547 (and below) of configure script you'll see that both tclConfig.sh and tkConfig.sh are sourced, but only few variables defined in them are actually used. I think there's something wrong with wordnet autoconf stuff. -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Help] Autoconf problems when trying to build WordNet 3.0 package
On 6/27/07, Ben Pfaff <[EMAIL PROTECTED]> wrote: The puzzling thing to me about this situation is what is expected to set TK_PREFIX. "grep TK_PREFIX" in the wordnet directory shows TK_PREFIX being used, but never defined anywhere. "grep TK_PREFIX" in /usr/share/aclocal shows no hits at all. Ditto for TCL_INCLUDE_SPEC. What do you expect to set TK_PREFIX and TCL_INCLUDE_SPEC? They are to be set by /usr/lib/tcl8.4/tclConfig.sh and /usr/bin/tk8.4/tkConfig.sh. But something in configure process went wrong. -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to package software with binaries in tarball?
On 6/14/07, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: On Wed, Jun 13, 2007 at 10:06:20PM +0400, Sergei Golovan wrote: >> pristine source. It is rather nice to be able take debian's tar.gz and >> verify with md5sum or a detached gpg sig that upstream's tarball is > The original tarball contains non-free RFCs, so it is recreated anyway. On a general note (I haven't checked if this applies to erlang or not): Please, if you repack, include the exact instructions for repacking in debian/copyright; ideally down to something you could cut-and-paste into a shell. Even though the resulting tarball might not be identical, it makes for much easier NMUing _and_ upstream intactness checking. Is get-orig-source target in debian/rules, which fetches and repacks orig.tar.gz sufficient? I guess it should be. -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to package software with binaries in tarball?
On 6/13/07, Andreas Metzler <[EMAIL PROTECTED]> wrote: > Should we remove them from the original tarball, or is it better to leave them? Unless there is a huge a gain in tarball size I would keep the Tarball without binaries is about 11Mb, with binaries is about 37Mb. pristine source. It is rather nice to be able take debian's tar.gz and verify with md5sum or a detached gpg sig that upstream's tarball is The original tarball contains non-free RFCs, so it is recreated anyway. identical. OTOH if I needed to repackaged the source tarball anyway since it contains non DFSG free material I would remove the binaries too. OK. I see your point. Thanks! -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to package software with binaries in tarball?
Hi! What is a recommended practice of packaging programs, for which distributed tarball contains binaries (generated from the sources)? Specifically, newly released erlang distribution includes prebuilt architecture-independent binary files. Should we remove them from the original tarball, or is it better to leave them? Best wishes! -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425759: ITP: tcltrf -- Tcl data transformations library (Tcl-Trf)
Package: wnpp Severity: wishlist Owner: Sergei Golovan <[EMAIL PROTECTED]> * Package name: tcltrf Version : 2.1p2-20060125 Upstream Author : Andreas Kupries <[EMAIL PROTECTED]> * URL : http://tcltrf.sourceforge.net/ * License : BSD-type Programming Lang: (Tcl, C) Description : Tcl data transformations library (Tcl-Trf) This package contains an extension to Tcl, which provides various data transformations. The collection of provided transformation procedures includes: * generation of message digests (hash values, checksums): MD2, MD5, SHA/SHS, SHA-1, HAVAL, RIPEMD-128, -160, CRC (polynomial used by PGP), ADLER (based upon zlib); * conversion from and to various data encodings: dual, octal, hexadecimal representation, uuencoding, base64-encoding, ASCII85-encoding; * a Reed-Solomon error correcting coder; * compression/decompression based on zlib and libbz2. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=ru_RU.CP1251, LC_CTYPE=ru_RU.CP1251 (charmap=CP1251) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425756: ITP: memchan -- Tcl extension, which implements in-memory channels
Package: wnpp Severity: wishlist Owner: Sergei Golovan <[EMAIL PROTECTED]> * Package name: memchan Version : 2.2.1 Upstream Author : Andreas Kupries <[EMAIL PROTECTED]> * URL : http://memchan.sourceforge.net/ * License : BSD-type Programming Lang: (Tcl, C) Description : Tcl extension, which implements in-memory channels Allows to create I/O channels, which store the data placed into them in memory, not on disk. Several channel types are implemented: fifo, null, random and zero channels. Also, C API is provided for creating custom memory channels. This software can be used by tclvfs package (without it tclvfs can only browse filesystems and can't open files). -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=ru_RU.CP1251, LC_CTYPE=ru_RU.CP1251 (charmap=CP1251) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
