Bug#1069545: [Pkg-erlang-devel] Bug#1069545: erlang: FTBFS on armel: make[4]: *** [/<>/make/arm-unknown-linux-gnueabi/otp.mk:325: ../pdf/wx-2.2.2.1.pdf] Error 1
notfound 1069545 1:25.3.2.11+dfsg-1 thanks Hi Lucas, Java throwing an out-of-memory exception on armel doesn't count as a bug, I reckon. On the other hand, my previous thought about sufficient memory size on builds is irrelevant because builds build only architecture dependent packages, and erlang-doc is architecture independent. On Tue, Apr 23, 2024 at 10:02 AM Sergei Golovan wrote: > > Version: 1:25.3.2.11+dfsg-1 > > Hi Lukas, > > On Sat, Apr 20, 2024 at 4:27 PM Lucas Nussbaum wrote: > > > > Hi, > > > > During a rebuild of all packages in sid, your package failed to build > > on armel. > > > > [INFO] FOUserAgent - Rendered page #871. > > > Exception in thread "main" java.lang.OutOfMemoryError: Java heap space > > It's an intermittent out-of-memory error. It never occurs on buildds > (I guess they just have more memory available then in the setup you're > using for the archive rebuild). Therefore, I'm closing this bugreport. > > Cheers! > -- > Sergei Golovan -- Sergei Golovan
Bug#1067701: [Pkg-erlang-devel] Bug#1067701: FTBFS: _TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64
Hi, Lukas! On Tue, Mar 26, 2024 at 2:42 PM Lukas Larsson wrote: > > This bug has been fixed but not released yet for Erlang. This is the github > PR with the fix: https://github.com/erlang/otp/pull/7952 > > The fix will be part of the Erlang 27 release. Thank you for pointing out the PR request! I'm planning to upload Erlang 27 for trixie, but currently it requires some additional tools missing in Debian. So, I'll add this fix in the meantime for Erlang 25. -- Sergei Golovan
Bug#1062462: [Pkg-tcltk-devel] Bug#1062462: itk3: NMU diff for 64-bit time_t transition
Hi Graham, On Thu, Feb 1, 2024 at 6:57 PM Graham Inggs wrote: > > Source: itk3 > Version: 3.4.2-3.1 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > itk3 as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). Can you elaborate how exactly you determined that itk3 is affected by time_t size change? As far as I can see in the sources, it doesn't use time_t at all. Cheers! -- Sergei Golovan
Bug#1062461: [Pkg-tcltk-devel] Bug#1062461: itcl3: NMU diff for 64-bit time_t transition
Hi Graham, On Thu, Feb 1, 2024 at 6:57 PM Graham Inggs wrote: > > Source: itcl3 > Version: 3.4.4-2 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > itcl3 as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). Can you elaborate how exactly you determined that itcl3 is affected by time_t size change? As far as I can see in the sources, it doesn't use time_t at all. Cheers! -- Sergei Golovan
Bug#1029034: snack: includes non-free source
Hi Thomas, Thank you very much for the patch! It makes the snack package build just fine. I'll do some testing and upload the fixed package shortly! As far as I can tell, there's still time for it to make bookworm (Debian 12). On Sun, Feb 19, 2023 at 12:12 AM Thomas Uhle wrote: > > Dear maintainers, > > I would very much appreciate if this package would be kept in Debian. > That is why I've had a look into the source code and have seen that there > is yet another implementation for a downsampler in jkGetF0.c that is not > proprietary code. And so I was thinking what is good enough to be used > for the estimation of the first formant F0, cannot be bad for doing the > computation to estimate all the others. However, in contrast to the code > from downsample.c, this other downsampler is not using 16-bit integer > values but it is a floating-point implementation. So it is not a drop-in > replacement and I had to rewrite large portions of the two functions > Fdownsample() and highpass(). I also had to make the function do_ffir() > public to be used by the highpass filter implementation and to uncomment > and fix some code in it that was headlined by /* never used */ but is > needed to make the highpass filter implementation working again. > > Long story short, there is a patch attached to this e-mail that I grant > under the license of either GPL2+ (like it is used for the whole project > snack) or BSD (like it is said to be in the headers of jkFormant.c and > jkGetF0.c), whatever suits you, in the hope to save this package from > being dropped. > I have attached two versions of it because I don't know whether the 170 > lines of conflicting proprietary code have to be removed before or can be > replaced by the patch. So applying remove_downsample.c.diff removes the > conflicting lines from jkFormant.c, formant.patch is the actual fix to > make the implementation work again, and formant2.patch is a combination > of both. > > I hope it is not too late. > > Best regards, > > Thomas Uhle -- Sergei Golovan
Bug#1029034: snack: includes non-free source
Hi Bastian, Thank you for the report! On Mon, Jan 16, 2023 at 9:33 PM Bastian Germann wrote: > > While the file part that is copied from formant.c is okay to be included in > Debian, the part from downsample.c is not. > Please repack the source package getting rid of the file. I don't think that I can remove this code without reimplementing its functionality somehow. So maybe it'd be better to drop the package from Debian. There are two packages that depend on tcl-snack: transcriber and wavesurfer. I guess they'd have to be removed from Debian as well. Cheers! -- Sergei Golovan
Bug#1024632: [Pkg-erlang-devel] Bug#1024632: Bug#1024632: Bug#1024632: erlang: CVE-2022-37026 Client Authentication Bypass
Hi! On Mon, Dec 12, 2022 at 5:27 PM Sergei Golovan wrote: > > Hi Salvatore, > > On Fri, Dec 9, 2022 at 12:15 AM Salvatore Bonaccorso > wrote: > > > > The upcoming point release for 11.6 is scheduled for 17th with > > uploading window closing the upcoming weekend. If we are confident > > enough about potential regressions, can you make sure the fix land in > > the next bullseye point release? > > Unfortunately, I've found a few regressions in the Erlang test suite, > and I couldn't fix them myself yet. I'll try my best to do that > tonight and tomorrow, but I'm afraid I'd suggest postponing uploading > patched Erlang to stable. I couldn't fix these regressions in the test suite, but it appears that they are present in the latest released Erlang 23 version (23.3.4.18) as well. Therefore, I'm uploading the fix to stable. Cheers! -- Sergei Golovan
Bug#1024632: [Pkg-erlang-devel] Bug#1024632: Bug#1024632: erlang: CVE-2022-37026 Client Authentication Bypass
Hi Salvatore, On Fri, Dec 9, 2022 at 12:15 AM Salvatore Bonaccorso wrote: > > The upcoming point release for 11.6 is scheduled for 17th with > uploading window closing the upcoming weekend. If we are confident > enough about potential regressions, can you make sure the fix land in > the next bullseye point release? Unfortunately, I've found a few regressions in the Erlang test suite, and I couldn't fix them myself yet. I'll try my best to do that tonight and tomorrow, but I'm afraid I'd suggest postponing uploading patched Erlang to stable. Cheers! -- Sergei Golovan
Bug#1024632: [Pkg-erlang-devel] Bug#1024632: erlang: CVE-2022-37026 Client Authentication Bypass
Hi Markus, On Wed, Nov 30, 2022 at 4:15 PM Markus Koschany wrote: > > Hello, > > I have prepared a security update for Bullseye which fixes CVE-2022-37026. > Sergei could you review the update please? I am attaching the debdiff. I'm also preparing a fix for CVE-2022-37026, but I'll gladly consider your patch first. Thank you for the work! -- Sergei Golovan
Bug#996437: elixir-lang: FTBFS with Erlang 24.1 (one test fails)
Hi Evgeny. I've missed your first reply somehow, sorry. I'll happily do NMU on the weekend. On Thu, Oct 21, 2021, 16:44 Evgeny Golyshev wrote: > Hi Sergei > > If you don't have time to do the NMU, tell me and I will upload the > package applying your patch. > > -- > Evgeny > > On Mon, 18 Oct 2021 at 14:25, Evgeny Golyshev wrote: > >> Hello Sergei >> >> Thank you for the patch you prepared. It's well done. Feel free to do a >> NMU. >> >> -- >> Evgeny >> >
Bug#992609: careless upload of Erlang v24 without a transition tracking with the release team (was: rabbitmq-server fails to start after erlang v24 update)
Hi Thomas, On Sun, Aug 22, 2021 at 6:55 PM Thomas Goirand wrote: > > Hi Damir, Sergei, the release team, > > First of all, thanks for your bug report, Damir. > > Debian Bullseye was released on the 14th of Aug. Then Erlang v24 was > uploaded on the 17th. Looking at: > > https://release.debian.org/transitions/ > > I cannot see any transition thingy opened for Erlang. This means that > Erlang was carelessly uploaded to Unstable: Uploading new major version of Erlang does not require a transition. No application needs to be rebuilt against it, and only a minority breaks (those which use removed deprecated features, and they have to be updated or patched anyway). I'm sorry that elixir and rabbit-mq break. > > 1/ Without informing the release team, and defining a schedule for the > Erlang transition I insist that a transition is not necessary. > > 2/ Without rebuilding any reverse dependency, and more specifically, > without caring about RabbitMQ which is kind of a high profile server > application. > > Now, we have Erlang v24 in Unstable which looks like a good target for > RabbitMQ 3.9.4, however, this new version needs a new Elixir release, as > it has a bound of ">= 1.10.4 and < 1.13.0". Elixir as in unstable (ie: > 1.10.3) doesn't work, even when trying to convince RabbitMQ it's ok. Well, I would say that Elixir in Debian is not in a good shape. It lags way behind upstream (which is already 1.12.2, quite a few releases ahead). > > There isn't much I can do now. I'm opening a bug against Elixir, and > I'll have to wait for it to be solved... > > This isn't the first time something like this happen. Could we please > bring some sanity in the way we do things? Sergei, could you please > revert your upload of Erlang v24 in Unstable, and open a release team > bug to get a transition tracker thingy, which is the only sane way to do > things in Debian? > > Not amused... I've uploaded Erlang 24 to experimental months ago. If you know that your software breaks on Erlang upgrade, you could do something already. Cheers! -- Sergei Golovan
Bug#986662: ossp-padsp not working with recent Pulseaudio
Hi Ralf, On Fri, Apr 30, 2021 at 2:07 PM Ralf Jung wrote: > > Hi Sergei, > > Our current problem is that we cannot even upload the package to unstable > since > my key in the debian keyring expired (and the updated key missed the April > keyring update), and Sebastien is not yet allowed to upload osspd. > I've done the upload before figuring this out, so now revision 12 is sitting > on > the ftp server and waiting for my key to become valid... > > If you are a DD, maybe you can help by uploading the package for us? I guess > we'd have to prepare a revision 13, but that should be easy. Yes, I'm a DD, sorry if I wasn't clear about this. > > When we prepared the fix, we were not aware that this would become an RC bug, > so > we didn't strive for a minimal fix. Okay. Then I'll open a bugreport with release.debian.org and ask if this not so minimal update can propagate to testing. If yes, I'll reupload it. Cheers! -- Sergei Golovan
Bug#986662: ossp-padsp not working with recent Pulseaudio
Hi Ralf, Sebastien, If you need any help with uploading the osspd package, please let me know. I've looked at the current 1.3.2-12 in Git, and it looks fine with the exception that it adds more changes than the fix of this bug (which is not advisable during freeze periods). So, I'd start to ask the release team if they are willing to grant a freeze exception for the new version prior to upload. Cheers! -- Sergei Golovan
Bug#985389: yaws: debug is enabled, which makes the package unusable for production
Package: yaws Version: 2.0.8+dfsg-2 Severity: grave Justification: renders package unusable Dear Maintainer, Currently, yaws is built with debug enabled, which slows it down and clutters its log files. The debug sould be disabled before the bullseye release.
Bug#985124: Acknowledgement (fossil: fails to update schema for older repositories)
Hi Barak,
I did some testing, the patch from
https://www2.fossil-scm.org/fossil/info/d4041437b6f40d0cc62f22d2973498d596af325b1d18fed2dd7584aef733df7a
indeed fixes the bug. I'm attaching the patch, and if you want, I can
do NMU.
--
Sergei Golovan
diff -Nru fossil-2.14/debian/changelog fossil-2.14/debian/changelog
--- fossil-2.14/debian/changelog 2021-01-24 19:12:40.0 +0300
+++ fossil-2.14/debian/changelog 2021-03-13 12:59:32.0 +0300
@@ -1,3 +1,11 @@
+fossil (1:2.14-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload
+ * Apply an upstream patch which fixes updating schema for repositories
+created by fossil 1.x (closes: #985124)
+
+ -- Sergei Golovan Sat, 13 Mar 2021 12:59:32 +0300
+
fossil (1:2.14-1) unstable; urgency=medium
* New upstream version
diff -Nru fossil-2.14/debian/patches/series fossil-2.14/debian/patches/series
--- fossil-2.14/debian/patches/series 2021-01-24 19:12:40.0 +0300
+++ fossil-2.14/debian/patches/series 2021-03-13 12:57:08.0 +0300
@@ -1 +1,2 @@
debian-changes
+update-schema.patch
diff -Nru fossil-2.14/debian/patches/update-schema.patch fossil-2.14/debian/patches/update-schema.patch
--- fossil-2.14/debian/patches/update-schema.patch 1970-01-01 03:00:00.0 +0300
+++ fossil-2.14/debian/patches/update-schema.patch 2021-03-13 12:59:32.0 +0300
@@ -0,0 +1,27 @@
+Author: Upstream
+Description: Disable devencive mode when updating schema for repositories created by fossil 1.x.
+
+--- a/src/rebuild.c
b/src/rebuild.c
+@@ -156,17 +156,20 @@
+ /* Search for: length(uuid)==40
+ ** 0123456789 12345 */
+ int i;
+ for(i=10; z[i]; i++){
+ if( z[i]=='=' && strncmp([i-6],"(uuid)==40",10)==0 ){
++int rc = 0;
+ z[i] = '>';
++sqlite3_db_config(g.db, SQLITE_DBCONFIG_DEFENSIVE, 0, );
+ db_multi_exec(
+"PRAGMA writable_schema=ON;"
+"UPDATE repository.sqlite_schema SET sql=%Q WHERE name LIKE 'blob';"
+"PRAGMA writable_schema=OFF;",
+z
+ );
++sqlite3_db_config(g.db, SQLITE_DBCONFIG_DEFENSIVE, 1, );
+ break;
+ }
+ }
+ fossil_free(z);
+ }
+
Bug#985124: fossil: fails to update schema for older repositories
Package: fossil
Version: 1:2.14-1
Severity: grave
Tags: upstream fixed-upstream
Dear Maintainer,
After updating the fossil package to 1:2.14-1, I've found that it fails
to open repositories created a while ago. It emits the following error
message:
SQLITE_ERROR(1): table sqlite_master may not be modified in "UPDATE
repository.sqlite_schema SET sql='CREATE TABLE blob(
rid INTEGER PRIMARY KEY,
rcvid INTEGER,
size INTEGER,
uuid TEXT UNIQUE NOT NULL,
content BLOB,
Database error: table sqlite_master may not be modified: {UPDATE
repository.sqlite_schema SET sql='CREATE TABLE blob(
rid INTEGER PRIMARY KEY,
rcvid INTEGER,
size INTEGER,
uuid TEXT UNIQUE NOT NULL,
content BLOB,
CHECK( length(uuid)>=40 AND rid>0 )
)' WHERE name LIKE 'blob';PRAGMA writable_schema=OFF;}
The message indicates that the repository Sqlite DB is in defencive
mode, and its schema can't be modified using UPDATE.
As far as I can see, this bug is fixed upstream in the following commit:
https://www2.fossil-scm.org/fossil/info/d4041437b6f40d0cc62f22d2973498d596af325b1d18fed2dd7584aef733df7a
which is a part of the 2.15 release.
Please, apply the fix to the fossil package in Debian, as it is now,
fossil is not very usable. I'm sure, the bug is serious enough to grant
a freeze exception.
To reproduce the bug, just create an empty repository using fossil
binary from stretch (1:1.37-1), and try to connect to it using fossil
1:2.14-1:
fossil-1.37 new test.fossil
fossil-2.14 info -R test.fossil
Cheers!
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages fossil depends on:
ii libc6 2.31-9
ii libfuse22.9.9-5
ii libsqlite3-03.34.1-3
ii libssl1.1 1.1.1j-1
ii libtcl8.6 [libtcl] 8.6.11+dfsg-1
ii zlib1g 1:1.2.11.dfsg-2
fossil recommends no packages.
Versions of packages fossil suggests:
ii gnupg 2.2.27-1
-- no debconf information
--
Sergei Golovan
Bug#983829: [Pkg-tcltk-devel] Bug#983829: tk-doc: copyright file missing (policy 12.5)
Hi Andreas, On Tue, Mar 2, 2021 at 4:54 AM Andreas Beckmann wrote: > > Hi, > > a test with piuparts revealed that your package misses the copyright > file, which is a violation of Policy 12.5: > https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information > > From the attached log (scroll to the bottom...): > > 0m15.7s ERROR: WARN: Inadequate results from running adequate! > tk-doc: missing-copyright-file /usr/share/doc/tk-doc/copyright > > MISSING COPYRIGHT FILE: /usr/share/doc/tk-doc/copyright > # ls -lad /usr/share/doc/tk-doc > ls: cannot access '/usr/share/doc/tk-doc': No such file or directory > # ls -la /usr/share/doc/tk-doc/ > ls: cannot access '/usr/share/doc/tk-doc/': No such file or directory Hm. /usr/share/doc/tk-doc should be a symlink to /usr/share/doc/tcl-doc. Looks like it went missing when it was built by a buildd daemon. Thank you for reporting this! -- Sergei Golovan
Bug#947272: blt builds fine with gcc-10
severity 947272 important thanks Hi Holger, On Wed, Dec 30, 2020 at 9:27 PM Holger Levsen wrote: > > On Wed, Dec 30, 2020 at 06:36:23PM +0300, Sergei Golovan wrote: > > There isn't Tcl/Tk 8.7 in unstable yet, only an alpha in experimantal. > > After the Tcl/Tk 8.7 will be released, I'll deal with this bug in > > unstable. > > ah, ok, makes sense. > > probably it would still be nicer to downgrade this bug to severity important > until that tcl/tk version has reached unstable. You're right. Currently this bug does not have any impact on the bullseye release. I'm downgrading its severity. -- Sergei Golovan
Bug#947272: blt builds fine with gcc-10
Hi Holger, On Wed, Dec 30, 2020 at 6:26 PM Holger Levsen wrote: > > Hi Sergei, > > On Wed, Dec 30, 2020 at 05:26:53PM +0300, Sergei Golovan wrote: > > This bug is actually about blt 2.5.3+dfsg-5 and failure to build with > > Tcl/Tk 8.7. So the serious severity is justified. The bug title is > > misleading though, so I'm changing it. Sorry for not doing it sooner. > > ah, cool! > > now I just wonder why it still builds in unstable? There isn't Tcl/Tk 8.7 in unstable yet, only an alpha in experimantal. After the Tcl/Tk 8.7 will be released, I'll deal with this bug in unstable. -- Sergei Golovan
Bug#947272: blt builds fine with gcc-10
retitle 947272 blt: FTBFS with Tcl/Tk 8.7 (>= 8.7.0~a3): error: argument 'argv' doesn't match prototype severity 947272 serious thanks Hi Holger! This bug is actually about blt 2.5.3+dfsg-5 and failure to build with Tcl/Tk 8.7. So the serious severity is justified. The bug title is misleading though, so I'm changing it. Sorry for not doing it sooner. On Wed, Dec 30, 2020 at 5:06 PM Holger Levsen wrote: > > control: severity -1 important > thanks > > Hi Andreas, > > it seems blt builds fine with gcc-10 as can be seen from the recent upload, > so I'm downgrading the severity and am wondering if we should actually close > this bug (=ftbfs with gcc-9). What do you think? > > > -- > cheers, > Holger > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org > ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C > ⠈⠳⣄ > > Dance like no one's watching. Encrypt like everyone is. -- Sergei Golovan
Bug#963192: critcl can't find the critcl_md5 package
Package: critcl
Version: 3.1.17+dfsg-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
Currently, critcl cannot create any C proc because it can't find the
critcl_md5c package:
tclsh8.6 [~] package require critcl
3.1.17
tclsh8.6 [~] critcl::cproc A {} int {return 1;}
can't find package critcl_md5c
while evaluating critcl::cproc A {} int {return 1;}
tclsh8.6 [~]
-- System Information:
Debian Release: 10.4
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500,
'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), (1,
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-9-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages critcl depends on:
ii build-essential 12.6
ii gcc 4:8.3.0-1
ii tcl 8.6.9+1
ii tcl-dev 8.6.9+1
ii tcl8.6-dev 8.6.9+dfsg-2
ii tcllib 1.19-dfsg-2
Versions of packages critcl recommends:
ii tcl-trf 2.1.4-dfsg3-2+b1
critcl suggests no packages.
-- no debconf information
Bug#958841: erlang breaks elixir-lang autopkgtest: killed
On Mon, Apr 27, 2020 at 11:01 AM Sergei Golovan wrote: > Looks like changes in Erlang regular expressions library broke Elixir > again. Elixir stores internal binary representation of regular > expressions in its compilation phase, and it breaks when Erlang > changes this representation (which happens now and then, since it > isn't supposed to be stable). > > I've already added a virtual package which reflects the version of the > PCRE library Erlang uses (to indicate that Elixir requires > rebuilding), but clearly it's insufficient. I'll have to increment its > version on changes in erl_bif_re.c as well. > > As a long term solution, I'd suggest the maintainer of Elixir to reach > out downstream and suggest not to use unstable interfaces fro regular Sorry, I meant upstream here. > expressions (not precompile them in advance). Also, it seems like Elixir upstream did some enhancements in this area. See the changelog to 1.9.2: https://github.com/elixir-lang/elixir/releases/tag/v1.9.2 Cheers! -- Sergei Golovan
Bug#958841: erlang breaks elixir-lang autopkgtest: killed
Hi Paul! On Sat, Apr 25, 2020 at 10:09 PM Paul Gevers wrote: > > Dear maintainer(s), > > With a recent upload of erlang the autopkgtest of elixir-lang fails in > testing when that autopkgtest is run with the binary packages of erlang > from unstable. It passes when run with only packages from testing. In > tabular form: > >passfail > erlang from testing1:22.3.2+dfsg-1 > elixir-langfrom testing1.9.1.dfsg-1.3 > all others from testingfrom testing Looks like changes in Erlang regular expressions library broke Elixir again. Elixir stores internal binary representation of regular expressions in its compilation phase, and it breaks when Erlang changes this representation (which happens now and then, since it isn't supposed to be stable). I've already added a virtual package which reflects the version of the PCRE library Erlang uses (to indicate that Elixir requires rebuilding), but clearly it's insufficient. I'll have to increment its version on changes in erl_bif_re.c as well. As a long term solution, I'd suggest the maintainer of Elixir to reach out downstream and suggest not to use unstable interfaces fro regular expressions (not precompile them in advance). Cheers! -- Sergei Golovan
Bug#936678: Patch & NMU suggestion
tags 936678 + patch thanks Hi Onur, I'd like to suggest a patch which removes the Python 2 support from gumbo-parser. It contains minimal changes I came up with to remove Python 2 and leave anything untouched. If you don't mind, I could do NMU with this patch. Cheers! -- Sergei Golovan
Bug#936678: Attachment
Hi Onur, Actually attaching the patch. Cheers! -- Sergei Golovan gumbo-parser_0.10.1+dfsg-2.4.diff Description: Binary data
Bug#941124: [Pkg-erlang-devel] Bug#941124:
Hi Evgeny,
On Tue, Oct 1, 2019 at 1:27 PM Evgeny Golyshev wrote:
>
> Hello everyone
>
> I maintain Elixir in Debian.
> Obviously the compatibility between the Erlang's versions has been
> broken. I did a small research and found out that failing autopkgtest
> is the result of Erlang's :re module. Unfortunately, I can't provide
> details for the problem because a deeper study of it can take a lot of
> time which I don't have so far.
> Also I can confirm that rebuilding Elixir against the newest Erlang
> fixes the problem.
I'd like to propose a fix for this bug. It adds a dependency on newly
introduced virtual package erlang-pcre-, which will help to
notice when PCRE is changed.
The patch also utilises ${erlang:Depends} which calculates the dependencies
automatically. By the way, it appears that elixir should depend not only
on erlang-base, but also on a few other erlang related packages (erlang-crypto,
erlang-inets etc.)
If you don't mind, I could make a NMU with these changes (the NMU diff
is attached).
Cheers!
--
Sergei Golovan
elixir-lang_1.9.1dfsg-1.1.nmu.diff
Description: Binary data
Bug#941124: [Pkg-erlang-devel] Bug#941124:
Hi Evgeny,
On Tue, Oct 1, 2019 at 1:27 PM Evgeny Golyshev wrote:
>
> Hello everyone
>
> I maintain Elixir in Debian.
> Obviously the compatibility between the Erlang's versions has been
> broken. I did a small research and found out that failing autopkgtest
> is the result of Erlang's :re module. Unfortunately, I can't provide
> details for the problem because a deeper study of it can take a lot of
> time which I don't have so far.
> Also I can confirm that rebuilding Elixir against the newest Erlang
> fixes the problem.
Here is a simple example which demonstrates the issue.
Just compile it using Erlang 21 backend, and then run with Erlang 22.
The first call to a Regex.run/2 uses the precompiled regex, and will match
only "s", the second call uses the same regex but recompiles it, so it will
successfully match the whole string. (The original Erlang re:run also
succeeds because it isn't precompiled).
# reg.ex
defmodule Reg do
def run do
regex = ~r/[a-z]+/i
IO.puts Regex.opts(regex)
IO.puts Regex.source(regex)
IO.puts Regex.run(regex, "sTrInG")
IO.puts Regex.run(Regex.recompile!(regex), "sTrInG")
IO.puts inspect :re.run("sTrInG", "[a-z]+", [:caseless])
end
end
Cheers!
--
Sergei Golovan
Bug#941124: nmu: elixir-lang_1.9.1.dfsg-1
Hi!
On Mon, Sep 30, 2019 at 10:02 PM Paul Gevers wrote:
> >
> > Apparently, elixir-land needs to be rebuilt against newer erlang 22.1.
>
> That's not the proper way to solve bugs.
Indeed, it seems to me now that it's a bug in packaging Erlang and
Elixir. We'll try to fix it.
>
> > Currently, it doesn't pass autopkgtest (see [1] for details).
> >
> > There were some internal changes in Erlang re module (regular expressions)
> > which
> > triggered the test failure. After a simple rebuild all tests pass again.
>
> This means that either erlang changed something they shouldn't have
> changed (think of software outside of the Debian archive here as well),
> or elixir-lang is buggy and it is using something of erlang that it
> should be using (in its autopkgtest). Please discuss and figure out
> which package needs to fix something and reassign the package to it.
After some digging, I've found that the situation is indeed
documented. Citing from
elixir-lang-source/lib/elixir/lib/regex.ex:
Regular expressions built with sigil are precompiled and stored in `.beam`
files. Precompiled regexes will be checked in runtime and may work slower
between operating systems and OTP releases. This is rarely a
problem, as most Elixir code
shared during development is compiled on the target (such as dependencies,
archives, and escripts) and, when running in production, the code must either
be compiled on the target (via `mix compile` or similar) or released on the
host (via `mix releases` or similar) with a matching OTP, OS and architecture
as as the target.
If you know you are running on a different system that the current one and
you are doing multiple matches with the regex, you can manually invoke
`Regex.recompile/1` or `Regex.recompile!/1` to perform a runtime version
check and recompile the regex if necessary.
It happened that the PCRE library Erlang uses was updated in Erlang 22.1,
so the precompiled regexs (at least some of them) stopped working in the new
runtime. The elixir sources have to be rebuilt to match the PCRE changes
(there's no need to fix anything in the sources because re: API in Erlang
didn't change).
Can it be treated as a bug in Elixir that needs to be fixed? I'm not
sure upstream
will agree.
So, I'd like to suggest the following: I'll add another virtual package
(erlang-pcre-8.43 as for now) reflecting the PCRE version currently in Erlang.
Elixir will depend on it (via ${erlang-pcre:Depends} substitution variable and
the erlang-depends script call in debian/rules). This means that when the PCRE
library updates, elixir temporarily becomes uninstallable and needs a rebuild
(binNMU will suffice in this case).
The PCRE library updates in Erlang infrequently (approximately one
time per year),
so I don't think that it'd be a serious burden to the maintainers.
Alternatively, one could try to convince Elixir authors not to
precompile regex on creation
(or to patch it).
Cheers!
--
Sergei Golovan
Bug#926628: I suggest to add libmariadb3 to the list
Hi Ivo, On Wed, Apr 10, 2019 at 2:35 PM Ivo De Decker wrote: > > Hi, > > On Wed, Apr 10, 2019 at 10:24:25AM +0300, Sergei Golovan wrote: > > The problem with the package is that it doesn't link to a specific > > mysql or mariadb client library, but searches for it in runtime by > > name and loads it dynamically. So we can't use the shlibdeps mechanism > > to construct the dependencies list as usual. > > Is there a specific reason why this isn't done? Wouldn't it be better to just > link to the client library the way other packages do? Obviously, such a change > would be for after the buster release. That's the way the upstream code is written. It uses Tcl_LoadFile() to load the library dynamically at the runtime. I'm afraid that to make it work with pre-linked library would mean rewriting a portion of the code. Cheers! -- Sergei Golovan
Bug#926628: I suggest to add libmariadb3 to the list
Hi! The problem with the package is that it doesn't link to a specific mysql or mariadb client library, but searches for it in runtime by name and loads it dynamically. So we can't use the shlibdeps mechanism to construct the dependencies list as usual. I'd suggest to add another alternative libmariadb3 (with a patch which adds libmariadb.so.3 to the library search list). We'll upload the fixed version shortly. Cheers! -- Sergei Golovan
Bug#921792: closing 921792
close 921792 1.2.1-3 thanks The bug is fixed by the recent texlive update.
Bug#924188:
Hi!
In the short run, while the new packages won't be able to enter
buster, I would just make knxd-dev depend on knxd-tools (=
${binary:Version}). But for the next release cycle slitting out the
library would be preferable.
Cheers!
--
Sergei Golovan
Bug#923781: Set locale to C for a build
Hi! Apparently, python-tesserocr tests don't work if the system locale differs from "C". The simple patch fixes this FTBFS: --- a/debian/rules +++ b/debian/rules @@ -5,6 +5,7 @@ export PYBUILD_NAME=tesserocr export DEB_BUILD_MAINT_OPTIONS = hardening=+all +export LC_ALL=C %: dh $@ --with python3 --buildsystem=pybuild (I've tried setting LANG, but it wouldn't be sufficient for some reason.) Cheers! -- Sergei Golovan
Bug#921792: Did you filed a bug for manual testing transition? (Was: log4c: FTBFS (LaTeX error))
Hi Andreas, On Mon, Mar 4, 2019 at 7:50 PM Andreas Tille wrote: > > Hi Sergei, > > thanks for your upload of log4c and fixing the open bugs. Since the > testing transition will not happen before deep freeze. So did you > followed "Applying for an unblock"[1] and filed a bug report against > release.debian.org (I've checked BTS but did not found a bug)? Looks like I overlooked something. My upload doesn't fix 921792, I'm afraid. The package successfully builds on sid, but not on buster (I've just checked). Also, I've checked if the original 1.2.1-3 builds on sid, and it does (looks like the newer texlive packages fixed it)! Another concern is that the diff between 1.2.1-3 and 1.2.4-1 is fairly large. I'm not sure it justifies a freeze exception. So, as for now I'd do the following: 1) reopen the bug 2) wait until the texlive enters buster and then close the bug for 1.2.1-3 (which will cancel the package autoremoval) 3) keep 1.2.4-1 for bullseye Cheers! -- Sergei Golovan
Bug#917758: A fix candidate
Hi, Simon! On Tue, Jan 29, 2019 at 1:05 AM Simon Josefsson wrote: > > Hi Sergei! We worked on this precisely at the same time! I just Nice timing! > uploaded 2.7.0-1 which incorporates upstream's solution to this > problem. I think it is a cleaner approach than to patch 2.6.1, and we Definitely, It's better to incorporate the fix upstream. > still have time before the freeze. Sorry for not noticing your push > before doing the upload, but I merged your changelog entry to give you > credit for this. What do you think? It's unnecessary, as long as the bug is fixed. :-) Cheers! -- Sergei Golovan
Bug#917758: A fix candidate
Hi Simon, I've pushed a possible fix for this bug: https://salsa.debian.org/xmpp-team/jabberd2/commit/c2d181c5eed5b2d83de99eb87626253fe512f019 If it's okay to you, I could upload it. Cheers! -- Sergei Golovan
Bug#916231: Including sys/ioctl.h helps
Hey Ralf, Including sys/ioctl.h into ossp.h doesn't help as it is included into osspd.c too late (sys/socket.h already did harm by undefining IOC_IN and IOC_OUT). But including sys/ioctl.h directly into osspd.c before sys/socket.h works. Here is a possible patch: --- a/osspd.c +++ b/osspd.c @@ -22,6 +22,7 @@ #include #include #include +#include #include #include #include Hopefully, it won't cause damage for other architectures. Cheers! -- Sergei Golovan
Bug#896087: [Pkg-tcltk-devel] Bug#896087: tcl8.5: Time to remove from Debian
Control: clone 896087 -1 Control: reassign -1 ftp.debian.org Control: retitle -1 RM: tcl8.5 -- ROM; obsolete Control: affects -1 src:tcl8.5 On Thu, Apr 19, 2018 at 1:54 PM Sergei Golovan wrote: > > Tcl/Tk 8.5 has reached its end-of-life, so it's time to remove it from Debian. > Applications which use Tcl/Tk should switch to 8.6 which is now a supported > version. As far as I can see, all packages except din have moved to tcl8.6. Cheers! -- Sergei Golovan
Bug#909941: [Pkg-erlang-devel] erlang 21.1+dfsg-1 causes rabbitmq-server to fail to start/install
Hi Paul, On Sun, Oct 7, 2018 at 9:56 PM Paul Gevers wrote: > > On 07-10-18 19:26, Paul Gevers wrote: > > On Sun, 30 Sep 2018 12:54:10 +0100 Jose Antonio Ortega Ruiz > > wrote: > >> This version of the server fails to start using systemd: > > > > Yes, but until recently it worked. So this is a regression caused by > > some other package. According to [1] rabbitmq-server doesn't work with Erlang 21 prior to version 3.7.7, so I guess I can't do much with this bug except probably adding the 'breaks' header to debian/control. It's just time to update rabbitmq-server. Cheers! -- Sergei Golovan
Bug#891098: NMU sugegstion
Hi Onur, I've prepared a NMU with the Stefano's patch. If you don't mind, I'd like to upload it. The diff is attached. Cheers! -- Sergei Golovan gumbo-parser_0.10.1+dfsg-2.3.debdiff Description: Binary data
Bug#898170: closing 898170
close 898170 thanks
Bug#898173: planets: you can't use ${ocaml:Depends} in architecture:all packages
Package: planets
Version: 0.1.13-18
Severity: grave
Justification: renders package unusable
Dear Maintainer,
The planets package 0.1.13-18 uses ${ocaml:Depends} substitution variable
in debian/control. It would be great if the package were
architecture-dependent. But since it isn't, the debian/control now contains
dependency on virtual liblabltk-ocaml-l9fi9 picked from an amd64 arch,
and can't be satisfied on any other arch (on i386 it's liblabltk-ocaml-pc510
for example).
That's why it can't still be in testing despite of more than 3-month delay.
-- System Information:
Debian Release: 9.4
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'stable-debug'), (500, 'proposed-updates'), (500, 'stable'), (500,
'oldstable'), (1, 'experimental'), (1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages planets depends on:
pn liblabltk-ocaml
pn liblabltk-ocaml-l9fi9
pn ocaml-base-4.01.0
ii ocaml-base-nox [ocaml-base-nox-4.02.3] 4.02.3-9
pn ocaml-base-nox-4.01.0
pn ocaml-base-nox-4.05.0
ii tk8.5 8.5.19-1+b1
planets recommends no packages.
Versions of packages planets suggests:
pn doc-base
Bug#898170: planets: depends on deprecated Tcl/Tk 8.5
Source: planets Version: 0.1.13-17 Severity: serious Tags: buster Dear Maintainer, The planets package currently in testing still dpends on a deprecated Tcl/Tk 8.5 which is to be removed from Debian. (I know that the bug is fixed in sid, and I'll happily close it myself after the fixed package will enter testing.) -- System Information: Debian Release: 9.4 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), (1, 'unstable'), (1, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#897429: [Pkg-tcltk-devel] Bug#897429: ppc64el: Shared Object not available in the platform
Hi Bruno, If you have access to the ppc64el hardware, could you test the fix (I've attached a diff, which is to be applied to the 2.1.0-15 sources)? If it's okay, I'll ask the release team about a stable update. Cheers! -- Sergei Golovan diff -Nru tclreadline-2.1.0/debian/changelog tclreadline-2.1.0/debian/changelog --- tclreadline-2.1.0/debian/changelog 2016-10-08 12:04:28.0 +0300 +++ tclreadline-2.1.0/debian/changelog 2016-10-08 12:04:28.0 +0300 @@ -1,3 +1,10 @@ +tclreadline (2.1.0-15+deb9u1) stretch; urgency=medium + + * Add a patch by Breno Leitao which fixes building the shared library for + the ppc64el architecture (closes: #897429). + + -- Sergei Golovan <sgolo...@debian.org> Sat, 08 Oct 2016 12:04:28 +0300 + tclreadline (2.1.0-15) unstable; urgency=low * Fixed implicit function declararion warning (replaced the deprecated diff -Nru tclreadline-2.1.0/debian/patches/ppc64el.patch tclreadline-2.1.0/debian/patches/ppc64el.patch --- tclreadline-2.1.0/debian/patches/ppc64el.patch 1970-01-01 03:00:00.0 +0300 +++ tclreadline-2.1.0/debian/patches/ppc64el.patch 2016-10-08 12:04:28.0 +0300 @@ -0,0 +1,15 @@ +Author: Breno Leitao +Description: Patch fixes building the shared library for ppc64el. +Last-Modified: Wed, 02 May 2018 21:11:16 +0300 +Debian-Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897429 + +--- a/aux/ltconfig b/aux/ltconfig +@@ -2000,7 +2000,6 @@ + else + # Only the GNU ld.so supports shared libraries on MkLinux. + case "$host_cpu" in +-powerpc*) dynamic_linker=no ;; + *) dynamic_linker='Linux ld.so' ;; + esac + fi diff -Nru tclreadline-2.1.0/debian/patches/series tclreadline-2.1.0/debian/patches/series --- tclreadline-2.1.0/debian/patches/series 2016-10-08 12:04:28.0 +0300 +++ tclreadline-2.1.0/debian/patches/series 2016-10-08 12:04:28.0 +0300 @@ -12,3 +12,4 @@ functions.patch ding.patch stubs.patch +ppc64el.patch
Bug#897429: [Pkg-tcltk-devel] Bug#897429: ppc64el: Shared Object not available in the platform
tags 897429 + stretch fixed 897429 2.3.1+dfsg-1 thanks Hi Breno, On Wed, May 2, 2018 at 5:12 PM Breno Leitao <lei...@debian.org> wrote: > Dear maintainer, > I just found that this package is not generating the shared object for > ppc64el platform, as showed below: >dpkg -c tcl-tclreadline_2.1.0-15_ppc64el.deb | grep lib/powerpc64le-linux-gnu >drwxr-xr-x root/root 0 2016-10-08 05:04 ./usr/lib/powerpc64le-linux-gnu/ >-rw-r--r-- root/root 25340 2016-10-08 05:04 ./usr/lib/powerpc64le-linux-gnu/libtclreadline.a Right, it's missing. > Looking at the 'configure' process, I see the failure on detecting if > the shared object should be built. This is the build log line and > explains the problem. >checking whether to build shared libraries... no > I checked against unstable/buster version (2.3) and this problem does > not happen anymore. So, this fix will only need to make Stretch. > The real cause of this problem is realted to the following exemption of > powerpc, which might be removed. > case "$host_cpu" in > powerpc*) dynamic_linker=no ; > *) dynamic_linker='Linux ld.so' ;; > With the patch above, I can see the shared objects being generated: Thank you for the analysis and for the bugreport. I'll release the fix and update the package in stretch in a few days. Cheers! -- Sergei Golovan
Bug#888678: Please NMU dirdiff
Hi Tomas, On Sat, Apr 28, 2018 at 10:17 PM Tomas Pospisek <t...@sourcepole.ch> wrote: > Hello Sergei, > dirdiff is going to be removed from unstable/testing on the 5th of Mai. > Unless you have been in communication with Santiago and he has a plan > on how to move forward with this issue, I'd ask you to please do the NMU. Santiago haven't contacted me, but okay, I'll do NMU. > I am no tcl/tk expert but I have read your patch and it looks good to me. > So, unless Santiago objects, I'd ask you to please NMU. > Also, it'd be nice, if you could tell upstream (Paul Mackerras) about the > fixes so it gets included upstream. It's actually not a proper fix, but just a way to use legacy programs without having to change their code. On the other hand, the last dirdiff release was in 2005. I'm not sure the upstream author is interested in porting it to the newer Tcl/Tk. Cheers! -- Sergei Golovan
Bug#896087: tcl8.5: Time to remove from Debian
Source: tcl8.5 Severity: serious Dear Maintainer, Tcl/Tk 8.5 has reached its end-of-life, so it's time to remove it from Debian. Applications which use Tcl/Tk should switch to 8.6 which is now a supported version. -- System Information: Debian Release: 9.4 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), (1, 'unstable'), (1, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#896085: tk8.5: Time to remove from Debian
Source: tk8.5 Severity: serious Dear Maintainer, Tcl/Tk 8.5 has reached its end-of-life, so it's time to remove it from Debian. Applications which use Tcl/Tk should switch to 8.6 which is available for a few years already. -- System Information: Debian Release: 9.4 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), (1, 'unstable'), (1, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#894282: openssl: Missing quotes in c_rehash
Package: openssl Version: 1.1.0h-1 Severity: grave Dear Maintainer, In the latest openssl package there's a regression in c_rehash script. Quotes are missing in lines 15 and 16: my $dir = /usr/lib/ssl; my $prefix = /usr; This makes Perl treat the lines as regexps which makes the script unusable. It affects configuration of ca-certificates (it's not installable in sid at the moment) therefore I set the severity to grave. -- System Information: Debian Release: 9.4 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), (1, 'unstable'), (1, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openssl depends on: ii libc6 2.24-11+deb9u3 ii libssl1.1 1.1.0f-3+deb9u1 openssl recommends no packages. Versions of packages openssl suggests: ii ca-certificates 20161130+nmu1 -- no debconf information
Bug#892710: [Pkg-tcltk-devel] Bug#892710: {tcl, tk}-i{tcl, tk}4-{dev, doc}: missing Conflicts: i{tcl, tk}-{dev, doc}
Hi Andreas,
On Wed, Mar 14, 2018 at 4:58 AM, Andreas Beckmann <a...@debian.org> wrote:
>
> Hi,
>
> unfortunately i{tcl,tk}3-dev in stretch did not provide a virtual
> package, so you'll need Breaks+Replaces or Conflicts against the real
> packages. (Sorry, didn't check the -dev packages in detail, just assumed
> they worked similarily to the -doc packages.)
Sorry, I missed this too. I'll add the necessary conflicts shortly.
Cheers!
--
Sergei Golovan
Bug#734837: tk8.4: Time to remove from testing
On Thu, Mar 9, 2017 at 2:30 PM, Mattia Rizzolo <mat...@debian.org> wrote: > > Where did you ask? About 3 years ago, some time after this bug was reported and tcl8.4 and tk8.4 has been removed from testing. > Last years I asked the removal of countless packages, that I'm very > positive there were some ports package still depending on it and thus > got broken by the removal. Nobody ever spoke up for those, nor > complained. Okay, good to hear that. > > Besides, 8.5 and 8.6 is built everwhere, if any single package didn't > manage to build against a newer tcl/tk is not an excuse to keep 8.4 > around for so long… > >> I definitely don't object in removing tcl8.4 and tk8.4 from unstable. > > So are you fine if I file a RoQA for those? (or will send a ROM?) I'll send a ROM. I think it's nicer to do that. Cheers! -- Sergei Golovan
Bug#734837: tk8.4: Time to remove from testing
Hi Mattia, On Thu, Mar 9, 2017 at 10:52 AM, Mattia Rizzolo <mat...@debian.org> wrote: > On Thu, Mar 09, 2017 at 10:43:49AM +0300, Sergei Golovan wrote: >> Unfortunately, there're still reverse dependencies in the archive. > > Not really. > >> For example, >> mozart on kfreebsd-i386 > > I've already took care of it, by asking for the removal of that outdated > binary. Thank you :-) > >> and some other unofficial ports still depend on tcl8.4 and tk8.4. > > I'm not convinced you/we should care of outdated ports when considering > removal of very old package like this. Besides, can you even > effectively check for rdeps on all of ports.debian.org? (note that > ftpmasters processing removals don't check ports either) Well, last time when I asked to remove tcl8.4 and tk8.4 the reason for retaining them was that there are still binary reverse dependencies. > >> So, it's a bit more complicated than just file an RM bugreport. > > I can probably help with that, I've got some experience at handling > deprecation and removals of packages from the archive, but this one > feels straightforward to me. I'll appreciate your help in this. I definitely don't object in removing tcl8.4 and tk8.4 from unstable. Also, I have plans to remove tcl8.5 and tk8.5 as well (after stretch is released and their reverse dependencies are ported to 8.6). Cheers! -- Sergei Golovan
Bug#734837: tk8.4: Time to remove from testing
Hi Mattia, On Thu, Mar 9, 2017 at 12:52 AM, Mattia Rizzolo <mat...@debian.org> wrote: > On Fri, Jan 10, 2014 at 11:16:14AM +0400, Sergei Golovan wrote: >> It's time to remove Tk 8.4 from testing. > > 3+ years passed, there are no reverse dependencies left in the archive. > Can we also remove it from unstable too? (same for tcl 8.4). Unfortunately, there're still reverse dependencies in the archive. For example, mozart on kfreebsd-i386 and some other unofficial ports still depend on tcl8.4 and tk8.4. So, it's a bit more complicated than just file an RM bugreport. Cheers! -- Sergei Golovan
Bug#847556: Proposed patch
tags 847556 + patch
thanks
Hi again,
I took a look at the code and came up with a patch which fixes the SSL
connection problem (attached).
The patch simply specifies the hostname-port pair in one
BIO_set_conn_hostname() call, similar to what I've found in the
OpenSSL manuals. Alternatively, one can use BIO_set_conn_port(), but
still she'd have to convert the port value from an integer to a string
first.
The problem with the current code is that the
BIO_ctrl(iBio,BIO_C_SET_CONNECT,3,(char *)>port) no longer
sets the connection port, but sets the IP family instead in OpenSSL
1.1.
Cheers!
--
Sergei Golovan
Index: src/http_ssl.c
==
--- src/http_ssl.c
+++ src/http_ssl.c
@@ -293,12 +293,14 @@
#endif
SSL_set_mode(ssl, SSL_MODE_AUTO_RETRY);
if( !pUrlData->useProxy ){
-BIO_set_conn_hostname(iBio, pUrlData->name);
-BIO_ctrl(iBio,BIO_C_SET_CONNECT,3,(char *)>port);
+char *connStr;
+connStr = mprintf("%s:%d", pUrlData->name, pUrlData->port);
+BIO_set_conn_hostname(iBio, connStr);
+free(connStr);
if( BIO_do_connect(iBio)<=0 ){
ssl_set_errmsg("SSL: cannot connect to host %s:%d (%s)",
pUrlData->name, pUrlData->port, ERR_reason_error_string(ERR_get_error()));
ssl_close();
return 1;
Bug#847556: fossil: Cannot clone/sync over HTTPS
Package: fossil Version: 1:1.36-1 Severity: grave Justification: renders package unusable Dear Maintainer, The latest update of the fossil package broke cloning/syncing over HTTPS. Currrently (with 1:1.36-1) I get the 'unsupported ip family' error every time I try to use HTTPS with fossil. % fossil clone https://chiselapp.com/user/rkeene/repository/tclreadline tclreadline.fossil SSL: cannot connect to host chiselapp.com:443 (unsupported ip family) Clone done, sent: 0 received: 0 ip: server returned an error - clone aborted It seems like the OpenSSL 1.1 support is buggy yet. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fossil depends on: ii libc6 2.24-7 ii libfuse22.9.7-1 ii libsqlite3-03.15.2-1 ii libssl1.1 1.1.0c-2 ii libtcl8.5 [libtcl] 8.5.19-2 ii libtcl8.6 [libtcl] 8.6.6+dfsg-1 ii zlib1g 1:1.2.8.dfsg-2+b3 fossil recommends no packages. Versions of packages fossil suggests: ii gnupg 2.1.16-2 -- no debconf information
Bug#844593: [Pkg-erlang-devel] Bug#844593: erlang-wx: WX broken due to "-fno-pie -no-pie" CFLAGS/LDFLAGS
Hi Johannes,
On Thu, Nov 17, 2016 at 12:30 PM, Johannes Weißl <jar...@molb.org> wrote:
> Package: erlang-wx
> Version: 1:19.1.6+dfsg-1
> Severity: grave
> Tags: upstream patch
> Justification: renders package unusable
>
> The solution of bug #842998 breaks WX:
>
> 1> observer:start().
> {error,{{load_driver,"No driver found"},
> [{wxe_server,start,1,[{file,"wxe_server.erl"},{line,65}]},
> {wx,new,1,[{file,"wx.erl"},{line,115}]},
> {observer_wx,init,1,[{file,"observer_wx.erl"},{line,104}]},
> {wx_object,init_it,6,[{file,"wx_object.erl"},{line,355}]},
> {proc_lib,init_p_do_apply,3,
>[{file,"proc_lib.erl"},{line,247}]}]}}
>
> =ERROR REPORT 17-Nov-2016::10:12:15 ===
> ERROR: Could not find 'wxe_driver.so' in:
> /usr/lib/erlang/lib/wx-1.7.1/priv
Sorry, I've missed this.
>
> What works is to remove "-fno-pie -no-pie" from CFLAGS and LDFLAGS in
> debian/rules and to apply the following two upstream patches:
>
> -
> https://github.com/erlang/otp/commit/5aa13e16ae81050509fceaf603650fc8594af7ec.patch
> -
> https://github.com/erlang/otp/commit/edfa3b87542687baa2530a41241eb83d9afda1fb.patch
>
> (both are necessary).
Thank you for the patches. I'll upload the updated package soon.
Cheers!
--
Sergei Golovan
Bug#828566: Proposed NMU
tags 828566 + patch
thanks
Hi, Muammar,
I'd like to offer a patch which ports tcltls to the new Openssl 1.1.
It's already forwarded upstream
(https://sourceforge.net/p/tls/bugs/66/) though I don't know when it
(or some other patch) will be accepted. The changes are mostly
straightforward, the patch retains compatibility with OpenSSL 1.0, and
the package passes regression tests.
If you don't mind, I could do NMU for this bugfix.
Cheers!
--
Sergei Golovan
diff -Nru tcltls-1.6.7+dfsg/debian/changelog tcltls-1.6.7+dfsg/debian/changelog
--- tcltls-1.6.7+dfsg/debian/changelog 2016-05-29 14:54:10.0 +0300
+++ tcltls-1.6.7+dfsg/debian/changelog 2016-11-07 16:40:21.0 +0300
@@ -1,3 +1,10 @@
+tcltls (1.6.7+dfsg-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Added a patch which fixes FTBFS with OpenSSL 1.1 (closes: #828566).
+
+ -- Sergei Golovan <sgolo...@debian.org> Mon, 07 Nov 2016 16:40:21 +0300
+
tcltls (1.6.7+dfsg-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru tcltls-1.6.7+dfsg/debian/patches/openssl1.1
tcltls-1.6.7+dfsg/debian/patches/openssl1.1
--- tcltls-1.6.7+dfsg/debian/patches/openssl1.1 1970-01-01 03:00:00.0
+0300
+++ tcltls-1.6.7+dfsg/debian/patches/openssl1.1 2016-11-06 23:48:18.0
+0300
@@ -0,0 +1,410 @@
+Author: Sergei Golovan <sgolo...@debian.org>
+Description: Patch ports the tcltls to the new OpenSSL 1.1 API.
+Last-Modified: Sun, 30 Oct 2016 23:08:28 +0300
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828566
+Bug-Upstream: https://sourceforge.net/p/tls/bugs/66/
+Forwarded: yes
+
+--- a/tls.c
b/tls.c
+@@ -115,15 +115,29 @@
+ static DH *get_dh2048()
+ {
+ DH *dh=NULL;
++BIGNUM *p=NULL, *g=NULL;
+
+-if ((dh=DH_new()) == NULL) return(NULL);
++p=BN_bin2bn(dh2048_p,sizeof(dh2048_p),NULL);
++if (p == NULL) goto err;
+
+-dh->p=BN_bin2bn(dh2048_p,sizeof(dh2048_p),NULL);
+-dh->g=BN_bin2bn(dh2048_g,sizeof(dh2048_g),NULL);
++g=BN_bin2bn(dh2048_g,sizeof(dh2048_g),NULL);
++if (g == NULL) goto err;
+
+-if ((dh->p == NULL) || (dh->g == NULL))
+- return(NULL);
++if ((dh=DH_new()) == NULL) goto err;
++
++#if OPENSSL_VERSION_NUMBER < 0x1010L
++dh->p=p;
++dh->g=g;
++#else
++if (!DH_set0_pqg(dh, p, NULL, g)) goto err;
++#endif
+ return(dh);
++
++err:
++if (p) BN_free(p);
++if (g) BN_free(g);
++if (dh) DH_free(dh);
++return(NULL);
+ }
+ #endif
+
+@@ -160,7 +174,10 @@
+ #define OPENSSL_THREAD_DEFINES
+ #include
+
+-#ifdef OPENSSL_THREADS
++static Tcl_Mutex init_mx;
++static int initialized;
++
++#if defined(OPENSSL_THREADS) && OPENSSL_VERSION_NUMBER < 0x1010L
+ #include
+
+ /*
+@@ -169,8 +186,6 @@
+ */
+
+ static Tcl_Mutex locks[CRYPTO_NUM_LOCKS];
+-static Tcl_Mutex init_mx;
+-static int initialized;
+
+ static void CryptoThreadLockCallback (int mode, int n, const char
*file, int line);
+ static unsigned long CryptoThreadIdCallback (void);
+@@ -310,7 +325,7 @@
+ Tcl_Obj *cmdPtr, *result;
+ char *errStr, *string;
+ int length;
+-SSL *ssl= (SSL*)X509_STORE_CTX_get_app_data(ctx);
++SSL *ssl= (SSL*)X509_STORE_CTX_get_ex_data(ctx,
SSL_get_ex_data_X509_STORE_CTX_idx());
+ X509 *cert = X509_STORE_CTX_get_current_cert(ctx);
+ State *statePtr = (State*)SSL_get_app_data(ssl);
+ int depth = X509_STORE_CTX_get_error_depth(ctx);
+@@ -554,14 +569,14 @@
+ }
+ switch ((enum protocol)index) {
+ case TLS_SSL2:
+-#if defined(NO_SSL2)
++#if defined(NO_SSL2) || OPENSSL_VERSION_NUMBER >= 0x1010L
+ Tcl_AppendResult(interp, "protocol not supported", NULL);
+ return TCL_ERROR;
+ #else
+ ctx = SSL_CTX_new(SSLv2_method()); break;
+ #endif
+ case TLS_SSL3:
+-#if defined(NO_SSL3)
++#if defined(NO_SSL3) || OPENSSL_VERSION_NUMBER >= 0x1010L
+ Tcl_AppendResult(interp, "protocol not supported", NULL);
+ return TCL_ERROR;
+ #else
+@@ -754,12 +769,12 @@
+ #ifndef OPENSSL_NO_TLSEXT
+ char *servername = NULL; /* hostname for Server Name Indication */
+ #endif
+-#if defined(NO_SSL2)
++#if defined(NO_SSL2) || OPENSSL_VERSION_NUMBER >= 0x1010L
+ int ssl2 = 0;
+ #else
+ int ssl2 = 1;
+ #endif
+-#if defined(NO_SSL3)
++#if defined(NO_SSL3) || OPENSSL_VERSION_NUMBER >= 0x1010L
+ int ssl3 = 0;
+ #else
+ int ssl3 = 1;
+@@ -1069,13 +1084,13 @@
+ }
+
+ /* create SSL context */
+-#if defined(NO_SSL2)
++#if defined(NO_SSL2) || OPENSSL_VERSION_NUMBER >= 0x1010L
+ if (ENABLED(proto, TLS_PROTO_SSL2)) {
+ Tcl_AppendResult(interp, "protocol not supported", NULL);
+ return (SSL_CTX *)0;
+ }
+ #endif
+-#if defined(NO_SSL3)
++#if defined(NO_SSL3) || OPENSSL_VERSION_NUMBER >= 0x1010L
+ if (ENABLED(proto, TLS_PROTO_SSL3))
Bug#828427: Upstream fix
Hi, It seems that upstream is already fixed this bug in git: https://github.com/brunoos/luasec/commit/4889830d53c19e915959eb778e25bb303b9d3cf0 Cheers! -- Sergei Golovan
Bug#837234: [Pkg-erlang-devel] Bug#837234: rebar: FTBFS: Uncaught error in rebar_core: {'EXIT',
Hi!
On Sat, Sep 10, 2016 at 11:46 AM, Sergei Golovan <sgolo...@nes.ru> wrote:
> Hi!
>
> On Sat, Sep 10, 2016 at 10:26 AM, Lucas Nussbaum <lu...@debian.org> wrote:
>>
>> During a rebuild of all packages in sid, your package failed to build on
>> amd64.
>>
>>> Uncaught error in rebar_core: {'EXIT',
>>>{undef,
>>> [{crypto,start,[],[]},
>
> The problem is that in the newer Erlang erlang-tools no longer pulls
> out the erlang-crypto package (it depended on erlang-crypto implicitly
> via erlang-inets and then erlang-ssl). So, erlang-crypto must be added
> to the build dependencies list explicitly now.
Also, erlang-crypto has to be added to the rebar dependencies list.
Otherwise, rebar won't start.
Moreover, looking through the rebar sources I've found quite a few
modules it uses directly, which packages can be added to the
dependencies list as well. The full list is:
erlang-asn1 (used in rebar_asn1_compiler only)
erlang-base
erlang-crypto
erlang-dialyzer (used in rebar_dialyzer.erl only)
erlang-diameter (used in rebar_dia_compiler.erl only)
erlang-edoc (used in rebar_edoc.erl only)
erlang-eunit (used in rebar_eunit.erl only)
erlang-reltool (used in rebar_reltool.erl only)
erlang-snmp (used in rebar_erlc_compiler.er only)l
erlang-syntax-tools (used in rebar_erlc_compiler.erl only)
erlang-tools
And finally, a few files mention some external modules (I guess they
are optional):
abnfc (used in rebar_abnfc_compiler.erl)
eflame (used in rebar.erl)
erlydtl (used in rebar_erlydtl_compiler.erl)
gpb_compile (used in rebar_proto_gpb_compiler.erl)
lfe_comp (used in rebar_lfe_compiler.erl)
neotoma (used in rebar_neotoma_compiler.erl)
protobuffs_compile (used in rebar_protobuffs_compiler.erl)
Hope that helps fixing the rebar dependencies.
Cheers!
--
Sergei Golovan
Bug#837234: [Pkg-erlang-devel] Bug#837234: rebar: FTBFS: Uncaught error in rebar_core: {'EXIT',
Hi!
On Sat, Sep 10, 2016 at 10:26 AM, Lucas Nussbaum <lu...@debian.org> wrote:
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
>> Uncaught error in rebar_core: {'EXIT',
>>{undef,
>> [{crypto,start,[],[]},
The problem is that in the newer Erlang erlang-tools no longer pulls
out the erlang-crypto package (it depended on erlang-crypto implicitly
via erlang-inets and then erlang-ssl). So, erlang-crypto must be added
to the build dependencies list explicitly now.
Cheers!
--
Sergei Golovan
Bug#819122: Proposed patch for #819122
tags 819122 + patch thanks Hi! I'd like to propose the following patch to Makefile for the issue (also attached): -- --- a/Makefile +++ b/Makefile @@ -223,12 +223,13 @@ test_stdlib: compile @ echo "==> elixir (exunit)" - $(Q) exec epmd & exit + $(Q) epmd -daemon $(Q) if [ "$(OS)" = "Windows_NT" ]; then \ cd lib/elixir && cmd //C call ../../bin/elixir.bat -r "test/elixir/test_helper.exs" -pr "test/elixir/**/*_test.exs"; \ else \ cd lib/elixir && ../../bin/elixir -r "test/elixir/test_helper.exs" -pr "test/elixir/**/*_test.exs"; \ fi + $(Q) epmd -kill #==> Dialyzer tasks --- basically, it starts epmd as a daemon during test phase and kills it afterwards. Cheers! -- Sergei Golovan elixir-epmd.patch Description: Binary data
Bug#822293: password-gorilla: Cannot save new passwords
Hi Jonathan, I'll fix this bug in the next upload. I'll just allow nettool to invoke /sbin/ifconfig if it can't be found in PATH. Thank you for the report! -- Sergei Golovan
Bug#810889: [Pkg-erlang-devel] Bug#810889: yaws: non-DFSG WSDL .xsd files (no modification?)
On Sun, Apr 17, 2016 at 3:55 PM, Dmitry Smirnov <only...@debian.org> wrote: > Hi Sergei, > > On Sunday, 17 April 2016 12:21:09 PM AEST Sergei Golovan wrote: >> It seems you're right, though modifying a schema is a bit pointless. I >> can remove these files from the Yaws package, but the same or >> essentially the same files are shipped withing other packages as well >> (see [1] for the reference), so I'd wait for you to file bugreports to >> all other packages with the same issue. > > I can't believe how easily you've subscribed me for filing bugs about this > problem to all affected packages. ;) > It might take a while though and if I were you I wouldn't wait much longer... Well, I guess you understand that removing the susceptible files from the yaws package will not fix the bug you reported. So, if you're not really interested in fixing this just tell me, and I'll just close it. > >> May be we all will come to some more resonable agreement together. > > I'm quite sceptical about this as I don't see many options here as > I doubt we would be able to find compromise between DFSG and non-free > licensing terms... Maybe, maybe not. The authors' intention is what matters. Cheers! -- Sergei Golovan
Bug#810889: [Pkg-erlang-devel] Bug#810889: yaws: non-DFSG WSDL .xsd files (no modification?)
Hi Dmitry, On Wed, Jan 13, 2016 at 3:11 PM, Dmitry Smirnov <only...@debian.org> wrote: > > Files: > priv/wsdl11soap12.xsd > priv/soap.xsd > priv/wsdl.xsd > > are licensed under "WSDL" licenses allowing only distribution and explicitly > prohibiting everything else: "No other rights are granted by implication, > estoppel or otherwise.". > > I'm particularly concerned about modification rights that appears to be > prohibited. It seems you're right, though modifying a schema is a bit pointless. I can remove these files from the Yaws package, but the same or essentially the same files are shipped withing other packages as well (see [1] for the reference), so I'd wait for you to file bugreports to all other packages with the same issue. May be we all will come to some more resonable agreement together. [1] https://codesearch.debian.net/results/No%20other%20rights%20are%20granted%20by%20implication/page_0 Cheers! -- Sergei Golovan
Bug#802400: [Pkg-erlang-devel] Bug#802400: Bug#802400: erlang: FTBFS: FOP - Exception
block 802400 by 799662 thanks On Tue, Oct 20, 2015 at 7:43 AM, Sergei Golovan <sgolo...@nes.ru> wrote: > > I'd say that It's not a bug in Erlang but a bug in fop. Likely, it's > bug #799662. I haven't had time to confirm yet whether it's really > #799662 and whether the patch to #799662 fixes it. I'll do that in a > few days. I confirm that after applying the patch from #799662 to fop Erlang build is fixed. So, I'll bump the severity of #799662 at the moment. Cheers! -- Sergei Golovan
Bug#802400: [Pkg-erlang-devel] Bug#802400: erlang: FTBFS: FOP - Exception
Hi Chris, On Tue, Oct 20, 2015 at 12:40 AM, Chris West (Faux) <solo-debianb...@goeswhere.com> wrote: > Source: erlang > Version: 1:18.0-dfsg-2 > Severity: serious > Justification: fails to build from source > Tags: sid stretch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > The package fails to build: I'd say that It's not a bug in Erlang but a bug in fop. Likely, it's bug #799662. I haven't had time to confirm yet whether it's really #799662 and whether the patch to #799662 fixes it. I'll do that in a few days. Thank you for the report! -- Sergei Golovan
Bug#734838: [Pkg-tcltk-devel] Bug#734838: Many applications depend on tcl8.4
Hi Nye, On Thu, Oct 8, 2015 at 9:50 PM, Nye Liu <n...@nyet.org> wrote: > It looks like it is already missing from testing, which broke a bunch of > my old apps. Well, Tcl/Tk 8.4 is discontinued upstream, version 8.5 is available for almost 8 years already, so we can't ship 8.4 with Debian any more. > > Is there a interim or compatibility package for tcl8.4 and libtcl8.4 in > testing or stable? There's no such packages. If you absolutely need Tcl/Tk 8.4 you can grap the packages from unstable. They are still available. Cheers! -- Sergei Golovan
Bug#790625: [Pkg-erlang-devel] Bug#790625: FTBFS: erlang:now/0: Deprecated BIF
Hi Martin, On Tue, Jun 30, 2015 at 3:56 PM, Martin Michlmayr t...@hp.com wrote: yaws fails to build in unstable: I'm aware of this bug and will upload a fix in a few days. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781839: CVE-2015-2774
Hi Moritz! I'm not an expert in SSL, so I can't really say if it's a real threat. But i think I'd better prepare a patched package for jessie. Should I do it for wheezy also? (Note, that we decided not to bother disabling SSLv3 for the erlang-ssl currently in wheezy.) On Fri, Apr 3, 2015 at 8:07 PM, Moritz Muehlenhoff j...@debian.org wrote: Source: erlang Severity: grave Tags: security (Feel free to downgrade the severity, I don't have a full picture of Erlang's SSL implementation) This has been assigned CVE-2015-2774: http://openwall.com/lists/oss-security/2015/03/27/9 Fix is here: https://github.com/erlang/otp/commit/e53c55dd0ab69982bc511396ccf8655d27c6d38c Cheers, Moritz -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780439: [Pkg-tcltk-devel] Bug#780439: tcl8.6: upgrade issues switching from tcl8.4/wheezy to tcl/jessie
Hi Andreas, On Sat, Mar 14, 2015 at 1:06 AM, Andreas Beckmann a...@debian.org wrote: Hi, analyzing some piuparts logs in depth showed an issue with fsl being hold at the wheezy version rather than being upgraded. This is caused by the switch from tcl8.4 to tcl which requires removal of the old tcl8.4 package. This seems to work well in most upgrade paths, but unfortunately in this case the scoring resulted in a tie, and that is resolved in favor of the already installed package. There may be more upgrade paths involving other packages hitting this issue ... Adding some Breaks to libtcl8.6 (which has a slightly higher score than tcl due to a higher number of rdepends) will help apt to resolve this upgrade path in favor of the new tcl package. The versions I've taken from the Breaks found in the tcl and tk packages. Thank you for the analysis and for the patch. I'll upload the fixed packages shortly. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775635: [Pkg-tcltk-devel] Bug#775635: chiark-tcl: FTBFS in jessie: build-dependency not installable: tcl8.4-dev
Hi Ian! On Sun, Jan 18, 2015 at 3:37 AM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Anyway, I'm a bit puzzled. I uploaded a new version of this package in November 2014 and it built fine. tcl8.4-dev seemed to be available then. I deliberately did not update it to build-depend on 8.5 because I wanted to avoid perturbing what was in testing by potentially introducing depedencies on 8.5-specific aspects of the Tcl ABI. But according to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737104 tcl8.4-dev was removed in January 2014. How did I and the buildds manage to build chiark-tcl 1.1.2 using tcl8.4-dev in November ? https://buildd.debian.org/status/logs.php?pkg=chiark-tcl Tcl/Tk 8.4 is removed from jessie, and not removed from sid yet (a few packages still depend on it). This means that if you upload a package to unstable it will happily find tcl8.4-dev but it won't be able to go to testing. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774890: [Pkg-tcltk-devel] Bug#774890: itk3: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
Hi Andreas, On Thu, Jan 8, 2015 at 8:46 PM, Andreas Beckmann a...@debian.org wrote: Hi, an upgrade test with piuparts revealed that your package installs files over existing symlinks and possibly overwrites files owned by other packages. This usually means an old version of the package shipped a symlink but that was later replaced by a real (and non-empty) directory. This kind of overwriting another package's files cannot be detected by dpkg. This was observed on the following upgrade paths: lenny - squeeze - wheezy - jessie The errors seems to date back to the lenny-squeeze update ... Yes, I see that. But I'm not sure if this bug is serious for now. And since even squeeze is already discontinued I'm not sure if this can be qualified as a bug at all. Though I can add calls to dpkg-maintscript-helper to the itk3 maintainer's scripts for jessie. It'll fix the overwriting the itcl3 package files, but upgrade path lenny-squeeze-wheezy-jessie will still fail leaving a few files unowned after the packages wil be purged (they are left from upgrades lenny-squeeze and squeeze-jessie): /usr/share/doc/itcl3/CHANGES.gznot owned /usr/share/doc/itcl3/INCOMPATIBLE.gz not owned /usr/share/doc/itcl3/README.gz not owned /usr/share/doc/itcl3/TODO not owned /usr/share/doc/itcl3/changelog.gz not owned But anyway, I'm tempted to just close this bugreport since it's reproducible for upgrades from really old distribution. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751767: libBLT changes SONAME without changing package name
Hi Ivo, On Sat, Nov 29, 2014 at 8:26 PM, Ivo De Decker iv...@debian.org wrote: But the packages currently in testing can be installed with the old blt version, which doesn't work. Well, the concern is about the packages which are currently in wheezy and depend on blt (= 2.4). They can be installed with blt currently in jessie, which will break them. The packages which are currently in testing can be installed only with BLT currently in testing or unstable, and they work fine with both of these blt versions. I unblocked the version of blt currently in unstable, to allow it to migrate to testing. All that packages that depend on blt need to be rebuilt. I'm It's not necessary, because they work fine as they are now. And they can't be installed together with blt from wheezy (depend on blt=2.5.3). So, after the new blt will hit testing partial upgrades will not be possible either way. scheduling binnmu's for them. Once that's done, you should do a new upload, removing the blt binary package, as it would be wrong to keep it around (I'll let you know when you can do the upload). Therefore, I'm not closing this bug now. I'm not going to remove the blt package. I want it to be installable as easy as apt-get install blt. And I don't see how this is bad now (except for not very pretty 'breaks' in its debian/control).. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751767: libBLT changes SONAME without changing package name
On Sun, Nov 16, 2014 at 6:20 PM, Jonathan Wiltshire j...@debian.org wrote: That presumably makes this package undistributable, or have I misunderstood? Yes, I think so as well. Fortunately, these files aren't important for the BLT library at all. In fact, I've found only one piece of software which ever uses one function from these sources (see the reference for dd_send_text in [1]). So, I believe I could just repackage the source package to make it distributable. [1] https://searchcode.com/codesearch/view/16892304/ Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769814: blt: non-distributable files library/dd_protocols/*.tcl
Source: blt Severity: serious Justification: Policy 2.3 Dear Maintainer, The blt source package currently includes files library/dd_protocols/dd-color.tcl library/dd_protocols/dd-file.tcl library/dd_protocols/dd-number.tcl library/dd_protocols/dd-text.tcl with the following copyright information: Copyright (c) 1993 ATT All Rights Reserved Theere's nothing in the files which would indicate that they are free software. It makes the blt package non-distributable. But since these files aren't essential for the binary package (they are basically examples which users can live without, there's a single reference found for the functions defined in them: see [1]), I think we can just repackage the sources removing these files and code in makefiles which installs them). [1] https://searchcode.com/codesearch/view/16892304/ (search for dd_send_text) -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751767: libBLT changes SONAME without changing package name
On Sat, Nov 15, 2014 at 12:50 PM, Julien Cristau jcris...@debian.org wrote: You can't keep a dummy package on SONAME changes, since it doesn't actually provide the ABI older versions of its rdeps expect. I've added 'Breaks' header for all packages that depended on the older library. Specifically it is: Breaks: tclspice ( 26-1~), tkdesk ( 2.0-9.2~), skycat ( 3.1.2+starlink1~b-7~), python-tk ( 2.7.8-1~), python3-tk ( 3.4.1-3~) This means that there will not be possible to upgrade blt (which pulls in the new library) and leave the dependent packages unapgraded. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751767: libBLT changes SONAME without changing package name
Hi! On Sun, Nov 2, 2014 at 8:05 AM, Julien Cristau jcris...@debian.org wrote: On Sun, Nov 2, 2014 at 13:58:10 +, Simon McVittie wrote: Hello release team, Since this is going to be a transition, and a new upstream SONAME for jessie seems unlikely, should this bug be jessie-ignore'd and fixed for jessie+1 instead? If the SONAME changed between wheezy and jessie then this ought to be fixed for jessie, IMO. I've prepared the fixed packages. Since i've retained the 'blt' package (it became a dummy one), the transition isn't strictly necessary. If a package which build-depends on blt-dev rebuilds, it gets a new dependency on libblt2.5-8.6. Otherwise, it just keeps depending on blt which is fine as blt won't go anywhere. On the other hand, I've reviewed the licenses for the source codes and found a few disturbing files. They are library/dd_protocols/*.tcl (I've attached one of them here). The copyright statement stands: Copyright (c) 1993 ATT All Rights Reserved So, I'm unsure what to do now. Cheers! -- Sergei Golovan dd-text.tcl Description: Tcl script
Bug#767741: Unable to initialize TLS: No SSL/TLS configuration present
tags 767741 + moreinfo
thanks
Hi Alexander,
It seems like you've disabled TLS for your server.
On Sun, Nov 2, 2014 at 1:51 PM, Alexander alex1...@gmx.net wrote:
-- Configuration Files:
/etc/prosody/conf.avail/localhost.cfg.lua changed:
-- Section for localhost
-- enabled = false -- Remove this line to enable this host
-- This allows clients to connect to localhost. No harm in it.
VirtualHost localhost
http_host = localhost -- HTTP requests will be addressed to here
There's no ssl options in localhost.cfg.lua.
/etc/prosody/prosody.cfg.lua changed:
...
-- These are the SSL/TLS-related settings. If you don't want
-- to use SSL/TLS, you may comment or remove this
-- ssl = {
-- key = /etc/prosody/certs/localhost.key;
-- certificate = /etc/prosody/certs/localhost.cert;
--}
The ssl options are commented out.
...
-- Settings under each VirtualHost entry apply *only* to that host.
VirtualHost example.com
enabled = false -- Remove this line to enable this host
-- Assign this host a certificate for TLS, otherwise it would use the
one
-- set in the global section (if any).
-- Note that old-style SSL on port 5223 only supports one
certificate, and will always
-- use the global one.
ssl = {
key = /etc/prosody/certs/example.com.key;
certificate = /etc/prosody/certs/example.com.crt;
}
These options are specified for a disabled virtual host.
-- no debconf information
Content of prosody.err
Nov 02 11:23:11 localhost:tls error Unable to initialize TLS: No SSL/TLS
configuration present for localhost
Nov 02 11:23:11 localhost:tls error Unable to initialize TLS: No SSL/TLS
configuration present for localhost
Client SecureChat unable to connect because SSL is not supported. lua-sec is
installed.
Could you try to add the following lines to your
/etc/prosody/conf.d/localhost.cfg.lua and look if TLS is back after
Prosody restart?
ssl = {
key = /etc/prosody/certs/localhost.key;
certificate = /etc/prosody/certs/localhost.cert;
}
Make sure that /etc/prosody/certs/localhost.key and
/etc/prosody/certs/localhost.cert exist. They should link to
../../ssl/private/ssl-cert-snakeoil.key and
../../ssl/certs/ssl-cert-snakeoil.pem respectively.
Cheers!
--
Sergei Golovan
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751767: libBLT changes SONAME without changing package name
Hi Peter, On Mon, Aug 11, 2014 at 2:07 AM, peter green plugw...@p10link.net wrote: That only partially solves the problem, in particular partial upgrades are still likely to break. Furthermore the problem will recur next time libBLT changes it's soname. I don't expect changing its soname in next few years (or maybe even forever). The package is dead upstream. But you're right. It should be fixed properly. I'll split out the library to libblt2.5-8.6 (which won't work without the Tcl code, so it'll go to libblt2.5-8.6 too making the blt package dummy) and I'll add the necessary 'breaks'. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755336: Patch
tags 755336 + patch thanks Hi! I'd like to offer a patch (and possibly NMU if you don't mind) for this bug and 755102. I can't do much for the other RC bugs, but these two are consequences of my changes in expect, so here's a fix. Cheers! -- Sergei Golovan diff -Nru libexpect-php5-0.3.1/debian/changelog libexpect-php5-0.3.1/debian/changelog --- libexpect-php5-0.3.1/debian/changelog 2012-02-15 00:24:59.0 +0400 +++ libexpect-php5-0.3.1/debian/changelog 2014-07-24 09:06:04.0 +0400 @@ -1,3 +1,11 @@ +libexpect-php5 (0.3.1-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Replaced expect-dev by tcl-expect-dev in build dependencies to adapt +the package to the changes in expect. (Closes: #755102, #755336). + + -- Sergei Golovan sgolo...@debian.org Thu, 24 Jul 2014 09:05:51 +0400 + libexpect-php5 (0.3.1-1) unstable; urgency=low * New upstream release diff -Nru libexpect-php5-0.3.1/debian/control libexpect-php5-0.3.1/debian/control --- libexpect-php5-0.3.1/debian/control 2012-02-15 00:29:26.0 +0400 +++ libexpect-php5-0.3.1/debian/control 2014-07-24 09:03:55.0 +0400 @@ -2,7 +2,7 @@ Section: web Priority: optional Maintainer: Alex Denvir cold...@blueyonder.co.uk -Build-Depends: debhelper (= 7), php5-dev, expect-dev +Build-Depends: debhelper (= 7), php5-dev, tcl-expect-dev Standards-Version: 3.9.2 Homepage: http://pecl.php.net/expect
Bug#755102: libexpect-php5: please update build-depends, expect-dev is gone
Hi Cyril, On Thu, Jul 17, 2014 at 11:30 PM, Cyril Brulebois k...@debian.org wrote: Sergei (in cc): that package needs an update before the old binary can be removed, and so that your package can be a candidate for migration to testing. In the meanwhile, it's not because it has out-of-date binaries. I understand that, thank you for the clarification. Though libexpect-php5 has another two RC bugs, one of which was reported more than 2 years ago (see [1]). I can fix #755102 in NMU, but would this fix be reasonable given that I'm not going to fix #667767 and #752628 (especially the latter). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667767 Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754453: ttt: maintainer address bounces
Hi Ansgar, On Fri, Jul 11, 2014 at 1:58 PM, Ansgar Burchardt ans...@debian.org wrote: Sergei, you did the last two uploads in 2013 and 2014. Are you interested in the package? Not really. I just fixed breakages I've caused by changes in packages ttt depends on. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753794: tkdesk: needs rebuild because BLT is ported to Tcl/Tk 8.6
Source: tkdesk Version: 2.0-9.1 Severity: grave Tags: patch Justification: renders package unusable Dear Maintainer, Since the blt package is built against Tcl/Tk 8.6 tkdesk stopped working and has to be ported to Tcl/Tk 8.6 as well. Unfortunately, simple bin-NMU doesn't suffice (tkdesk uses deprecated interp-result field, which support was dropeed in 8.6). I've prepared a small patch which allows tkdesk to build and I caould do NMU if you don't mind. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -u tkdesk-2.0/debian/changelog tkdesk-2.0/debian/changelog --- tkdesk-2.0/debian/changelog +++ tkdesk-2.0/debian/changelog @@ -1,3 +1,11 @@ +tkdesk (2.0-9.2) unstable; urgency=low + + * Non-maintainer upload. + * Switched to Tcl/Tk 8.6 to work with newer BLT. + * Defined USE_INTERP_RESULT macro to build with Tcl 8.6. + + -- Sergei Golovan sgolo...@debian.org Fri, 04 Jul 2014 07:53:30 +0400 + tkdesk (2.0-9.1) unstable; urgency=low * Non-maintainer upload. diff -u tkdesk-2.0/debian/rules tkdesk-2.0/debian/rules --- tkdesk-2.0/debian/rules +++ tkdesk-2.0/debian/rules @@ -15,7 +15,7 @@ configure: configure-stamp configure-stamp: dh_testdir - ./configure --with-blt=/usr/lib --prefix=/usr --mandir=/usr/share/man --with-tcl=/usr/lib/tcl8.5 --with-tk=/usr/lib/tk8.5 --with-itcl=/usr/lib/itcl3.4 --with-itcl-lib=-litcl3.4 --with-itcl-version=3.4 + ./configure --with-blt=/usr/lib --prefix=/usr --mandir=/usr/share/man --with-tcl=/usr/lib --with-tk=/usr/lib --with-itcl=/usr/lib/itcl3.4 --with-itcl-lib=-litcl3.4 --with-itcl-version=3.4 touch configure-stamp build: build-stamp @@ -23,7 +23,7 @@ build-stamp: configure-stamp dh_testdir - make CC_EXTRA_OPTS=-O2 -g -Wall TKDESK_LIBRARY=$(TKDESK_LIBRARY) + make CC_EXTRA_OPTS=-O2 -g -Wall -DUSE_INTERP_RESULT TKDESK_LIBRARY=$(TKDESK_LIBRARY) touch build-stamp clean: diff -u tkdesk-2.0/debian/control tkdesk-2.0/debian/control --- tkdesk-2.0/debian/control +++ tkdesk-2.0/debian/control @@ -3,7 +3,7 @@ Priority: extra Maintainer: Daniel Martin fiz...@debian.org Standards-Version: 3.6.1.0 -Build-Depends: itcl3-dev ( 3.3), blt-dev, tk8.5-dev (= 8.5.7-2), debhelper ( 5.0.0) +Build-Depends: itcl3-dev ( 3.3), blt-dev (= 2.5.3), tk-dev (= 8.6.0), debhelper ( 5.0.0) Package: tkdesk Architecture: any
Bug#753795: ngspice: needs rebuild with Tcl/Tk 8.6 after BLT was ported to Tcl/Tk 8.6
Source: ngspice
Version: 24-1.1
Severity: grave
Tags: patch
Justification: renders package unusable
Dear Maintainer,
Recently the blt package was ported to the Tcl/Tk 8.6, so tclspice needs
to do the same because it uses BLT. I've prepared a patch and can do NMU if
you don't mind.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru ngspice-24/debian/changelog ngspice-24/debian/changelog
--- ngspice-24/debian/changelog 2014-02-14 09:43:38.0 +0400
+++ ngspice-24/debian/changelog 2014-07-04 07:35:11.0 +0400
@@ -1,3 +1,12 @@
+ngspice (24-1.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Replace dependencies on Tcl/Tk 8.5 by Tcl/Tk 8.6 to match the newer
+blt package.
+ * Define USE_INTERP_RESULT to make tclspice buildable with Tcl 8.6.
+
+ -- Sergei Golovan sgolo...@debian.org Fri, 04 Jul 2014 07:35:05 +0400
+
ngspice (24-1.1) unstable; urgency=low
* Non-maintainer upload.
diff -Nru ngspice-24/debian/control ngspice-24/debian/control
--- ngspice-24/debian/control 2014-01-31 11:23:48.0 +0400
+++ ngspice-24/debian/control 2014-07-05 10:26:27.0 +0400
@@ -6,7 +6,7 @@
Andreas Tille ti...@debian.org
Build-Depends: debhelper (= 8), automake, libtool, libxaw7-dev, flex,
bison, gfortran, libedit-dev, libncurses5-dev,
- texinfo, tcl8.5-dev, tcl8.5, tk8.5-dev, tk8.5, blt-dev
+ texinfo, tcl8.6-dev, tcl8.6, tk8.6-dev, tk8.6, blt-dev (= 2.5.3)
Build-Depends-Indep: lyx, elyxer, texlive, texlive-latex-extra, texlive-lang-greek,
texlive-generic-recommended, imagemagick
Standards-Version: 3.9.3
@@ -29,7 +29,7 @@
Package: tclspice
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ngspice, blt, tcl8.5, tk8.5
+Depends: ${shlibs:Depends}, ${misc:Depends}, ngspice, blt, tcl8.6, tk8.6
Replaces: tclspice-dev
Breaks: tclspice-dev
Description: NGspice library for Tcl
diff -Nru ngspice-24/debian/rules ngspice-24/debian/rules
--- ngspice-24/debian/rules 2014-01-31 11:33:17.0 +0400
+++ ngspice-24/debian/rules 2014-07-04 07:36:02.0 +0400
@@ -14,7 +14,7 @@
CROSS= --build $(DEB_BUILD_GNU_TYPE)
endif
-
+CFLAGS= -DUSE_INTERP_RESULT
config.status: config.status-stamp configure
config.status-stamp:
@@ -57,7 +57,7 @@
--enable-cider \
--disable-debug \
--disable-x \
- --with-tcl=/usr/lib/tcl8.5 \
+ --with-tcl=/usr/lib/tcl8.6 \
CFLAGS=$(CFLAGS))
touch $@
Bug#753795: The correct patch
Hi!
Here is the correct patch (where the examples in the tclspice package
use wish8.6 instead of wish8.5).
Cheers!
--
Sergei Golovan
diff -Nru ngspice-24/debian/changelog ngspice-24/debian/changelog
--- ngspice-24/debian/changelog 2014-02-14 09:43:38.0 +0400
+++ ngspice-24/debian/changelog 2014-07-04 07:35:11.0 +0400
@@ -1,3 +1,12 @@
+ngspice (24-1.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Replace dependencies on Tcl/Tk 8.5 by Tcl/Tk 8.6 to match the newer
+blt package.
+ * Define USE_INTERP_RESULT to make tclspice buildable with Tcl 8.6.
+
+ -- Sergei Golovan sgolo...@debian.org Fri, 04 Jul 2014 07:35:05 +0400
+
ngspice (24-1.1) unstable; urgency=low
* Non-maintainer upload.
diff -Nru ngspice-24/debian/control ngspice-24/debian/control
--- ngspice-24/debian/control 2014-01-31 11:23:48.0 +0400
+++ ngspice-24/debian/control 2014-07-05 10:26:27.0 +0400
@@ -6,7 +6,7 @@
Andreas Tille ti...@debian.org
Build-Depends: debhelper (= 8), automake, libtool, libxaw7-dev, flex,
bison, gfortran, libedit-dev, libncurses5-dev,
- texinfo, tcl8.5-dev, tcl8.5, tk8.5-dev, tk8.5, blt-dev
+ texinfo, tcl8.6-dev, tcl8.6, tk8.6-dev, tk8.6, blt-dev (= 2.5.3)
Build-Depends-Indep: lyx, elyxer, texlive, texlive-latex-extra,
texlive-lang-greek,
texlive-generic-recommended, imagemagick
Standards-Version: 3.9.3
@@ -29,7 +29,7 @@
Package: tclspice
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ngspice, blt, tcl8.5, tk8.5
+Depends: ${shlibs:Depends}, ${misc:Depends}, ngspice, blt, tcl8.6, tk8.6
Replaces: tclspice-dev
Breaks: tclspice-dev
Description: NGspice library for Tcl
diff -Nru ngspice-24/debian/patches/02_fix_tcl_examples.patch
ngspice-24/debian/patches/02_fix_tcl_examples.patch
--- ngspice-24/debian/patches/02_fix_tcl_examples.patch 2014-01-31
11:29:19.0 +0400
+++ ngspice-24/debian/patches/02_fix_tcl_examples.patch 2014-07-05
10:46:45.0 +0400
@@ -6,7 +6,7 @@
#!/bin/sh
# WishFix \
-exec wish -f $0 ${1+$@}
-+exec wish8.5 -f $0 ${1+$@}
++exec wish8.6 -f $0 ${1+$@}
###
# old name: analyse-20070504-0.tcl
@@ -22,7 +22,7 @@
#!/bin/sh
# WishFix \
- exec wish -f $0 ${1+$@}
-+ exec wish8.5 -f $0 ${1+$@}
++ exec wish8.6 -f $0 ${1+$@}
###
package require BLT
@@ -37,7 +37,7 @@
#!/bin/sh
# WishFix \
-exec wish -f $0 ${1+$@}
-+exec wish8.5 -f $0 ${1+$@}
++exec wish8.6 -f $0 ${1+$@}
###
package require BLT
@@ -52,7 +52,7 @@
#!/bin/sh
# WishFix \
- exec wish vspicechart.tcl example.cir
-+ exec wish8.5 vspicechart.tcl example.cir
++ exec wish8.6 vspicechart.tcl example.cir
###
--- a/examples/tclspice/tcl-testbench4/vspicechart.tcl
+++ b/examples/tclspice/tcl-testbench4/vspicechart.tcl
@@ -80,7 +80,7 @@
#!/bin/sh
# WishFix \
-exec wish -f $0 ${1+$@}
-+exec wish8.5 -f $0 ${1+$@}
++exec wish8.6 -f $0 ${1+$@}
###
package require BLT
diff -Nru ngspice-24/debian/rules ngspice-24/debian/rules
--- ngspice-24/debian/rules 2014-01-31 11:33:17.0 +0400
+++ ngspice-24/debian/rules 2014-07-04 07:36:02.0 +0400
@@ -14,7 +14,7 @@
CROSS= --build $(DEB_BUILD_GNU_TYPE)
endif
-
+CFLAGS= -DUSE_INTERP_RESULT
config.status: config.status-stamp configure
config.status-stamp:
@@ -57,7 +57,7 @@
--enable-cider \
--disable-debug \
--disable-x \
- --with-tcl=/usr/lib/tcl8.5 \
+ --with-tcl=/usr/lib/tcl8.6 \
CFLAGS=$(CFLAGS))
touch $@
Bug#753307: Patch
Hi Ole!
I've prepared a small patch which can help in porting skycat to 8.6
(it just replaces 8.5 by 8.6 here and there and adds a bit more
restrictive dependency on blt).
Cheers!
--
Sergei Golovan
diff -Nru skycat-3.1.2+starlink1~b/debian/changelog
skycat-3.1.2+starlink1~b/debian/changelog
--- skycat-3.1.2+starlink1~b/debian/changelog 2014-04-14 13:48:11.0
+0400
+++ skycat-3.1.2+starlink1~b/debian/changelog 2014-07-05 10:52:33.0
+0400
@@ -1,3 +1,10 @@
+skycat (3.1.2+starlink1~b-6.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Switched to Tcl/Tk 8.6.
+
+ -- Sergei Golovan sgolo...@debian.org Sat, 05 Jul 2014 10:52:01 +0400
+
skycat (3.1.2+starlink1~b-6) unstable; urgency=low
* Replace tclx8.4 dependency by tcl8.5 counterparts
diff -Nru skycat-3.1.2+starlink1~b/debian/control
skycat-3.1.2+starlink1~b/debian/control
--- skycat-3.1.2+starlink1~b/debian/control 2014-04-14 13:38:08.0
+0400
+++ skycat-3.1.2+starlink1~b/debian/control 2014-07-05 10:51:21.0
+0400
@@ -3,15 +3,15 @@
Priority: optional
Maintainer: Debian Astronomy Maintainers
debian-astro-maintain...@lists.alioth.debian.org
Uploaders: Ole Streicher deb...@liska.ath.cx
-Build-Depends: blt-dev (= 2.4z),
+Build-Depends: blt-dev (= 2.5.3),
debhelper (= 9),
dh-autoreconf,
itcl3,
itk3,
libcfitsio3-dev,
libwcstools-dev,
- tcl8.5-dev,
- tk8.5-dev
+ tcl8.6-dev,
+ tk8.6-dev
Standards-Version: 3.9.5
Homepage: http://archive.eso.org/cms/tools-documentation/skycat.html
Vcs-Git: git://anonscm.debian.org/debian-astro/packages/skycat.git
@@ -19,12 +19,12 @@
Package: skycat
Architecture: any
-Depends: blt (= 2.4z),
+Depends: blt (= 2.5.3),
itcl3,
itk3,
libtk-img,
- tcl8.5,
- tk8.5,
+ tcl8.6,
+ tk8.6,
${misc:Depends},
${shlibs:Depends}
Description: Image visualization and access to catalogs and data for astronomy
diff -Nru skycat-3.1.2+starlink1~b/debian/patches/fhs.patch
skycat-3.1.2+starlink1~b/debian/patches/fhs.patch
--- skycat-3.1.2+starlink1~b/debian/patches/fhs.patch 2014-03-17
14:48:30.0 +0400
+++ skycat-3.1.2+starlink1~b/debian/patches/fhs.patch 2014-07-05
11:02:54.0 +0400
@@ -315,7 +315,7 @@
test -d $HOME/.skycat || mkdir $HOME/.skycat
echo `date`: Starting skycat with: $0 ${1+$@} $HOME/.skycat/log
-exec wish8.4 $SKYCAT_BASE/lib/skycat@PACKAGE_VERSION@/main.tcl ${1+$@} |
tee -a $HOME/.skycat/log 21
-+exec wish8.5 /usr/share/skycat/skycat@PACKAGE_VERSION@/main.tcl ${1+$@} |
tee -a $HOME/.skycat/log 21
++exec wish8.6 /usr/share/skycat/skycat@PACKAGE_VERSION@/main.tcl ${1+$@} |
tee -a $HOME/.skycat/log 21
--- a/skycat/configure.in
+++ b/skycat/configure.in
@@ -359,7 +359,7 @@
test -d $HOME/.rtd || mkdir $HOME/.rtd
-exec wish8.4 $RTD_BASE/lib/rtd@PACKAGE_VERSION@/main.tcl ${1+$@} | tee
$HOME/.skycat/log 21
-+exec wish8.5 /usr/share/skycat/rtd@PACKAGE_VERSION@/main.tcl ${1+$@} | tee
$HOME/.skycat/log 21
++exec wish8.6 /usr/share/skycat/rtd@PACKAGE_VERSION@/main.tcl ${1+$@} | tee
$HOME/.skycat/log 21
--- a/tclutil/configure.in
+++ b/tclutil/configure.in
diff -Nru skycat-3.1.2+starlink1~b/debian/rules
skycat-3.1.2+starlink1~b/debian/rules
--- skycat-3.1.2+starlink1~b/debian/rules 2014-03-17 16:28:18.0
+0400
+++ skycat-3.1.2+starlink1~b/debian/rules 2014-07-05 10:54:21.0
+0400
@@ -7,7 +7,7 @@
dh $@ --with autoreconf
override_dh_auto_configure:
- dh_auto_configure -- --with-tkinclude=/usr/include/tcl8.5
--with-tcl=/usr/lib/tcl8.5 --with-tk=/usr/lib/tk8.5 --libdir=/usr/lib/
--libexecdir=/usr/lib
+ dh_auto_configure -- --with-tkinclude=/usr/include/tcl8.6
--with-tcl=/usr/lib/tcl8.6 --with-tk=/usr/lib/tk8.6 --libdir=/usr/lib/
--libexecdir=/usr/lib
override_dh_installchangelogs:
Bug#753817: ttt: needs to build with Tcl/Tk 8.6 because BLT is ported to Tcl/Tk 8.6
Source: ttt
Version: 1.7-3.4
Severity: grave
Tags: patch
Justification: renders package unusable
Dear Maintainer,
Recently we switched to Tcl/Tk 8.6 in blt, one of the packages ttt depends on.
This means ttt has to switch as well. I've prepared a patch which does that
and fixes immediate segfault in tttviewer. If you don't mind I could NMU it.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u ttt-1.7/debian/control ttt-1.7/debian/control
--- ttt-1.7/debian/control
+++ ttt-1.7/debian/control
@@ -2,7 +2,7 @@
Section: net
Priority: optional
Maintainer: Thomas Scheffczyk thomas.scheffc...@verwaltung.uni-mainz.de
-Build-Depends: debhelper (= 6.0.0), autotools-dev, tcl8.5-dev, tk8.5-dev, blt-dev, libpcap-dev
+Build-Depends: debhelper (= 6.0.0), autotools-dev, tcl-dev, tk-dev, blt-dev, libpcap-dev
Standards-Version: 3.7.2.2
Package: ttt
diff -u ttt-1.7/debian/rules ttt-1.7/debian/rules
--- ttt-1.7/debian/rules
+++ ttt-1.7/debian/rules
@@ -14,6 +14,7 @@
DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
+EXTRA_CFLAGS = -DUSE_INTERP_RESULT
ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
CFLAGS += -g
@@ -35,7 +36,7 @@
cp -f /usr/share/misc/config.guess cf/config.guess )
./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info \
- --with-tcl=/usr/lib/tcl8.5 --with-tk=/usr/lib/tk8.5
+ --with-tcl=/usr/lib --with-tk=/usr/lib
build-arch: config.status build-arch-stamp
@@ -43,7 +44,7 @@
dh_testdir
# Add here command to compile/build the package.
- $(MAKE)
+ $(MAKE) EXTRA_CFLAGS=$(EXTRA_CFLAGS)
touch build-arch-stamp
@@ -65,7 +66,7 @@
dh_testdir
dh_testroot
# 2003-04-14 Extended rm command to make sure that all build
-# stamps are deleted. Original comand was rm -f build-stamp
+ # stamps are deleted. Original comand was rm -f build-stamp
rm -f build-*stamp
# Add here commands to clean up after the build process.
diff -u ttt-1.7/debian/changelog ttt-1.7/debian/changelog
--- ttt-1.7/debian/changelog
+++ ttt-1.7/debian/changelog
@@ -1,3 +1,14 @@
+ttt (1.7-3.5) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Build with Tcl/Tk 8.6 to make the package work with newer BLT package.
+ * Define USE_INTERP_RESULT macro to allow the usage of deprecated
+interp-result field.
+ * Added missing includes into viewer.c to declare exit(), strcpy(),
+bzero() and inet_ntoa() functions to prevent immediate segfault.
+
+ -- Sergei Golovan sgolo...@debian.org Sat, 05 Jul 2014 16:25:45 +0400
+
ttt (1.7-3.4) unstable; urgency=low
* Non-maintainer upload.
only in patch2:
unchanged:
--- ttt-1.7.orig/viewer.c
+++ ttt-1.7/viewer.c
@@ -17,11 +17,15 @@
shared by tttview and extview but TTT_TEXT flag is set for
extview. */
#include stdio.h
+#include stdlib.h
+#include string.h
+#include strings.h
#include netdb.h
#include sys/param.h
#include sys/socket.h
#include sys/time.h
#include netinet/in.h
+#include arpa/inet.h
#include ttt.h
#include ttt_node.h
Bug#753307: broken by tcl/tk 8.6
Hi again, On Wed, Jul 2, 2014 at 1:00 PM, Sergei Golovan sgolo...@debian.org wrote: On the other hand, blt, which is currently built with tk8.6, doesn't work at all. The demos from blt-demo package crashed for me every time (I'm going to file a bugreport). So, I guess, we have to decide what to do with blt first. I've taken over the blt package and uploaded the new version which doesn't crash immediately under Tcl/Tk 8.6. I've tried to run skycat (rebuilt with 8.6 too) and it seems to work. So, build-depend skycat on blt-dev (=2.5.3) and tk-dev (or tk8.6-dev), and it should be fine after that. If some other bugs related to BLT will be revealed, please, report them to the blt package. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753307: broken by tcl/tk 8.6
Hi, On Mon, Jun 30, 2014 at 3:35 PM, Sergei Golovan sgolo...@debian.org wrote: Hi Julian. On Mon, Jun 30, 2014 at 3:25 PM, Julian Taylor jtaylor.deb...@googlemail.com wrote: on the ubuntu-motu mailing list (search skycat) there is a patch that fixes this issue but it will still segfault on start due to itcl3 needing tcl 8.5. I have no fix for that. I'll try to port itcl3 and itk3 to tcl/tk8.6, or may be package itcl4. It'll require to look into their reverse dependencies (e.g. ftools-pow and ftools-fv). As far as I can tell, itcl3 and itk3 work with tcl/tk8.6. Even if they currently depend on tcl8.5, if you run wish8.6 and do package require Itcl or package require Itk, everything works fine (I've tried to run tests, supplied with itcl3 and itk3, and demos in iwidgets4). On the other hand, blt, which is currently built with tk8.6, doesn't work at all. The demos from blt-demo package crashed for me every time (I'm going to file a bugreport). So, I guess, we have to decide what to do with blt first. By the way, blt 2.4z-8 (conservatively built with tcl8.5) works fine (but obviously doesn't load into wish8.6). Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753476: blt: new build against Tcl/Tk 8.6 crashes
Package: blt Version: 2.4z-9 Severity: grave Justification: renders package unusable Dear Maintainer, Looks like blt 2.4z can't work with Tcl/Tk 8.6. An easy way to see this is to run demos included in the blt-demo package. Here are the issues: 1) barchart1.tcl: segfault on exit 2) barchart2.tcl: immediate segfault 3) barchart3.tcl: segfault on mouse interaction with the chart 4) barchart4.tcl: segfault on mouse interaction with the chart 5) barchart5.tcl: segfault on mouse interaction with the chart 6) bgexec1.tcl: segfault on Stop button click 7) bitmap.tcl: segfault on any button click and so on. This means that we either have to build blt with Tcl/Tk 8.5 (and make sure that all packages which use blt don't try to use Tcl/Tk 8.6) or we should port blt to Tcl/Tk 8.6. The problem is that the project upstream isn't active (https://sourceforge.net/projects/blt/) Last release in 2003, last activity in CVS in 2010. There is a 2.5 release from another upstream (https://sourceforge.net/projects/wize/files/), but this is another discontinued project, so we can't rely on its development. Moreover, I can't say at the moment if this release really works with Tcl/Tk 8.6. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages blt depends on: ii libc6 2.19-3 ii libtcl8.5 8.5.15-4 ii libtk8.5 8.5.15-4 ii libx11-6 2:1.6.2-2 blt recommends no packages. Versions of packages blt suggests: ii blt-demo 2.4z-9 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753476: BLT from wize doesn't work
Hi! I've tried to build BLT from https://sourceforge.net/projects/wize/files/ and it suffers the same problems as 2.4z currently in Debian. It segfaults for Tcl/Tk 8.6. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753307: broken by tcl/tk 8.6
Hi Julian. On Mon, Jun 30, 2014 at 3:25 PM, Julian Taylor jtaylor.deb...@googlemail.com wrote: on the ubuntu-motu mailing list (search skycat) there is a patch that fixes this issue but it will still segfault on start due to itcl3 needing tcl 8.5. I have no fix for that. I'll try to port itcl3 and itk3 to tcl/tk8.6, or may be package itcl4. It'll require to look into their reverse dependencies (e.g. ftools-pow and ftools-fv). Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751879: tcl-trf contain non-free, non-distributable code.
Hi Legimet, On Fri, Jun 20, 2014 at 7:13 AM, Legimet legimet.c...@gmail.com wrote: Hi, Here are my own implementations of RIPEMD-128 and RIPEMD-160, under the same license as the rest of tcl-trf. They are compatible with the ones included in this package and a little faster as well. They should go in generic/ripemd. Thank you very much for the code! I was about to drop RIPEMD-128 and use RIPEMD-160 from OpenSSL (which API is different, so some porting was required). Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751879: tcl-trf contain non-free, non-distributable code.
Hi Mejiko. On Tue, Jun 17, 2014 at 4:05 PM, mejiko kame55-itasenpara...@y2.dion.ne.jp wrote: tcl-trf included non-free codes. Please see Trisquel bug 11006 details. I'll look into it an will see what I can do to fix it. Thank you for the report. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725079: NMU?
Hi! If you don't mind I could fix this bug in NMU. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725070: NMU?
Hi! If you don't mind I could fix this bug in NMU. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743100: Help with tclx8.4 [was: emacspeak is marked for autoremoval from testing]
Hi Paul. On Wed, Apr 16, 2014 at 9:45 AM, Paul Gevers elb...@debian.org wrote: On 16-04-14 06:13, Sergei Golovan wrote: On Wed, Apr 16, 2014 at 7:47 AM, Sergei Golovan sgolo...@nes.ru wrote: Hi Paul, I'll prepare an NMU to fix tclx8.4. Thank you for the reminder. Here it is. I'll upload it shortly. Thanks for the very quick response. I also went to the upstream web-site and saw that a 8.4.1 version is available. Do you think it is worth it to upload that? You don't have to do it, I can do that, but I want your opinion on the value. Since we don't know what will be fixed and what will be broken after upgrade to 8.4.1 and we aren't the tclx8.4 maintainers, I wouldn't upload the new version in NMU. Though, if you're going to adopt tclx8.4 you can do whatever you think is right. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743100: Help with tclx8.4 [was: emacspeak is marked for autoremoval from testing]
Hi Paul, On Tue, Apr 15, 2014 at 11:56 PM, Paul Gevers elb...@debian.org wrote: Hi Sergei, On 14-04-14 06:39, Debian testing autoremoval watch wrote: emacspeak 39.0+dfsg-2 is marked for autoremoval from testing on 2014-05-13 It (build-)depends on packages with these RC bugs: 743100: tclx8.4: FTBFS: ./generic/tclXgeneral.c:408:10: error: 'Tcl_Interp' has no member named 'errorLine' It seems that tclx8.4 is failing to build now [1] that tcl8.4 is being removed from Debian. Unfortunately, tclx8.4 doesn't have a maintainer anymore and I don't have experience at all with tcl. Would you be willing to have a look at tclx8.4 and see if you can easily spot the issue and maybe propose a fix. Else, the emacspeak package might become collateral damage of the tcl8.4 removal. I'll prepare an NMU to fix tclx8.4. Thank you for the reminder. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743100: Help with tclx8.4 [was: emacspeak is marked for autoremoval from testing]
On Wed, Apr 16, 2014 at 7:47 AM, Sergei Golovan sgolo...@nes.ru wrote: Hi Paul, I'll prepare an NMU to fix tclx8.4. Thank you for the reminder. Here it is. I'll upload it shortly. -- Sergei Golovan diff -u tclx8.4-8.4.0/debian/rules tclx8.4-8.4.0/debian/rules --- tclx8.4-8.4.0/debian/rules +++ tclx8.4-8.4.0/debian/rules @@ -27,7 +27,7 @@ ENABLE_THREADS = $(shell test $(TCL_THREADS) = 1 echo --enable-threads) DESTDIR = $(CURDIR)/debian/tmp -CFLAGS = -Wall -g +CFLAGS = -Wall -g -DUSE_INTERP_RESULT -DUSE_INTERP_ERRORLINE ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) CFLAGS += -O0 diff -u tclx8.4-8.4.0/debian/changelog tclx8.4-8.4.0/debian/changelog --- tclx8.4-8.4.0/debian/changelog +++ tclx8.4-8.4.0/debian/changelog @@ -1,3 +1,10 @@ +tclx8.4 (8.4.0-3.2) unstable; urgency=low + + * Non-maintainer upload. + * Fixed FTBFS with Tcl 8.6 as a default Tcl version (Closes: #743100). + + -- Sergei Golovan sgolo...@debian.org Wed, 16 Apr 2014 07:53:53 +0400 + tclx8.4 (8.4.0-3.1) unstable; urgency=low * Non-maintainer upload.
Bug#737279: NMU
Hi, I guess, you don't mind if I do NMU for ngspice. Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
