Re: Alioth: the future of mailing lists
On Mon, Sep 18, 2017 at 09:53:43PM +0200, Alexander Wirt wrote: > > I have managed mailman installations for some time so I'm fairly familiar > > with how it works, and have some time from November onwards to work on > > this which I hope would be enough time to develop and implement a migration > > plan. I'm CCing the alioth and DSA teams so they are aware of this. > Do you have infrastructure for running it? (as I understand it…) Alexander's point is that mailman needs root access and DSA is not happy^wwilling to hand out root (anymore for this). -- cheers, Holger signature.asc Description: Digital signature
Re: Alioth: the future of mailing lists
On Mon, 18 Sep 2017, Dominic Hargreaves wrote: > On Mon, Sep 18, 2017 at 09:22:34AM +, Holger Levsen wrote: > > On Mon, Sep 18, 2017 at 01:57:31AM +0100, peter green wrote: > > > Just because a team isn't big or established doesn't mean they don't need > > > a place to discuss issues relating to their activities, some of which do > > > not relate to any one particular package. Contributers should be able to > > > self-organise within the project and for many dds email is their primary > > > means of communication. Sure you can just cc everyone involved but then > > > there is no archive and no way for new contributers to jump in. > > > > agreed. > > > > > I find the current proposal to drop alioth mailing lists without a real > > > replacement to be a major step backwards. > > > > fully agreed. > > > > However, I also fully understand and support the decision of those who want > > to > > maintain git.debian.org (or whatever the DNS name will be) in future, that > > they don't want to migrate+run lists.alioth.debian.org as well. > > > > So given all that, I would also applaud other people who want to keep > > lists.alioth.d.o running. (As one third of all binary packages in main > > currently use such an address in the maintainers or uploaders field… (*)) > > I am willing to step up to help keep lists.alioth.debian.org running > as a standalone service using mailman. It seems like it is yet to be > resolved whether this is a long-term strategic option, but this > thread demonstrates the many practical reason that we should aim to > maintain it beyond February 2018. Maintaining the current service > separated out from Alioth would, it appears, reduce the impact on the > project of the alioth switch-off considerably. The main requirements/ > issues seem to be: > > - retaining archives (ideally with consistent URLs) > - retaining the email addresses in many maintainer fields > - short-term uncertainty about replacements for certain use cases > > I have managed mailman installations for some time so I'm fairly familiar > with how it works, and have some time from November onwards to work on > this which I hope would be enough time to develop and implement a migration > plan. I'm CCing the alioth and DSA teams so they are aware of this. Do you have infrastructure for running it? Alex
Re: How to start a new packaging team now?
On Mon, 18 Sep 2017, Michael Biebl wrote: > Am 18.09.2017 um 18:00 schrieb Jonathan Carter (highvoltage): > > > Well, it's not official yet of course but salsa.debian.org is running > > GitLab and it seems like the likely Alioth replacement. > Do I need to create a new user account for salsa.debian.org or can I use > my existing Debian account? When its ready, it will import you debian account. But it will not use the ud-ldap password. Alex signature.asc Description: PGP signature
Re: How to start a new packaging team now?
Am 18.09.2017 um 18:00 schrieb Jonathan Carter (highvoltage): > Well, it's not official yet of course but salsa.debian.org is running > GitLab and it seems like the likely Alioth replacement. Do I need to create a new user account for salsa.debian.org or can I use my existing Debian account? signature.asc Description: OpenPGP digital signature
Re: Alioth: the future of mailing lists
❦ 18 septembre 2017 14:55 +0200, Raphael Hertzog : > Hum, that documentation is a bit outdated. What you have to use is > actually dispatch+@tracker.debian.org. But I would not want > people to use this email address in Maintainer fields. > > Instead we should use @packages.debian.org. But for this we > need a lintian upload and a lintian backport to be installed on > ftp-master: > https://bugs.debian.org/871575 Would any of those solutions also email the uploaders or recent people in d/changelog? This would be helpful for NMU as well as for team-maintained packages in a large team. For example, I am part of the Debian Python Modules Team but there are so many packages that I can't follow the mailing list. Therefore, I miss bugs from "my" packages due to the "noise". I still catch RC bugs by looking at the maintainer dashboard, but for anything else... -- It is often the case that the man who can't tell a lie thinks he is the best judge of one. -- Mark Twain, "Pudd'nhead Wilson's Calendar" signature.asc Description: PGP signature
Re: Summary of the 2038 BoF at DC17
On Mon, Sep 18, 2017 at 05:46:34PM +0100, Ian Jackson wrote:
>Steve McIntyre writes ("Re: Summary of the 2038 BoF at DC17"):
>> It depends on how/where/why you're embedding 64-bit time,
>> basically. If you're embedding a time_t (or a struct including a
>> time_t) in your ABI and want to keep to something similar, it's worth
>> waiting to see what's going to be standardised then using that.
>
>Are you saying that if I am designing an API/ABI now I should write:
>
> typedef struct {
>blah blah;
>time_t whenever;
>blah blah;
> } MyAPIThing;
>
>rather than
>
> typedef struct {
>blah blah;
>uint64_t whenever;
>blah blah;
> } MyAPIThing;
>
>? Really ?
>
>I think that's bad advice.
Yes, really. You've now hidden that you're storing time data by using
another data type, which makes things much harder to find if anybody
else is scanning for time-handling code. And you've made assumptions
about how new time-handling APIs are likely to look in the near-ish
future when people have worked everything out and agreed new
standards. If the new stuff ends up using a different representation
with 96 or even 128 bits in total, I'd argue that it's cleaner to wait
for that and not gamble.
>I would do the latter. Even though that means writing library code
>internally that checks whether the supplied value of `whenever' fits
>in whatever the system calls a time_t.
Your code, your choice...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Mature Sporty Personal
More Innovation More Adult
A Man in Dandism
Powered Midship Specialty
Re: How to start a new packaging team now?
On Mon, Sep 18, 2017 at 12:00 PM, Jonathan Carter (highvoltage) wrote: > Great! I've also thinking about started a team for all the gnome-shell > extensions we have in Debian. The Debian Qt/KDE team has a complementary > Debian KDE Extras team (see https://pkg-kde.alioth.debian.org/ for more > information), I wonder if it might be worth while considering having a > GNOME Extras team for all the GNOME related stuff that isn't part of > upstream GNOME? I think there are at least 2 kinds of "extras": 1. Stuff that's currently being developed but isn't part of the core desktop 2. Deprecated and/or unmaintained stuff like the reverse-depends of src:libgnome which the Debian GNOME team would like to remove from Debian, but it's a bit hard to remove stuff that apparently still works for someone. Some example of #1 that aren't in Debian yet are glom (hosted on GNOME infrastructure but otherwise not really considered part of GNOME) and lollypop (hosted on GitHub). GNOME Shell extensions could be maintained with the same team as GTK+ themes although they are only usable in one desktop but the themes are cross-desktop. > Well, it's not official yet of course but salsa.debian.org is running > GitLab and it seems like the likely Alioth replacement. I think it would > be less disruptive to use a project on gitlab.org and get used to its > tools, which should make it easier to move the project onto Debian > infrastructure than from Launchpad.net. Although, Launchpad.net would be > preferable to Github, at least Launchpad.net is now free software. I was expecting to probably just use collab-maint git for now. The packaging hosting wasn't as big of a concern to me as the Maintainer field for a new packaging team (which is being discussed in multiple threads on debian-devel now). Thanks, Jeremy Bicha
Re: Summary of the 2038 BoF at DC17
Steve McIntyre writes ("Re: Summary of the 2038 BoF at DC17"):
> It depends on how/where/why you're embedding 64-bit time,
> basically. If you're embedding a time_t (or a struct including a
> time_t) in your ABI and want to keep to something similar, it's worth
> waiting to see what's going to be standardised then using that.
Are you saying that if I am designing an API/ABI now I should write:
typedef struct {
blah blah;
time_t whenever;
blah blah;
} MyAPIThing;
rather than
typedef struct {
blah blah;
uint64_t whenever;
blah blah;
} MyAPIThing;
? Really ?
I think that's bad advice.
I would do the latter. Even though that means writing library code
internally that checks whether the supplied value of `whenever' fits
in whatever the system calls a time_t.
Ian.
Re: How to start a new packaging team now?
Hey Jeremy On 15/09/2017 18:39, Jeremy Bicha wrote: > I have been thinking for a while of starting a new packaging team for > desktop themes (especially GTK+ and GNOME themes since so many > desktops can use them). Great! I've also thinking about started a team for all the gnome-shell extensions we have in Debian. The Debian Qt/KDE team has a complementary Debian KDE Extras team (see https://pkg-kde.alioth.debian.org/ for more information), I wonder if it might be worth while considering having a GNOME Extras team for all the GNOME related stuff that isn't part of upstream GNOME? > Now that Alioth is beginning to close down and its replacement is not > yet ready, how would I start this team now? Well, it's not official yet of course but salsa.debian.org is running GitLab and it seems like the likely Alioth replacement. I think it would be less disruptive to use a project on gitlab.org and get used to its tools, which should make it easier to move the project onto Debian infrastructure than from Launchpad.net. Although, Launchpad.net would be preferable to Github, at least Launchpad.net is now free software. -Jonathan
Re: pasting license text into debian/copyright
On Saturday, 16 September 2017 23:13:04 CEST Andrey Rahmatullin wrote: > Changing a long free-form text file into a deb822 multiline block, when > you want to use the "machine-readable" format. You can do this with cme. Either launch cme GUI with 'cme edit dpkg-copyright'. You can paste the license content in the tree widget on the left side. See [1] for more details Or you can try the fuse interface: $ cd pkg_dir $ mkdir fuse $ cme fusefs dpkg-copyright -fuse-dir fuse/ $ ls fuse Comment Copyright Disclaimer Files Files-Excluded Format Global-License License Source Upstream-Contact Upstream-Name $ ls fuse/License/ LGPL-2.1 $ cat fuse/License/LGPL-2.1/text This program is free software; you can redistribute it and/or modify it [snip] $ mkdir fuse/License/Test $ echo "yada yada" > fuse/License/Test/text $ fusermount -u fuse $ git diff diff --git a/debian/copyright b/debian/copyright index b631507..913af34 100644 --- a/debian/copyright +++ b/debian/copyright @@ -18,3 +18,6 @@ License: LGPL-2.1 . On Debian systems, the complete text of version 2.1 of the GNU Lesser General Public License can be found in `/usr/share/common-licenses/LGPL-2.1'. + +License: Test + yada yada See the diff above. cme takes care of indenting and inserting '.' where needed. HTH [1] https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme#maintaining-debian-copyright-file -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: Alioth: the future of mailing lists
Dominic Hargreaves: > I am willing to step up to help keep lists.alioth.debian.org running > as a standalone service using mailman. It seems like it is yet to be > resolved whether this is a long-term strategic option, but this > thread demonstrates the many practical reason that we should aim to > maintain it beyond February 2018. Thanks for stepping up, I'd be pleased to help you with the setup and maintainance. > I have managed mailman installations for some time so I'm fairly familiar > with how it works, and have some time from November onwards to work on > this which I hope would be enough time to develop and implement a migration > plan. Same here, both Mailman experience and availability from November onwards. Cheers! Alex signature.asc Description: PGP signature
Re: Summary of the 2038 BoF at DC17
In article <10e4fa4a-433c-a43b-1136-984293497...@p10link.net> you write: >> Firstly: developers trying to be *too* clever are likely to only make >> things worse - don't do it! Whatever you do in your code, don't bodge >> around the 32-bit time_t problem. *Don't* store time values in weird >> formats, and don't assume things about it to "avoid" porting >> problems. These are all going to cause pain in the future as we try to >> fix problems. >> >> For the time being in your code, *use* time_t and expect an ABI break >> down the road. This is the best plan *for now*. > >I find this argument unconvincing. > >If a library is new or is going to have an ABI break anyway then by >moving to 64-bit time in it's interfaces now it can avoid another ABI >break down the road. It depends on how/where/why you're embedding 64-bit time, basically. If you're embedding a time_t (or a struct including a time_t) in your ABI and want to keep to something similar, it's worth waiting to see what's going to be standardised then using that. If you don't care and want to go your own way, then fine - but you might end up having to do conversions to/from the new standard stuff. But (please $deity!) avoid the temptation to do something "clever" like using a double or similar to store large values where precision matters. >Similarly if someone is introducing a new version of a file format >anyway moving to 64-bit time at the same time as making other changes >avoids breaking things twice. Now in this case, *definitely* it's worth doing it right now - as suggested in the session. On-disk formats are always going to be specific and you can invent your own solution however you like. -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
Re: Is bash-completion orphaned?
Hello, Il 18 Set 2017 13:24, "Axel Beckert" ha scritto: Since you granted the MIA team to orphan your packages as necessary, and since you seem to be the only bash-completion team member, I plan to declare bash-completion as orphaned officially after this mail. I hope you're still fine with that. Fine with that, yes. And sorry for not doing so before. I still hope to get some free time sooner or later.. Have a nice day, David
Re: Alioth: the future of mailing lists
Hi, On Mon, 18 Sep 2017, Paul Wise wrote: > If the Maintainer field is going to be completely deterministic based > on the package name, we should probably just change dak/BTS/etc to > mail those addresses instead of making dak put those addresses in > Maintainer fields in Sources/Packages or updating almost every package > in the archive. I would be fine with that. But I don't put this as a pre-requisite to any change. That's the kind of decision that we are not able to take very well collectively due to lots of inertia. > There are a number of non-Debian mailing lists in Maintainer fields > though, do we want to drop support for that? There are a couple of mailing lists already subscribed to the package tracker so they could do the same if they want to continue to get the same traffic (without appearing in the Maintainer field). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Alioth: the future of mailing lists
On Mon, Sep 18, 2017 at 8:55 PM, Raphael Hertzog wrote: > Instead we should use @packages.debian.org. If the Maintainer field is going to be completely deterministic based on the package name, we should probably just change dak/BTS/etc to mail those addresses instead of making dak put those addresses in Maintainer fields in Sources/Packages or updating almost every package in the archive. There are a number of non-Debian mailing lists in Maintainer fields though, do we want to drop support for that? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Alioth: the future of mailing lists
Hello Axel, On Mon, 18 Sep 2017, Axel Beckert wrote: > Alexander Wirt wrote: > > - Distribution lists for use in the Maintainer: field. We suggest > > that, with maybe some extra code, this use-case could be well served > > by the tracker.debian.org service for almost all purposes. > > Reading https://tracker.debian.org/docs/about.html#email-interface it > seems that the e-mail address @tracker.debian.org is usable > not only for tracker-generated mails. Hum, that documentation is a bit outdated. What you have to use is actually dispatch+@tracker.debian.org. But I would not want people to use this email address in Maintainer fields. Instead we should use @packages.debian.org. But for this we need a lintian upload and a lintian backport to be installed on ftp-master: https://bugs.debian.org/871575 (I filed this after https://lists.debian.org/debian-devel/2017/08/msg00247.html ) > Please advice and update > https://wiki.debian.org/Alioth#Clarification_Request_.2F_Open_Questions > accordingly. I did not do that, feel free to do it based on my answers. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#876095: O: bash-completion -- programmable completion for the bash shell
Package: wnpp The current maintainer of bash-completion, David Paleino (Cc'ed), currently lacks time to work on this package and granted the MIA team to orphan his packages as necessary. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: bash-completion Version: 1:2.1-4.3 Installed-Size: 1220 Maintainer: Bash Completion Maintainers Architecture: all Replaces: bash, cryptsetup (<< 2:1.1.2-2), xen-tools (<= 4.1-1) Depends: bash (>= 3.2) Pre-Depends: dpkg (>= 1.15.7.2~) Breaks: xen-tools (<= 4.1-1) Description-en: programmable completion for the bash shell bash completion extends bash's standard completion behavior to achieve complex command lines with just a few keystrokes. This project was conceived to produce programmable completion routines for the most common Linux/UNIX commands, reducing the amount of typing sysadmins and programmers need to do on a daily basis. Multi-Arch: foreign Homepage: http://bash-completion.alioth.debian.org Tag: implemented-in::shell, interface::shell, role::plugin Section: shells Priority: standard Size: 178338 Package: bash-completion Binary: bash-completion Version: 1:2.1-4.3 Maintainer: Bash Completion Maintainers Uploaders: David Paleino Build-Depends: debhelper (>= 9~), dh-autoreconf Build-Depends-Indep: perl Architecture: all Standards-Version: 3.9.5 Format: 3.0 (quilt) Vcs-Browser: http://anonscm.debian.org/gitweb/?p=bash-completion/debian.git Vcs-Git: git://anonscm.debian.org/bash-completion/debian.git Homepage: http://bash-completion.alioth.debian.org Package-List: bash-completion deb shells standard arch=all Directory: pool/main/b/bash-completion Priority: source Section: shells Please also notice that there seems new upstream development at https://github.com/scop/bash-completion/, so one of the tasks for the new maintainer is to update the package to the most recent upstream release. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: Digital signature
Re: Alioth: the future of mailing lists
On Mon, Sep 18, 2017 at 09:22:34AM +, Holger Levsen wrote: > On Mon, Sep 18, 2017 at 01:57:31AM +0100, peter green wrote: > > Just because a team isn't big or established doesn't mean they don't need a > > place to discuss issues relating to their activities, some of which do not > > relate to any one particular package. Contributers should be able to > > self-organise within the project and for many dds email is their primary > > means of communication. Sure you can just cc everyone involved but then > > there is no archive and no way for new contributers to jump in. > > agreed. > > > I find the current proposal to drop alioth mailing lists without a real > > replacement to be a major step backwards. > > fully agreed. > > However, I also fully understand and support the decision of those who want to > maintain git.debian.org (or whatever the DNS name will be) in future, that > they don't want to migrate+run lists.alioth.debian.org as well. > > So given all that, I would also applaud other people who want to keep > lists.alioth.d.o running. (As one third of all binary packages in main > currently use such an address in the maintainers or uploaders field… (*)) I am willing to step up to help keep lists.alioth.debian.org running as a standalone service using mailman. It seems like it is yet to be resolved whether this is a long-term strategic option, but this thread demonstrates the many practical reason that we should aim to maintain it beyond February 2018. Maintaining the current service separated out from Alioth would, it appears, reduce the impact on the project of the alioth switch-off considerably. The main requirements/ issues seem to be: - retaining archives (ideally with consistent URLs) - retaining the email addresses in many maintainer fields - short-term uncertainty about replacements for certain use cases I have managed mailman installations for some time so I'm fairly familiar with how it works, and have some time from November onwards to work on this which I hope would be enough time to develop and implement a migration plan. I'm CCing the alioth and DSA teams so they are aware of this. Thanks, Dominic.
Bug#876091: ITP: node-module-deps -- walk the dependency graph to generate json output that can be fed into browser-pack
Package: wnpp Severity: wishlist Owner: ro...@debian.org X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-module-deps Version : 4.1.1 Upstream Author : James Halliday (http://substack.net) * URL : https://github.com/substack/module-deps * License : Expat Programming Lang: JavaScript Description : walk the dependency graph to generate json output that can be fed into browser-pack This modules creates a dependency graph allowing browserify to embed all modules in a single object. . Browserify is a JavaScript tool that allows developers to write Node.js-style modules that compile for use in the browser . Node.js is an event-based server-side JavaScript engine.
Re: Is bash-completion orphaned?
Hi Hakan, Hakan Peker wrote: > Subject: Is bash-completion orphaned? > > Last non-NMU upload happened 3 years ago and version in sid is 2.1. > > Development seems to be moved over to Github > (https://github.com/scop/bash-completion/). Latest release there is > 2.7 from last July. Thanks for the heads up! It's not declared orphaned, but it should be: David, the maintainer of the bash-completion package currently doesn't have time for it. I'm cc'ing him and the bash-completion packaging mailing list. David: Since you granted the MIA team to orphan your packages as necessary, and since you seem to be the only bash-completion team member, I plan to declare bash-completion as orphaned officially after this mail. I hope you're still fine with that. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: Digital signature
Re: Alioth: the future of mailing lists
Hi, Alexander Wirt wrote: > - Distribution lists for use in the Maintainer: field. We suggest > that, with maybe some extra code, this use-case could be well served > by the tracker.debian.org service for almost all purposes. Reading https://tracker.debian.org/docs/about.html#email-interface it seems that the e-mail address @tracker.debian.org is usable not only for tracker-generated mails. But then again, I haven't received any of my test mails to such addresses. So how exactly shall we use the tracker.debian.org service inside a Maintainer field instead of a @lists.alioth.debian.org mailing list? Please advice and update https://wiki.debian.org/Alioth#Clarification_Request_.2F_Open_Questions accordingly. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: Digital signature
Bug#876083: ITP: zsh-theme-powerlevel9k -- theme for zsh which uses powerline fonts
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: zsh-theme-powerlevel9k Version : 0.6.4-1 Upstream Author : Ben Hilburn * URL : https://github.com/bhilburn/powerlevel9k * License : expat Programming Lang: zsh Description : theme for zsh which uses powerline fonts Powerlevel9k is a theme for zsh which uses powerline fonts Get more out of your terminal. Be a badass. Impress everyone in 'Screenshot Your Desktop' threads. Use powerlevel9k. There are a number of Powerline ZSH themes available, now. The developers of this theme focus on four primary goals: - Give users a great out-of-the-box configuration with no additional configuration required. - Make customization easy for users who do want to tweak their prompt. - Provide useful segments that you can enable to make your prompt even more effective and helpful. We have prompt segments for everything from unit test coverage to your AWS instance. - Optimize the code for execution speed as much as possible. A snappy terminal is a happy terminal. - Powerlevel9k can be used to create both very useful and beautiful terminal environments. For more information about powerlevel9k, please see above URL.
Re: Alioth: the future of mailing lists
On Mon, Sep 18, 2017 at 01:57:31AM +0100, peter green wrote: > Just because a team isn't big or established doesn't mean they don't need a > place to discuss issues relating to their activities, some of which do not > relate to any one particular package. Contributers should be able to > self-organise within the project and for many dds email is their primary > means of communication. Sure you can just cc everyone involved but then there > is no archive and no way for new contributers to jump in. agreed. > I find the current proposal to drop alioth mailing lists without a real > replacement to be a major step backwards. fully agreed. However, I also fully understand and support the decision of those who want to maintain git.debian.org (or whatever the DNS name will be) in future, that they don't want to migrate+run lists.alioth.debian.org as well. So given all that, I would also applaud other people who want to keep lists.alioth.d.o running. (As one third of all binary packages in main currently use such an address in the maintainers or uploaders field… (*)) -- cheers, Holger (*) which as other people already pointed out will also effect stable. signature.asc Description: Digital signature
Re: Summary of the Arm ports BoF at DC17
On Sun, 2017-09-17 at 12:59 -0700, Vagrant Cascadian wrote: > On 2017-09-15, Ben Hutchings wrote: > > On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote: > > [...] > >> There is optional kernel support to trap the exceptions here > >> and emulate the instructions, but it's really not recommended for > >> serious use (e.g. on a build machine!). > > [...] > > > > Why is it not recommended? Terrible performance, or known bugs? > > On arm64 kernels building armhf packages for the reproducible builds > builders, I'm seeing hundreds or even thousands of kernel log warnings > per second when building anything that makes use of > CP15_BARRIER_EMULATION (e.g. anything using ghc): > > [85740.553537] cp15barrier_handler: 115316 callbacks suppressed > [85740.559358] "ghc-pkg" (29572) uses deprecated CP15 Barrier instruction > at 0xf5beaa7c > [85740.567344] "ghc-pkg" (29572) uses deprecated CP15 Barrier instruction > at 0xf5beaa9c > > That *might* be sufficient to actually impact performance; it certainly > makes it hard to read other kernel log messages on those machines... I bet it does! I was a bit surprised to find in the docs that there was no "silently emulate" option in the proc interface, seems my memory was faulty there. But it did remind me that on some platforms writing "2" to /proc/sys/abi/cp15_barrier will enable hw support for these instructions, since some platforms do support them even thought they are deprecated. It's certainly worth investigating what your hardware supports. Ian.
