Bug#966355: ITP: denss -- calculate electron density from a solution scattering profile
Package: wnpp Severity: wishlist Owner: Sebastien Delafond X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: denss Version : 0.0.1+20200710gac8923a Upstream Author : Thomas Grant * URL : https://github.com/tdgrant1/denss * License : GPL-3 Programming Lang: Python Description : calculate electron density from a solution scattering profile DENSS is an algorithm used for calculating ab initio electron density maps directly from solution scattering data. DENSS implements a novel iterative structure factor retrieval algorithm to cycle between real space density and reciprocal space structure factors, applying appropriate restraints in each domain to obtain a set of structure factors whose intensities are consistent with experimental data and whose electron density is consistent with expected real space properties of particles. . DENSS utilizes the NumPy Fast Fourier Transform for moving between real and reciprocal space domains. Each domain is represented by a grid of points (Cartesian), N x N x N. N is determined by the size of the system and the desired resolution. The real space size of the box is determined by the maximum dimension of the particle, D, and the desired sampling ratio. Larger sampling ratio results in a larger real space box and therefore a higher sampling in reciprocal space (i.e. distance between data points in q). Smaller voxel size in real space corresponds to higher spatial resolution and therefore to larger q values in reciprocal space.
Bug#966369: ITP: genx -- differential evolution algorithm for fitting X-ray and neutron reflectivity data
Package: wnpp Severity: wishlist Owner: Sebastien Delafond X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: genx Version : 3.0.0beta3 Upstream Author : Matts Bjorck; Artur Glavic * URL : Source: https://sourceforge.net/p/genx/git/ * License : GPL-3 Programming Lang: Python Description : differential evolution algorithm for fitting X-ray and neutron reflectivity data GenX is a versatile program using the differential evolution algorithm for fitting, primarily, X-ray and neutron reflectivity data, lately also surface x-ray diffraction data. The differential evolution algorithm is a robust optimization method which avoids local minima but at same is a highly effective. GenX is written in python and uses the wxpython package for the Graphical User Interface (GUI). A model to fit is defined either through a GUI plug-in or via a python script. The possibility to script everything makes it easy to develop completely new fitting model. Clearly, GenX is extremely modular, making it possible to extend the program with models and plug-ins for most fitting problems. At the present GenX is shipped with models for x-ray and neutron specular reflectivity, off-specular x-ray reflectivity and surface x-ray diffraction
Re: CTTE requesting questions for DebConf20 BoF
[cc:ing debian-devel so -announce doesn’t get swamped — apologies and please suggest a better list (or none) if I chose poorly ….] Greetings, Sean Whitton! Thank you for laying out the context. I will put in a few questions as I look at how I want to contribute to Debian community. If this triggers early discussion, so be it. Re: proposal #2: How does the Committee currently handle “hey this is fundamentally non-technical and out of our scope”? (eg refer to Debian Project Leader to re-delegate) Does this really suggest forming a Non-technical Committee? (maybe even constitutionally mandating) Re: proposal #5: Why must sending implicit/out-of-scope duties elsewhere require disbanding TC? If such implicit/out-of-scope duties accreted, it seems like not by Constitution, so can DPL delegate/distribute those away from TC? Re: TC as nuclear option, proposal #4: What’s done currently to mitigate? Perhaps this encourages forming a well-known lesser body, formal or informal, to give advice and serve as a rally-point for hammering out proposals and encouraging design work. (Or two, one for advice/review and one to track/encourage the actual work.) In many US-based non-profits, the past heads of organization as a group visibly serve such a role. For instance, in Toastmasters International, past District Managers serve as this “council of grey-beards”, along with the explicit mandate to help mentor prospective and future leaders for their respective districts. A naive translation of this idea would propose all past TC members together be asked to fulfill this role. Re: no design work: What prevents the TC from visibly tabling a matter pending further design work? Perhaps with specific advice/observations/suggestions for designers to consider? Maybe even in conjunction with DPL/someone designating specific folks to create proposal(s)? Re: advisory body: What prevents TC members (acting as an informal group which is not the TC) from being that advisory now? Thanks! Joseph —— Joseph Beckenbach
Bug#844315: marked as done (updates appear in wheezy-security before jessie)
Your message dated Mon, 27 Jul 2020 17:53:33 +0200 with message-id <7f0c15310ef08be0e48fd99526820a04d8adab58.ca...@43-1.org> and subject line Re: Bug#844315: tzdata version breaks dist-upgrade leaving version from oldstable security installed has caused the Debian Bug report #844315, regarding updates appear in wheezy-security before jessie to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 844315: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844315 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: tzdata Version: 2016i-0+deb7u1 Severity: critical Upgrading a fully updated wheezy system (incl. security repo) to jessie (incl. security repo) results in tzdata not being updated because the version in wheezy-security is newer than in jessie. Package tzdata on amd64 wheezy: 2016d-0+deb7u1 wheezy-security: 2016i-0+deb7u1 jessie: 2016f-0+deb8u1 jessie-updates: 2016i-0+deb8u1 jessie-proposed-updates: 2016i-0+deb8u1 Using only the main repo + security repo results in tzdata not being updates since wheezy-securities '2016i-0+deb7u1' is higher than jessies '2016f-0+deb8u1'. Comment from IRC: That's indeed unfortunate. You can work around the problem by adding jessie-updates, though. I think it's because wheezy didn't have a wheezy-updates, so all updates must go through wheezy-security, whereas in jessie all non-critical updates go through jessie-updates, and get wrapped up in point releases every few months. It's still a bug though, I'd report it on the tzdata package. Might warrant a RC severity, since it breaks automatic upgrades and is easy to fix. --- End Message --- --- Begin Message --- On Mon, 14 Nov 2016 22:42:09 +0100 Aurelien Jarno wrote: > On 2016-11-14 12:54, Marcel Meckel wrote: > > Upgrading a fully updated wheezy system (incl. security repo) to > > jessie (incl. security repo) results in tzdata not being updated > > because the version in wheezy-security is newer than in jessie. > > > > Package tzdata on amd64 > > > > wheezy: 2016d-0+deb7u1 > > wheezy-security: 2016i-0+deb7u1 > > > > jessie: 2016f-0+deb8u1 > > jessie-updates: 2016i-0+deb8u1 > > jessie-proposed-updates: 2016i-0+deb8u1 > > > > Using only the main repo + security repo results in tzdata not being > > updates since wheezy-securities '2016i-0+deb7u1' is higher than > > jessies '2016f-0+deb8u1'. > > Nothing can be done at the tzdata level, except maybe stopping providing > updates to wheezy users. I am therefore reassigning the bug to the > "general" package. Also there are probably more than tzdata affected. > > Note however that you are supposed to use jessie-updates on a jessie > system. This is actually enabled by default in debian-installer. I don't think there is really anything to do here as I don't see a problem with having to use *-updates. Given nobody else said anything in the last 3 1/2 years, I'll close the report. Ansgar--- End Message ---
Bug#508644: marked as done (Sorting out mail-transport-agent mess)
Your message dated Mon, 27 Jul 2020 18:00:18 +0200 with message-id <10adcf7ba4466553aeb2b50f38a58bde9af46300.ca...@43-1.org> and subject line Re: Sorting out mail-transport-agent mess has caused the Debian Bug report #508644, regarding Sorting out mail-transport-agent mess to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 508644: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508644 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: important Hi Looking around for why citadel-server was pulled in instead of exim4 (which I believe is still the default MTA in debian). I saw the bug #474999 I just would let you know that maybe it is a more general problem as mdadm is also pulling citadel-server in as a dependency I still believe it should have been exim4? -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/4 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash --- End Message --- --- Begin Message --- The last blocking bug for this 11+ years old report was closed in 2019 by removal of pyca; the other blocking bugs were already closed in 2012. So this can probably be closed now. Ansgar--- End Message ---
Bug#637232: marked as done (general: Multiarch breaks support for non-multiarch toolchain)
Your message dated Mon, 27 Jul 2020 18:05:22 +0200 with message-id <2ea4db46667572b33b5148a72025785732318b06.ca...@43-1.org> and subject line Re: general: Multiarch breaks support for non-multiarch toolchain has caused the Debian Bug report #637232, regarding general: Multiarch breaks support for non-multiarch toolchain to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 637232: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637232 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: critical Debian has choosen to implement multiarch, which amongs other things, means that the includes and libraries are moved in a new "multiarch" path. This breaks some upstream applications and non-Debian toolchain. It is possible to workaround some of the issues as described in /usr/share/doc/libc6/NEWS.Debian.gz. | eglibc (2.13-11) unstable; urgency=low | | Starting with the eglibc package version 2.13-5, the libraries are | shipped in the multiarch directory /lib/$arch instead of the more | traditional /lib. | | The toolchain in Debian has been updated to cope with that, and most | build systems should be unaffected. If you are using a non-Debian | toolchain to build your software and it is not able to cope with | multiarch, you might try to pass the following option to your | compiler: | |-B/usr/lib/$arch | | -- Aurelien Jarno Sat, 23 Jul 2011 23:42:46 +0200 I got fed up by people reporting bug on libc6, while this problem results from a decision Debian to implement multiarch. People should work on implementing a compatibility wrapper and to make upstream toolchain multiarch aware. Until this is done, this bug should be kept opened. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash --- End Message --- --- Begin Message --- On Tue, 09 Aug 2011 19:31:56 +0200 Aurelien Jarno wrote: > Debian has choosen to implement multiarch, which amongs other things, > means that the includes and libraries are moved in a new "multiarch" > path. This breaks some upstream applications and non-Debian toolchain. [...] > I got fed up by people reporting bug on libc6, while this problem results > from a decision Debian to implement multiarch. People should work on > implementing a compatibility wrapper and to make upstream toolchain > multiarch aware. Until this is done, this bug should be kept opened. This was now ~9 years ago and this report had no activity since late 2014. I would hope it is no longer relevant, so I'll close the report. Ansgar--- End Message ---
Bug#966377: ITP: aioftp -- FTP client and server for asyncio
Package: wnpp
Severity: wishlist
Owner: Adam Cecile
* Package name: aioftp
Version : 0.13.0
Upstream Author : Nikita Melentev
* URL : https://github.com/aio-libs/aioftp
* License : Apache
Programming Lang: Python
Description : FTP client and server for asyncio
Library implementing FTP protocol, both client and server for Python asyncio
module.
.
Supported commands as client: USER, PASS, ACCT, PWD, CWD, CDUP, MKD, RMD, MLSD,
MLST, RNFR, RNTO, DELE, STOR, APPE, RETR, TYPE, PASV, ABOR, QUIT, REST, LIST
(as fallback)
.
Supported commands as server: USER, PASS, QUIT, PWD, CWD, CDUP, MKD, RMD, MLSD,
LIST (non-standard), MLST, RNFR, RNTO, DELE, STOR, RETR, TYPE ("I" and "A"),
PASV, ABOR, APPE, REST
Bug#639214: marked as done (eglibc: changes to paths concerning crt1.o, crti.o and crtn.o breaks building LLVM Trunk)
Your message dated Mon, 27 Jul 2020 18:05:22 +0200 with message-id <2ea4db46667572b33b5148a72025785732318b06.ca...@43-1.org> and subject line Re: general: Multiarch breaks support for non-multiarch toolchain has caused the Debian Bug report #637232, regarding eglibc: changes to paths concerning crt1.o, crti.o and crtn.o breaks building LLVM Trunk to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 637232: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637232 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: eglibc Version: 2.13-18 Severity: normal With the most recent changes of moving the object files under /usr/lib/x86_64-linux-gnu/ the linker to build Clang/LLVM breaks. A workaround is to add symlinks for crt1.o, crti.o and crtn.o back under /usr/lib. Is there a solution possible in perhaps alternatives to make a clean approach for the LLVM/Clang project to see these object files necessary to link against and continue building without having to rehack their configure/makefiles? I would expect the Debian FreeBSD being part of the family would be a great opportunity to make this issue be resolved and work across all architectures and for other compilers besides the GCC Family. - Marc -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash --- End Message --- --- Begin Message --- On Tue, 09 Aug 2011 19:31:56 +0200 Aurelien Jarno wrote: > Debian has choosen to implement multiarch, which amongs other things, > means that the includes and libraries are moved in a new "multiarch" > path. This breaks some upstream applications and non-Debian toolchain. [...] > I got fed up by people reporting bug on libc6, while this problem results > from a decision Debian to implement multiarch. People should work on > implementing a compatibility wrapper and to make upstream toolchain > multiarch aware. Until this is done, this bug should be kept opened. This was now ~9 years ago and this report had no activity since late 2014. I would hope it is no longer relevant, so I'll close the report. Ansgar--- End Message ---
Bug#648889: marked as done (/usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h")
Your message dated Mon, 27 Jul 2020 18:05:22 +0200 with message-id <2ea4db46667572b33b5148a72025785732318b06.ca...@43-1.org> and subject line Re: general: Multiarch breaks support for non-multiarch toolchain has caused the Debian Bug report #637232, regarding /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h" to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 637232: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637232 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6-dev Version: 2.13-21 Severity: normal Dear Maintainer, I just tried to comiple some code with the intel compiler and got: /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h" #include The reason seems to be that /usr/include/features.h includes bits/predefs.h which does not exist in /usr/include/ . However, it exists in /usr/include/x86_64-linux-gnu/ . If I also install libc6-dev-i386 the problem goes away since this seems to create a symlink /usr/include/bits -> x86_64 -linux-gnu/bits . Shouldn't we be able to use features.h without also installing libc6-dev-i386? Thanks a lot, Wolfgang -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/6 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 libc6-dev depends on: ii libc-dev-bin2.13-21 ii libc6 2.13-21 ii linux-libc-dev 3.0.0-3 Versions of packages libc6-dev recommends: ii gcc [c-compiler] 4:4.6.1-3 ii gcc-4.6 [c-compiler] 4.6.1-15 Versions of packages libc6-dev suggests: ii glibc-doc ii manpages-dev 3.32-0.2 -- debconf-show failed --- End Message --- --- Begin Message --- On Tue, 09 Aug 2011 19:31:56 +0200 Aurelien Jarno wrote: > Debian has choosen to implement multiarch, which amongs other things, > means that the includes and libraries are moved in a new "multiarch" > path. This breaks some upstream applications and non-Debian toolchain. [...] > I got fed up by people reporting bug on libc6, while this problem results > from a decision Debian to implement multiarch. People should work on > implementing a compatibility wrapper and to make upstream toolchain > multiarch aware. Until this is done, this bug should be kept opened. This was now ~9 years ago and this report had no activity since late 2014. I would hope it is no longer relevant, so I'll close the report. Ansgar--- End Message ---
Bug#682678: marked as done (/usr/include/features.h referes to bits/predefs.h, but no "bits" link or dir in /usr/include)
Your message dated Mon, 27 Jul 2020 18:05:22 +0200 with message-id <2ea4db46667572b33b5148a72025785732318b06.ca...@43-1.org> and subject line Re: general: Multiarch breaks support for non-multiarch toolchain has caused the Debian Bug report #637232, regarding /usr/include/features.h referes to bits/predefs.h, but no "bits" link or dir in /usr/include to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 637232: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637232 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6-dev Version: 2.13-33 Severity: important Dear Maintainer, I've tried to build GCC-4.6.2 on my system from sources. I've got compilation failed with the following error message: In file included from /usr/include/stdio.h:28:0, from /home/lexa/arena/cT/search/gcc-4.6.2/libgcc/../gcc/tsystem.h:87, from /home/lexa/arena/cT/search/gcc-4.6.2/libgcc/../gcc/libgcc2.c:29: /usr/include/features.h:323:26: fatal error: bits/predefs.h: No such file or directory So I checked it and found that neither "bits" dir presents in /usr/include nor a link with this name (to x86_64-linux-gnu/bits/ since there is predefs.h in the /usr/include/x86_64-linux-gnu/bits/ dir) Is creating the correspondent link -- during libc6-dev installation-- a solution? gcc version detected and used for the compilation: /usr/bin/x86_64-linux-gnu-gcc -> gcc-4.7 The context (from logfile): make[2]: Entering directory `/home/lexa/tmb/gcc-4.6.2-build/x86_64-linux-gnu/libgcc' # If this is the top-level multilib, build all the other # multilibs. /home/lexa/tmb/gcc-4.6.2-build/./gcc/xgcc -B/home/lexa/tmb/gcc-4.6.2-build/./gcc/ \ -B/home/lexa/.cmd/x86_64-linux-gnu/bin/ -B/home/lexa/.cmd/x86_64-linux-gnu/lib/ \ -isystem /home/lexa/.cmd/x86_64-linux-gnu/include \ -isystem /home/lexa/.cmd/x86_64-linux-gnu/sys-include \ -O2 -O0 -g -O2 -O2 -O0 -g -DIN_GCC -W -Wall -Wwrite-strings \ -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes \ -Wold-style-definition -isystem ./include -fPIC -g \ -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector \ -I. -I. -I../.././gcc -I/home/lexa/arena/cT/search/gcc-4.6.2/libgcc \ -I/home/lexa/arena/cT/search/gcc-4.6.2/libgcc/. \ -I/home/lexa/arena/cT/search/gcc-4.6.2/libgcc/../gcc \ -I/home/lexa/arena/cT/search/gcc-4.6.2/libgcc/../include \ -I/home/lexa/arena/cT/search/gcc-4.6.2/libgcc/config/libbid \ -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _muldi3.o -MT _muldi3.o \ -MD -MP -MF _muldi3.dep -DL_muldi3 \ -c /home/lexa/arena/cT/search/gcc-4.6.2/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS In file included from /usr/include/stdio.h:28:0, from /home/lexa/arena/cT/search/gcc-4.6.2/libgcc/../gcc/tsystem.h:87, from /home/lexa/arena/cT/search/gcc-4.6.2/libgcc/../gcc/libgcc2.c:29: /usr/include/features.h:323:26: fatal error: bits/predefs.h: No such file or directory compilation terminated. make[2]: *** [_muldi3.o] Error 1 make[2]: Leaving directory `/home/lexa/tmb/gcc-4.6.2-build/x86_64-linux-gnu/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/home/lexa/tmb/gcc-4.6.2-build' make: *** [all] Error 2 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Shell: /bin/sh linked to /bin/dash Versions of packages libc6-dev depends on: ii libc-dev-bin2.13-33 ii libc6 2.13-33 ii linux-libc-dev 3.2.21-3 Versions of packages libc6-dev recommends: ii gcc [c-compiler] 4:4.7.1-1 ii gcc-4.4 [c-compiler] 4.4.7-1 ii gcc-4.6 [c-compiler] 4.6.3-8 ii gcc-4.7 [c-compiler] 4.7.1-2 Versions of packages libc6-dev suggests: pn glibc-doc ii manpages-dev 3.40-0.1 -- no debconf information --- End Message --- --- Begin Message --- On Tue, 09 Aug 2011 19:31:56 +0200 Aurelien Jarno wrote: > Debian has choosen to implement multiarch, which amongs other things, > means that the includes and libraries are moved in a new "multiarch" > path. This breaks some upstream applications and non-Debian toolchain. [...] > I got fed up by people reporting bug on libc6, while this problem results > from a decision Debian to implement multiarch. People should work on > implementing a compatibility wrapper and to make upstream toolchain > multiarch aware. Until this is done, this bug should be ke
Bug#644986: marked as done (i386: Compiling gcc-snapshots from upstream with multiarch-toolchain?)
Your message dated Mon, 27 Jul 2020 18:05:22 +0200 with message-id <2ea4db46667572b33b5148a72025785732318b06.ca...@43-1.org> and subject line Re: general: Multiarch breaks support for non-multiarch toolchain has caused the Debian Bug report #637232, regarding i386: Compiling gcc-snapshots from upstream with multiarch-toolchain? to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 637232: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637232 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6-dev Version: 2.13-21 Severity: normal [ CCing debian-gcc ML ] Dear Maintainer, these problems here were already discussed on #multiarch and reported by me (see for example #636116 or #637218), but still exist. I did not check for a while the progress on the issues, so I am sorry for being uninformed and tapping on your nerves by unseen re-reporting. Personally, I am interested in helping to get the issues solved (for me this looks like a multiarch problem, but CCing debian-gcc folks as well). Again I tried to compile a gcc-4.7 snapshot tarball [1] with my (updated) build-script. ### Workaround #1: /usr/include/gnu/stubs-32.h # ls -l /usr/include/gnu/stubs-32.h lrwxrwxrwx 1 root root 32 Sep 5 17:19 /usr/include/gnu/stubs-32.h -> ../i386-linux-gnu/gnu/stubs-32.h # dpkg -S /usr/include/gnu/ libc6-dev-amd64: /usr/include/gnu # dpkg -S /usr/include/i386-linux-gnu/gnu/stubs-32.h libc6-dev: /usr/include/i386-linux-gnu/gnu/stubs-32.h Q: Is it possible to have this symlink when both (libc6-dev-amd64 and libc6-dev) packages are installed? ### Workaround #2: /usr/lib/crt*.o # ls -l /usr/lib/crt*.o lrwxrwxrwx 1 root root 21 Sep 5 18:24 /usr/lib/crt1.o -> i386-linux-gnu/crt1.o lrwxrwxrwx 1 root root 21 Sep 5 18:24 /usr/lib/crti.o -> i386-linux-gnu/crti.o lrwxrwxrwx 1 root root 21 Sep 5 18:24 /usr/lib/crtn.o -> i386-linux-gnu/crtn.o # dpkg -S /usr/lib/i386-linux-gnu/crt*.o libc6-dev: /usr/lib/i386-linux-gnu/crt1.o libc6-dev: /usr/lib/i386-linux-gnu/crti.o libc6-dev: /usr/lib/i386-linux-gnu/crtn.o # dpkg -S /usr/lib64/crt*.o libc6-dev-amd64: /usr/lib64/crt1.o libc6-dev-amd64: /usr/lib64/crti.o libc6-dev-amd64: /usr/lib64/crtn.o # locate crt1.o crti.o crtn.o | grep ^/usr/lib | egrep -v 'gcrt1.o|Mcrt1.o|Scrt1.o' | sort /usr/lib64/crt1.o /usr/lib64/crti.o /usr/lib64/crtn.o /usr/lib/crt1.o <--- SELF-CREATED symlink /usr/lib/crti.o <--- SELF-CREATED symlink /usr/lib/crtn.o <--- SELF-CREATED symlink /usr/lib/i386-linux-gnu/crt1.o /usr/lib/i386-linux-gnu/crti.o /usr/lib/i386-linux-gnu/crtn.o Q: As you can see libc6-dev-amd64 places its crt*.o in /usr/lib64/, so why should libc6-dev NOT (logically) place same files below /usr/lib/ (as symlinks)? CONCLUSION: I am unsure if I should split this bug-report, but both issues affect the same Debian package and could IMHO easily solved by creating appropriate symlinks. NOTE: A succesfully compiled gcc upstream snapshot tarballs is a testcase for me before I start any compilation of a MIPSEL toolchain for a router project called freetz. Regards, - Sedat (dileks) - P.S.: ATTACHMENTS: 1. build-script 2. make logs [1] ftp://sourceware.org/pub/gcc/snapshots/LATEST-4.7/gcc-4.7-20111008.tar.bz2 [2] http://freetz.org -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.0-rc4-next20110831.9-686-small (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6-dev depends on: ii libc-dev-bin2.13-21 ii libc6 2.13-21 ii linux-libc-dev 3.0.0-5 Versions of packages libc6-dev recommends: ii gcc [c-compiler] 4:4.6.1-3 ii gcc-4.4 [c-compiler] 4.4.6-11 ii gcc-4.5 [c-compiler] 4.5.3-9 ii gcc-4.6 [c-compiler] 4.6.1-15 ii gcc-4.7 [c-compiler] 20111008-1 <--- SELF-CREATED dummy package (done with equivs) Versions of packages libc6-dev suggests: pn glibc-doc pn manpages-dev -- no debconf information build_gcc-snapshot.sh Description: Bourne shell script make.log.xz Description: Binary data make.log_continue.xz Description: Binary data make.log_continue-2.xz Description: Binary data make.log_continue-3.xz Description: Binary data --- End Message --- --- Begin Message --- On Tue, 09 Aug 2011 19:31:56 +0200 Aurelien Jarno wrote: > Debian has choosen to implement multiarch, which amongs other things, > means that the includes and libraries are moved in a new "multiarch" > path. This breaks some upstream application
Re: CTTE requesting questions for DebConf20 BoF
Hi Sean and the rest of the tech-ctte! 1st, thanks for preparing this BoF! In general I liked what I read, I just have a question or maybe two... On Sun, Jul 26, 2020 at 01:37:10PM -0700, Sean Whitton wrote: > **Proposal 2**: Explicitly delegate the mediation task for solving > social conflict between developers, when no code-of-conduct violation is > in place. This could be to: > > a. A new group of developers > b. The Community Team > c. The Technical Committee. which of the three options does the tech-ctte (roughly) prefer? > Allow design work > - > **Proposal 3**: Modify the Constitution to allow the TC to do design > work in the form of proposals. These proposals wouldn't override > developers or tell individual maintainers what to do, but rather should > guide the project towards a technical goal. I'm continued to be puzzled about this. Clearly you are all individuals, why don't you do design work as individuals? -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Bug#965151: /usr/bin/tx: transifex-client and afdko shipping binaries under the same name
(CC to @paravoid as original reporter of the same issue) On Sun, Jul 26, 2020 at 05:04:42AM +, Paul Wise wrote: > This sort of thing needs to happen upstream first. I reported it, without noticing that they had the same report third time, and it was not a charm, still marked as wontfix for compatibility of existing scripts. https://github.com/adobe-type-tools/afdko/issues/1196 https://github.com/adobe-type-tools/afdko/issues/1162 https://github.com/adobe-type-tools/afdko/issues/672 signature.asc Description: PGP signature
