Re: armel/armhf arch qualification for buster: call for DSA, Security, toolchain concernsj
Dear armel/armhf shakeholders, I talked to a few people about keeping armel in buster, during 1st and 2nd day in debcamp. Seems the blocker is just the buildd server hardware, and memory size it has. On Fri, Jun 29, 2018 at 7:04 PM, W. Martin Borgert wrote: > > Quoting Uwe Kleine-König : >> >> If the concerns are mostly about the hardware not being rackable, there >> is a rackable NAS by Netgear: >> >> >> https://www.netgear.com/business/products/storage/readynas/RN2120.aspx#tab-techspecs > > This seems to be out of stock and discontinued, unfortunately. This is still available in amazon: - https://www.amazon.com/dp/B00MQK14KC > Anyway, I'm relatively sure, that I can convince my boss to sponsor/donate > both armel and armhf hardware for Debian, if that is of any help. Or arm64 > used in "32 bits mode". I think DSA team prefers armel or armhf real hardware (not just developing boards). So it'll be super great if you (or your boss) can kindly sponsor some armel/armhf hardwares that support to install 4GB memory. Thanks! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: request to rebuild my package libcork (FTBFS on landau, but was built OK on andi)
On Thu, Oct 6, 2016 at 9:35 PM, James Clarke wrote: > > Yes, that looks fine. Have you forwarded it upstream? The upstream is not active anymore. Like I submit your patch monthly ago [0], but no reply yet. [0] https://github.com/redjack/libcork/issues/118 >> Do you think it's a good idea to avoid transition? > > If you’re doing that, I would consult other people (IRC is a good source), as > I > don’t know all the subtleties about package renaming and only have [1] to go > on. > However, IMO, given that you only have two reverse dependencies (namely > src:shadowsocks-libev and src:libcorkipset), I would just do a transition and > avoid picking up the cruft (and potential confusion), but I don’t have much > experience of these things. Accepted your suggestion, and now I finished the transition [1] It's not so difficult as expected. :-) After the transition, I applied your patch and made an experimental release [2]. Problem seems solved by confirming the buildd status [3] sparc64 can be built normally now, and other ARCHs aren't affected (yet, because some are waiting to start the build). Problem seems solved, so thank you so much for your help! [1] https://release.debian.org/transitions/html/auto-libcork.html [2] https://github.com/rogers0/libcork/commit/54357a [3] https://buildd.debian.org/status/logs.php?pkg=libcork&arch=sparc64 Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: request to rebuild my package libcork (FTBFS on landau, but was built OK on andi)
Dear James,
Thanks for your patch!
And sorry for my late reply..
I'm trying to handle the SONAME first, since the transition freeze
will come soon.
(although I'll try to not get involved in transition. explaining below)
On Mon, Aug 29, 2016 at 10:23 PM, James Clarke wrote:
>
> Whilst building the package, I couldn’t help but notice that libcork15
> contains
> libcork.so.15, which is a symlink to libcork.so.16.0.1. This is clearly very
> very wrong (package name should be bumped up to libcork16, and the symlink
> should be called libcork.so.16). The cause of this is a crazy calculation in
> upstream’s cmake/FindCTargets.cmake, where on line 66 it does:
>
> math(EXPR __SOVERSION "${__VERSION_CURRENT} - ${__VERSION_AGE}”)
I created the patch, just works as you suggested.
So could you kindly help to review it?
- https://github.com/rogers0/libcork/commit/8d45ec
> This is then used to create the libcork.so.$__SOVERSION symlink, and given
> that
> __VERSION_CURRENT is 16 and __VERSION_AGE is 1, it calculates 16-1=15.
> __SOVERSION and __VERSION_CURRENT should be the same thing. Please request a
> transition, patch FindCTargets.cmake, bump the package name up to libcork16,
> upload the fixed version and file binNMUs. And, of course, get upstream
> patched.
Since there's no ABI change from libcork15 to libcork16, they should
be no problem to replace the old with the new.
So here's my solution:
- https://github.com/rogers0/libcork/commit/f222c5
Do you think it's a good idea to avoid transition?
I have tried to install the local built packages (including above two
commits) on my PC with other packages depending on libcork15, so I
confirm the installation is with no problem:
# dpkg -i libcork16_0.15.0+ds-7_amd64.deb libcork-dev_0.15.0+ds-7_amd64.deb
Selecting previously unselected package libcork16:amd64.
dpkg: considering removing libcork15:amd64 in favour of libcork16:amd64 ...
dpkg: yes, will remove libcork15:amd64 in favour of libcork16:amd64
(Reading database ... 277621 files and directories currently installed.)
Preparing to unpack libcork16_0.15.0+ds-7_amd64.deb ...
Unpacking libcork16:amd64 (0.15.0+ds-7) ...
Selecting previously unselected package libcork-dev:amd64.
Preparing to unpack libcork-dev_0.15.0+ds-7_amd64.deb ...
Unpacking libcork-dev:amd64 (0.15.0+ds-7) ...
Setting up libcork16:amd64 (0.15.0+ds-7) ...
Setting up libcork-dev:amd64 (0.15.0+ds-7) ...
Processing triggers for libc-bin (2.24-3) ...
I'll apply your patch after soname bumping up.
Thanks for your understanding!
Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Porter roll call for Debian Stretch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 17 Aug 2016 22:05:06 +0200 ni...@thykier.net wrote: > Like last release, we are doing a roll call for porters of all release > architectures. If you are an active porter behind one of the [release > architectures] for the entire lifetime of Debian Stretch (est. end of > 2020), please respond with a signed email containing the following > before Friday, the 9th of September: > Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the Stretch release (est. end of 2020): For armel, I - submit device-tree patch to upstream (linux kernel), and backport to debian kernel to get more devices supported - support new device for d-i and flash-kernel package - test most packages on this architecture - run Debian stable / testing / unstable system on port that I use regularly - triage arch-specific bugs - fix arch-related bugs - triage d-i bugs - test d-i regularly - fix d-i bugs/issues I am a DM. Altough I enabled -fPIE/-pie for most of my maintaining packages, I'm not sure / I don't have enough knowledge whether it's able to be applied to all packages. Since all other ARM porters seem agree on this, I believe it definitely deserves a try to enable this hardening on stretch. Cheers, - -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXzEFiAAoJEKR4aw2nAzSoAekP/j4eNf0jKvmArPlPbhA7XkBk /5u9Un4qOHBNcSMAU5YVLHkpnT1CX/C08W+/ctGbB9AnnRwyn8X0uailjedZ13jK oZYW/kUSwWiPmOkRTeNgFepzuKL+TNsAGgjHOY4ZbzYKC+h9C0UNWwyA77L3GUep 3HA9eTrtxMAAvJPNN4AhOjMeCI3qXIZ+wLKjhT+u/OUETWly8MolBw8PUjjwW6yy Va7ciRMQf8KL149+Pa/tYFaENoAOV6//3M2QkJyaGbfxJp3xiFFcrlw+kw6J4RyH vNIewz78nZwN88Y7JWa2EdBVcJr0897REXpDPXK/OpzlWw0R0xqB86jtmHfc+rQJ IiNGt5Uc4Y3mD04O6AEDDJFJnEQ/QLi8OR8/TuxHiBJ6JTv0m67KsJVgdFqeRnlz wJqcIQAzTF1iixVXjreVqW6P/+pGNHDbh9APfUz+UV97sZ4tD2BV1K1Rgk7cPDCn zcpVhkQRy5PzLmK315vb8h9juFDDS/18yzmXwGMnmIhv4+8GBJIQLm5gvk9NuEbw V/hBC42+fqX6RzGCoV3M8V+A6aLSpG/BcIAQOx8ewVfzMHIFSJmYParCHKXdiX+z WB8UBt2xCHuzg98jxU80UwR492X9WvKeb6xA8dKqOW22XzsLxaQTe+SLSaGQ7er2 cpuhCpYFDKj/TL6UE2f9 =Vckg -END PGP SIGNATURE-
