Re: Bug#842191: ITP: node-is-fullwidth-code-point -- Check if the character represented by a given Unicode code point is fullwidth
On Thu, Oct 27, 2016 at 10:00:37AM +0530, Pirate Praveen wrote:
> On Thursday 27 October 2016 02:21 AM, Adam Borowski wrote:
> > On Thu, Oct 27, 2016 at 12:49:31AM +0530, suhail_p wrote:
> >> * Package name: node-is-fullwidth-code-point
> >> Upstream Author : Sindre Sorhus
> >> (sindresorhus.com
> >> )
> >> * URL :
> >> https://github.com/sindresorhus/is-fullwidth-code-point#readme
> >> Description : Check if a given Unicode point is fullwidth
> >>
> >> A Nodejs modeule to check if the character represented by a given Unicode
> >> code point is fullwidth
> >
> > Wouldn't it be better to replace this with full wcwidth()? That'd give you
> > not only double-width chars but also controls ("width" -1), combining and
> > non-spacing (width 0).
>
> It is a dependency for https://github.com/sindresorhus/string-width you
> can suggest upstream to use this.
Well, but why would you use code that's so buggy? If it has literally one
job, it should at least do that job right.
I see string-width ignores controls (0..0x1f, 0x7f..0x9f) on its own, so
that's handled. It reacts to them differently than POSIX wcswidth()
(silently ignores instead of returning an error for the whole string) but
as there's no good answer that's acceptable.
But, without having a case for width 0, string-width fails to handle any
non-spacing or combining characters. The former happen quite often in text
produced by some software, sometimes even in surprising cases as plain
German words like "Auflage" -- without a ZWNJ between f and l they'd be
combined into a ligature. The latter are required for a number of
languages, such as Vietnamese which tends to decorate every letter with two
or more combining characters.
Thus, I recommend scrapping this ITP, and instead packaging one of many
implementations without these problems. One for these that looks rightish
is https://github.com/mycoboco/wcwidth.js
You would then patch string-width:
- if (isFullwidthCodePoint(code)) {
- width += 2;
- } else {
- width++;
- }
+ width += wcwidth(code);
--
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month. Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.
Re: When should we https our mirrors?
❦ 17 octobre 2016 20:49 +0200, Vincent Bernat : >> TL;DR: Would we now recommend deb.d.o over httpredir.d.o for production >> use e.g. in base images (including for Jessie)? > > I get a 404 from time to time. Doing a second apt full-upgrade fixes the > issue. This works far better than httpredir.d.o. When I said that, I was using cdn-fastly-v6.deb.debian.org (to also force use of IPv6 which is still in beta at fastly). I have now tried deb.debian.org and in a few days, I got numerous hash mismatchs that are solved only after a few apt-get update (while with Fastly, the occurrence of those are pretty rare and always solved with one apt-get update). E: Failed to fetch https://cdn-aws.deb.debian.org/debian-debug/dists/experimental-debug/main/binary-i386/Packages.xz Hash Sum mismatch Hashes of expected file: - Checksum-FileSize:124436 [weak] - SHA256:456db0daa2897f2a1918d202858416093fe163e03e51a4fdfa5acb9682d8cf87 - MD5Sum:aef14dfd0625cdd010f675799f661c92 [weak] Hashes of received file: - SHA256:7b7cdee86f411dec5d8d90df7333fb62c8f3ab887105b3481040f6bf77b4fb00 - MD5Sum:1b6c55acb2d216cdccb46fb4c5cef93a [weak] - Checksum-FileSize:124192 [weak] Last modification reported: Wed, 26 Oct 2016 21:07:55 + Release file created at: Thu, 27 Oct 2016 03:31:09 + I seem to always get redirected to Cloudfront. Moreover, the download speed can be very slow, either from work or from home (100M fiber connection). Sometimes 100kbytes/s. That's a pain. I am a bit worried for deb.debian.org to become a default as it doesn't work well for me. Am I alone to have such problems? -- The very ink with which all history is written is merely fluid prejudice. -- Mark Twain signature.asc Description: PGP signature
Bug#842227: ITP: node-loud-rejection -- Make unhandled promise rejections fail loudly instead of the default silent fail
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-loud-rejection Version : 1.6.0 Upstream Author : Sindre Sorhus (sindresorhus.com) * URL : https://github.com/sindresorhus/loud-rejection#readme * License : Expat Programming Lang: JavaScript Description : Make unhandled promise rejections fail loudly instead of the default silent fail signature.asc Description: OpenPGP digital signature
ITP: node-babel -- Generic multi-purpose compiler for JavaScript
Package: wnpp Severity: wishlist Owner: Lucas de Castro Borges * Package name: node-babel Version : 6.5.2 Upstream Author : Sebastian McKenzie * URL : https://babeljs.io/ * License : Expat Programming Lang: JavaScript Description : Generic multi-purpose compiler for JavaScript Babel is a generic multi-purpose compiler for JavaScript. Using Babel you can use (and create) the next generation of JavaScript, as well as the next generation of JavaScript tooling. . Node.js is an event-based server-side JavaScript engine. signature.asc Description: OpenPGP digital signature
Re: Bug#842191: ITP: node-is-fullwidth-code-point -- Check if the character represented by a given Unicode code point is fullwidth
On Thursday 27 October 2016 02:21 AM, Adam Borowski wrote:
> On Thu, Oct 27, 2016 at 12:49:31AM +0530, suhail_p wrote:
>> * Package name: node-is-fullwidth-code-point
>> Upstream Author : Sindre Sorhus (sindresorhus.com
>> )
>> * URL :
>> https://github.com/sindresorhus/is-fullwidth-code-point#readme
>> Description : Check if a given Unicode point is fullwidth
>>
>> A Nodejs modeule to check if the character represented by a given Unicode
>> code point is fullwidth
>
> Wouldn't it be better to replace this with full wcwidth()? That'd give you
> not only double-width chars but also controls ("width" -1), combining and
> non-spacing (width 0).
>
It is a dependency for https://github.com/sindresorhus/string-width you
can suggest upstream to use this.
signature.asc
Description: OpenPGP digital signature
Re: "PIE by default" transition is underway -- wiki needs updating
On Wed, Oct 26, 2016 at 05:26:24AM +0200, Guillem Jover wrote: > My point was that, yes we have changed to generating relocatable code > but that is still targetted for executables only, which preserves the > current behavior, [...] But something must have changed with how a static lib is now compiled, because (a) I see bug reports saying "foo broke because static libbar is not -fPIC" and (b) the recommended fix is to rebuild libbar with the new toolchain -- with no source changes. So what's going on with static libs? Thanks, -Steve signature.asc Description: PGP signature
Re: Planned NMU of w3-recs would use much archive disk space
On Thu, Oct 27, 2016 at 8:16 AM, Thaddeus H. Black wrote: > I am moving [1] to NMU a big non-free package, w3-recs [2][3], > last updated five years ago. During the last five years, > upstream has grown, both in volume [4] and in scope [5], for > legitimate reasons. The new *.orig.tar.gz or *.orig.tar.xz > would be about 200 GiB in size, six times what it is now. I think you mean 200 MiB? If so, that is not that big in the scheme of things IMO. > Advice? Go ahead if you meant 200 MiB. I'd suggest a package 'salvage', add yourself to the Uploaders. If the maintainer never surfaces, you can then remove them from Maintainer. You may want to also talk to the package sponsor and the MIA team: https://www.debian.org/doc/manuals/developers-reference/ch07.en.html#mia-qa -- bye, pabs https://wiki.debian.org/PaulWise
Planned NMU of w3-recs would use much archive disk space
I am moving [1] to NMU a big non-free package, w3-recs [2][3], last updated five years ago. During the last five years, upstream has grown, both in volume [4] and in scope [5], for legitimate reasons. The new *.orig.tar.gz or *.orig.tar.xz would be about 200 GiB in size, six times what it is now. 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836943 2: https://packages.debian.org/sid/w3-recs 3: https://tracker.debian.org/pkg/w3-recs 4: https://www.w3.org/TR/tr-date-all 5: https://www.w3.org/TR/html51/references.html#references The NMUed package would rank among the top 50 in size, might be the second biggest non-free package in stretch, and would be by far the heaviest upload I had ever made. That's a lot for an NMU. Unfortunately, without an NMU, this package would not be very useful to stretch users. I'd do what I could to trim the size, but this NMU will be big no matter what I do. Advice? Objections? signature.asc Description: Digital signature
Bug#842211: ITP: eeshow -- Schematics renderer and viewer for KiCad
Package: wnpp Severity: wishlist * Package name: eeshow Version : none, just git Upstream Author : Werner Almesberger * URL : https://neo900.org/stuff/eeshow/ * License : GPL2 Programming Lang: C Description : Schematics renderer and viewer for KiCad Eeshow is a collection of programs that read schematics made by KiCad Eeschema and can be used as interactive viewer, or as a command-line tool to convert schematics to PNG, PDF, Postscript, EPS, or FIG. Eeshow can show the differences between two versions of schematics sheets and it can retrieve files directly from a git repository. Eeshow was developed as part of the Neo900 project. Note: This program is not yet stable and probably not suitable for the upcoming Debian release. But having it in experimental would be nice, until it stabilises. Justification for packaging: Eeplot fills a gap: So far I was not able to produce a searchable PDF with KiCad, because it always made plotted lines from text. Eeplot does it right!
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
On 10/26/2016 10:35 PM, Theodore Ts'o wrote: > In the case of firmware which is flashed into non-volatile memory, I > would guess that the it probably wouldn't necessarliy use the > Microsoft signing key at all. (For example, for a long time most > printers were not bothering to do any digital signature checking at > all before installing a firmware update.) I think this is pretty much untrue, bugs non-withstanding. If the machine is booting in Secure Boot mode, the UEFI firmware is supposed to validate Option ROMs found on addon cards (PXE boot ROM, VGA BIOS, RAID adapter ROM) if executed on the main CPU. The printer example is not particularly relevant to that. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Re: Bug#842191: ITP: node-is-fullwidth-code-point -- Check if the character represented by a given Unicode code point is fullwidth
On Thu, Oct 27, 2016 at 12:49:31AM +0530, suhail_p wrote:
> * Package name: node-is-fullwidth-code-point
> Upstream Author : Sindre Sorhus (sindresorhus.com
> )
> * URL :
> https://github.com/sindresorhus/is-fullwidth-code-point#readme
> Description : Check if a given Unicode point is fullwidth
>
> A Nodejs modeule to check if the character represented by a given Unicode
> code point is fullwidth
Wouldn't it be better to replace this with full wcwidth()? That'd give you
not only double-width chars but also controls ("width" -1), combining and
non-spacing (width 0).
--
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month. Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.
Bug#842200: ITP: node-deprecated -- Tool for deprecating things
Package: wnpp Severity: wishlist Owner: Sagar Ippalpalli X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-deprecated Version: 0.0.1 Upstream Author: Fractal (http://wearefractal.com/) * URL : http://github.com/wearefractal/deprecated * License : Expat Programming Lang : JavaScript Description : Tool for deprecating things . Node.js is an event-based server-side JavaScript engine.
Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.
On Wed, Oct 26, 2016 at 08:42:07AM +0200, Philipp Kern wrote: > > To the extent that we could easily support this particular use case, > > it might be a good thing. (I doubt Debian is going to want to get > > into the business of verifying and then resigning firmware blobs.) > > Depends if you are then able to flash it into the addon card you have > (think VGA BIOS on an NVIDIA graphics card), which requires a) access to > some flash process and b) depending on that potentially a signature > trusted by the device to accept the update. So I guess I was assuming the use case where the firmware is dynamically loaded into RAM each time the machine boot. For example, this is how the Intel Wireless drivers' firmware is handled. I need to have the binary blob iwlwifi-8000C-22.ucode available on my system each time it boots, or the wifi card no talkee to the network. Since it is needed each time the system boots, and certain cases (for example, a firewire device which can do arbitrary, unrestricted, device-initiated DMA requests anywhere in host memory[1]), it would make sense that the firmware needs to be signed before it can be loaded. In the case of firmware which is flashed into non-volatile memory, I would guess that the it probably wouldn't necessarliy use the Microsoft signing key at all. (For example, for a long time most printers were not bothering to do any digital signature checking at all before installing a firmware update.) > Otherwise you end up with no graphics output on bootup because the > system is not trusting the blob on your graphics card to run. If you > screw it up too heavily, you can render your machine unbootable as well. > (I know a coworker succeeded in doing that when modifying the key set.) > Nothing a SPI programmer can't fix, but it'd be annoying nonetheless. I suspect that most firmwares that have to be flashed will need to be done using vendor-provided software. For example, on Lenovo systems, where you have to get the BIOS update on a bootable USB stick which you then boot. In that case it's largely orthogonal to Linux and Debian altogether. The problem would be more for firmwares which have to be loaded each time you boot Linux. Cheers, - Ted
Bug#842196: ITP: elpa-org-bullets -- show bullets in Org-mode as UTF-8 characters
Package: wnpp Severity: wishlist Owner: Lev Lamberov * Package name: elpa-org-bullets Version : 0.2.4 Upstream Author : Evgkeni Sampelnikof * URL : https://github.com/sabof/org-bullets * License : GPL-3+ Programming Lang: Emacs Lisp Description : show bullets in Org-mode as UTF-8 characters This package replaces the *s in Org-mode documents with bullets with fancy UTF-8 characters. Bullet face depend on the heading level of a particular string and can be redefined to be literally any character.
Resilience of ‘debbugs’ against spam (was: "Dear Customer" spam in the BTS)
Don Armstrong writes: > Any developer who is interested in volunteering and/or helping can > e-mail ow...@bugs.debian.org, and I promise to try to train people and > get them set up. Shall do. > [And/or write additional tools to make things easier.] To what extent does ‘debbugs’, the instrallable package, have tools for dealing with spam? How much is even feasible to include in the package for the benefit of other ‘debbugs’ installations? -- \“A thing is not necessarily true because a man dies for it.” | `\—Oscar Wilde, _The Portrait of Mr. W. H._, 1889-07 | _o__) | Ben Finney
Bug#842191: ITP: node-is-fullwidth-code-point -- Check if the character represented by a given Unicode code point is fullwidth
Package: wnpp Severity: wishlist Owner: Suhail P X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-is-fullwidth-code-point Version : 2.0.0 Upstream Author : Sindre Sorhus (sindresorhus.com ) * URL : https://github.com/sindresorhus/is-fullwidth-code-point#readme * License : Expat Programming Lang: JavaScript Description : Check if a given Unicode point is fullwidth A Nodejs modeule to check if the character represented by a given Unicode code point is fullwidth . Node.js is an event-based server-side JavaScript engine.
Re: "PIE by default" transition is underway -- wiki needs updating
Hi, On 26.10.2016 05:37, Adam Borowski wrote: > What's your reason for building something as big and with as extensive > dependencies statically? Some parts of the test suite use private functions not exposed in the shared libraries, so they need the static libraries. > Let's delegate static libraries to special needs only, as limited as possible. Yeah, I'll just not include the static libraries in the lib*-dev packages anymore. Best regards, Andreas
Bug#842189: ITP: node-parse-json -- Parse JSON with more helpful errors
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-parse-json Version : 2.2.0 Upstream Author : Sindre Sorhus (sindresorhus.com) * URL : https://github.com/sindresorhus/parse-json * License : Expat Programming Lang: JavaScript Description : Parse JSON with more helpful errors signature.asc Description: OpenPGP digital signature
Re: Bug#837478: "PIE by default" transition is underway -- wiki needs updating
Hi, On 26.10.2016 05:26, Guillem Jover wrote: > On Wed, 2016-10-26 at 00:37:18 +0200, Andreas Cadhalpun wrote: >> On 25.10.2016 13:55, Guillem Jover wrote: >>> For many static libraries, >>> making them embeddable into other shared libraries is really not >>> desirable. And those should be using the shared libraries instead. >> >> If that's the reason why it shouldn't be done, policy should mention it. >> The current policy does not list this as reason not to use -fPIC, merely: >> "since there is no benefit" > > I don't think it's "the reason", but personally I think it's one > important reason. If there are more, they could be mentioned in policy, too. > Embedding static libraries into shared libraries can be very > problematic if the shared libraries do not take precautions, such as > explicit symbol visibility or symbol versioning, etc. Which most > shared libraries do not do. And even then it's still prone to symbol > conflicts, etc, even inside the shared library being linked itself in > case of namespace issues, if the static library is sloppy. A (possibly shortened) version of this paragraph would be a good addition to the policy. :) > So I think this should be in general discouraged. > >>> I still think the current policy is fine, and if someone wants to build >>> a static library with PIC it should be brought up here. >> >> The current ffmpeg packages builds shared and static libraries, the >> latter because they are used in the test suite. Both are built from >> the same object files compiled with -fPIC. >> Do you really think those static libraries should not be included >> in the binary lib*-dev packages just because they are not incompatible >> with including in other shared libraries? > > Well, I guess depends on how "clean" they are, what's the intended > usage, etc. But given that in this case the usage is inside the same > project, that seems pretty safe! There might be some confusion here. The ffmpeg package uses these static libraries only for build-time testing, so doesn't need to have them included in the binary packages. I don't know if anyone is using these shipped static libraries. > I'd personally probably not ship them, > and would instead provide non-PIC ones there. Or at most ship them in > addition as _pic.a libraries, to require explicit invocation. I'd rather not built everything twice, so I think I'll just drop the static libraries in the next upload and only worry about this again, when/if someone files a bug about missing the static libraries. Best regards, Andreas
Bug#842188: ITP: systemfixtures -- Test fixtures providing fake versions of various system resources.
Package: wnpp Severity: wishlist Owner: Free Ekanayaka * Package name: systemfixtures Version : 0.3.3 Upstream Author : Free Ekanayaka * URL : https://github.com/freeekanayaka/systemfixtures * License : GPL Programming Lang: Python Description : Test fixtures providing fake versions of various system resources. A collection of Python fixtures to fake out various system resources such as processes, users, groups, etc. Each fake resource typically behaves as an "overlay" on the real resource, in that it can be programmed with fake behavior for a set of inputs, but falls back to the real behavior for the rest.
Bug#842185: ITP: node-spdx-exceptions -- list of SPDX standard license exceptions
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-spdx-exceptions Version : 2.0.0 Upstream Author : The Linux Foundation * URL : https://github.com/kemitchell/spdx-exceptions.json#readme * License : CC-BY-3.0 Programming Lang: JavaScript Description : list of SPDX standard license exceptions signature.asc Description: OpenPGP digital signature
Bug#842181: ITP: node-spdx-expression-parse -- parse SPDX license expressions
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-spdx-expression-parse Version : 1.0.4 Upstream Author : Kyle E. Mitchell (http://kemitchell.com) * URL : https://github.com/kemitchell/spdx-expression-parse.js#readme * License : (MIT AND CC-BY-3.0) Programming Lang: JavaScript Description : parse SPDX license expressions signature.asc Description: OpenPGP digital signature
Re: "Dear Customer" spam in the BTS
Hi Don, > > We do spamassassin with a huge set of rules. I don't think we're > currently using clamav in the BTS, but we are using it for Debian > mailing lists. > > [I'd certainly accept a patch to enable clamav; I personally haven't had > time to readdress using it.] if you are interested, I can send you the required master.cf and main.cf with my changes for spamassassin and clamav. I secured all the files, when I left the job. However, you will have to edit it a little bit, as I will of course remove the loacal IPs and things, which point to the server (I do not want to get in trouble). However, I believe, this server is no more online at all - but security before comfort! What do you think? Best Hans
Re: "Dear Customer" spam in the BTS
Hi Don, On Wed, 26 Oct 2016, Don Armstrong wrote: > On Wed, 26 Oct 2016, Hans wrote: > > What about spamassassin? Wouldn't spamassassin and its databases not be the > > better way? I made good experiences with spamassassin on my mail servers. > > We do spamassassin with a huge set of rules. I don't think we're > currently using clamav in the BTS, but we are using it for Debian > mailing lists. For the record, it would certainly be very welcome. We have many email providers that reject (and not silently discard) those messages at SMTP time (including gmail) and we also have many such emails forwarded from the BTS to the PTS. The result is that many PTS users have been unsubscribed because of all the mail that we sent them was bounced for 3 consecutive days (see #841061). I recently deployed a quick hack to teach the PTS to ignore bounces that look like bounces generated by spam/virus/executable attachment but it would be better if the BTS did not forward them at all. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: "Dear Customer" spam in the BTS
On Wed, 26 Oct 2016, Hans wrote: > What about spamassassin? Wouldn't spamassassin and its databases not be the > better way? I made good experiences with spamassassin on my mail servers. We do spamassassin with a huge set of rules. I don't think we're currently using clamav in the BTS, but we are using it for Debian mailing lists. [I'd certainly accept a patch to enable clamav; I personally haven't had time to readdress using it.] -- Don Armstrong https://www.donarmstrong.com Creativity can be a social contribution, but only in so far as society is free to use the results. -- Richard M Stallman _GNU Manifesto_
Bug#842175: ITP: node-find-up -- Find a file by walking up parent directories
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-find-up Version : 2.0.0 Upstream Author : Sindre Sorhus (sindresorhus.com) * URL : https://github.com/sindresorhus/find-up#readme * License : Expat Programming Lang: JavaScript Description : Find a file by walking up parent directories signature.asc Description: OpenPGP digital signature
Re: "Dear Customer" spam in the BTS
What about spamassassin? Wouldn't spamassassin and its databases not be the better way? I made good experiences with spamassassin on my mail servers. My configuration was a little bit weired, I admit. As I was using spamassassin and clamav together, it was very effective. Note, that I never used amavis, which most people are using this way. In my configuration besides of strict postfix rules, I piped everything first through spamassassin (with bogofilter and all the other good stuff), and then what was not rejected by spamassassin through clamav - directlly from spamassassin's output into clamav input - no amavis. This worked very well after a good learning phase. But I guess, you are doing this already. If so, just aplogize my noise. Happy hacking! Hans > Spam e-mails like these that contain a zip with a windows executable > can easily be blocked based on file extension using the foxhole rules > for clamav (http://sanesecurity.com/foxhole-databases/). And clamav > can probably also be used to automatically clean the bug archive of > such messages. > > > Kind regards, > > Jeroen Dekkers
Bug#842168: ITP: orthanc-wsi -- Whole-slide imaging support for Orthanc (digital pathology)
Package: wnpp Severity: wishlist Owner: Sebastien Jodogne * Package name: orthanc-wsi Upstream Author : Sebastien Jodogne * URL : http://www.orthanc-server.com/static.php?page=wsi * License : AGPL Programming Lang: C++ Description : Whole-slide imaging support for Orthanc (digital pathology) The Orthanc project is a lightweight, extensible Vendor Neutral Archive for medical imaging (i.e. a DICOM server). It now provides a reference implementation of DICOM for whole-slide imaging (digital pathology), following DICOM Supplement 145. This package should be maintained by the Debian Med team, as it already maintains all the Orthanc-related packages.
Re: "Dear Customer" spam in the BTS
At Wed, 26 Oct 2016 13:43:31 +0200, Tomas Pospisek wrote: > I've recently received "Dear Customer" spam on a bug of mine. I've > searched the BTS [1], and there are many, many, many of these spam > postings in the BTS, see f.ex. [2]. > > I think it doesn't make sense to press "this bug log contains spam" on > each of those pages. Better would be to go directly to the archive and > delete such posts directly from there. > > I know I have once tried to do that - I think with a bit of advice from > Don Armstrong but it never went anywhere. > > Has anyone tried to do such a thing yet (methodically clean the bug > archive of spam)? Where and how could I start such an effort? How would > I get read/write access to the BTS archive? Spam e-mails like these that contain a zip with a windows executable can easily be blocked based on file extension using the foxhole rules for clamav (http://sanesecurity.com/foxhole-databases/). And clamav can probably also be used to automatically clean the bug archive of such messages. Kind regards, Jeroen Dekkers
Re: "Dear Customer" spam in the BTS
On Wed, 26 Oct 2016, Tomas Pospisek wrote: > Has anyone tried to do such a thing yet (methodically clean the bug > archive of spam)? Where and how could I start such an effort? How > would I get read/write access to the BTS archive? We're always looking for more vict^Wvolunteers; Blars Blarson has been tirelessly dealing with the spam issue in the archives for quite some time, and he's really the expert in this area. Any developer who is interested in volunteering and/or helping can e-mail ow...@bugs.debian.org, and I promise to try to train people and get them set up. [And/or write additional tools to make things easier.] -- Don Armstrong https://www.donarmstrong.com unbeingdead isn't beingalive -- e.e. cummings "31" _73 Poems_
Re: "PIE by default" transition is underway -- wiki needs updating
On Wed, 26 Oct 2016, Adrian Bunk wrote: > On Wed, Oct 26, 2016 at 05:37:06AM +0200, Adam Borowski wrote: > > On Wed, Oct 26, 2016 at 12:37:18AM +0200, Andreas Cadhalpun wrote: > > > The current policy says: > > > "As to the static libraries, the common case is not to have relocatable > > > code" > > > > > > As of gcc-6 version 6.2.0-7 this is factually wrong, because the compiler > > > enables PIE by default, which means it produces relocatable code. > > > This should definitely be updated to reflect reality. > > > > It's not that simple. The compiler enables PIE by default only: > > * if you use "gcc" or "gcc-6". gcc-5, clang, even gcc-snapshot still > > default to non-PIE. > > The intention is that gcc-6 will be the only gcc version in stretch. It needs to be able to compile the kernel correctly, first. Which it might not be able to right now (gcc 6.2.0), if one goes by code generation issues reported in LKML (for other distros). Hopefully it will be fixed upstream by the time stretch is out, but it *is* a current concern. Also, the upstream kernel source needs to be fixed to deal with PIE enabled by default (it is highly allergic to that). This is already ongoing AFAIK. -- Henrique Holschuh
Re: "Dear Customer" spam in the BTS
On Wed, Oct 26, 2016 at 7:43 PM, Tomas Pospisek wrote: > Has anyone tried to do such a thing yet (methodically clean the bug > archive of spam)? Where and how could I start such an effort? How would > I get read/write access to the BTS archive? The BTS admins do that regularly, based on people clicking the report spam links at the bottom of the bug reports. I guess you would need to become a BTS admin to contribute to that effort. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#842162: ITP: anything-sync-daemon -- Anything-sync-daemon (asd) is a tiny pseudo-daemon designed to manage user specified directories referred to as sync targets from here on out, in tmpfs and to
Package: wnpp Severity: wishlist Owner: Jan Luca Naumann * Package name: anything-sync-daemon Version : 5.83 Upstream Author : graysky * URL : https://github.com/graysky2/anything-sync-daemon * License : Expat Programming Lang: Bash Description : Sync user specified directories into RAM Anything-sync-daemon (asd) is a tiny pseudo-daemon designed to manage user specified directories referred to as sync targets from here on out, in tmpfs and to periodically sync them back to the physical disc (HDD/SSD). This is accomplished via a symlinking step and an innovative use of rsync to maintain synchronization between a tmpfs copy and media-bound backups. Additionally, asd features several crash recovery features.
Re: "PIE by default" transition is underway -- wiki needs updating
On Wed, Oct 26, 2016 at 05:37:06AM +0200, Adam Borowski wrote:
> On Wed, Oct 26, 2016 at 12:37:18AM +0200, Andreas Cadhalpun wrote:
> > The current policy says:
> > "As to the static libraries, the common case is not to have relocatable
> > code"
> >
> > As of gcc-6 version 6.2.0-7 this is factually wrong, because the compiler
> > enables PIE by default, which means it produces relocatable code.
> > This should definitely be updated to reflect reality.
>
> It's not that simple. The compiler enables PIE by default only:
> * if you use "gcc" or "gcc-6". gcc-5, clang, even gcc-snapshot still
> default to non-PIE.
The intention is that gcc-6 will be the only gcc version in stretch.
> * on most first-class (release) architectures: amd64 arm64 armel armhf i386
> mips mipsel mips64el ppc64el s390x. This leaves out powerpc.
> * on none of second-class architectures: alpha hppa hurd-i386
> kfreebsd-{amd64,i386} m68k powerpcspe ppc64 sh4 sparc64 x32
> * on none of unofficial architectures
>
> Points 2-4 mean you need to bear with extra joy of supporting both variants
> on different archs.
As maintainer of an average package, it shouldn't make any difference
for you.
In these special cases where it does, you might often already pass
-fno-pie on all architectures now.
> So while indeed the current wording of the policy is wrong, the reality is
> currently... complicated.
>...
The "must not be compiled with the `-fPIC' flag" unless there is an
exceptional case is still true.
So only a slight update in the wording is required regarding PIE.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Re: "Dear Customer" spam in the BTS
On Wed, Oct 26, 2016 at 1:43 PM, Tomas Pospisek wrote: > Hello all, > > I've recently received "Dear Customer" spam on a bug of mine. I've > searched the BTS [1], and there are many, many, many of these spam > postings in the BTS, see f.ex. [2]. Annoying indeed. https://bugs.debian.org/628285 -M
"Dear Customer" spam in the BTS
Hello all, I've recently received "Dear Customer" spam on a bug of mine. I've searched the BTS [1], and there are many, many, many of these spam postings in the BTS, see f.ex. [2]. I think it doesn't make sense to press "this bug log contains spam" on each of those pages. Better would be to go directly to the archive and delete such posts directly from there. I know I have once tried to do that - I think with a bit of advice from Don Armstrong but it never went anywhere. Has anyone tried to do such a thing yet (methodically clean the bug archive of spam)? Where and how could I start such an effort? How would I get read/write access to the BTS archive? ? Thanks, *t [1] https://www.startpage.com/do/metasearch.pl?query=site%3Abugs.debian.org%20%22Dear%20Customer%22 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754505
Re: "PIE by default" transition is underway -- wiki needs updating
On Wed, 26 Oct 2016 at 05:37:06 +0200, Adam Borowski wrote: > On Wed, Oct 26, 2016 at 12:37:18AM +0200, Andreas Cadhalpun wrote: > > The current ffmpeg packages builds shared and static libraries > > What's your reason for building something as big and with as extensive > dependencies statically? Let's delegate static libraries to special needs > only, as limited as possible. Are you suggesting that the normal way in which libraries are packaged in Debian should change from "shared+static unless there is a good reason to prefer shared-only or static-only" to "shared-only unless there is a good reason to prefer shared+static or static-only"? (In Autotools packages, this would mean adding --disable-static to most configure invocations, and dropping the .a file from debian/libwhatever.install.) I don't think that's a bad idea, but it's certainly not the project's conventional practice right now (e.g. Policy §8.3 says the static library "is usually provided"); so it should probably be treated as a separate change to the distribution, related to but distinct from the switch to PIE-by-default. S
Re: When should we https our mirrors?
On Wed, Oct 26, 2016 at 08:38:33AM +0200, Philipp Kern wrote: > On 10/24/2016 09:19 AM, Tollef Fog Heen wrote: > > ]] Philipp Kern > >> It's also a little awkward that apt does not tell you which of the SRV > >> records it picked. (The "and why" is clear: round robin.) I had a short > >> read earlier today and I had no idea how to even report it without that > >> information. (Of course I know how to turn on debugging but then it > >> picked a different one and succeeded.) > > > > Even getting the SRV record won't help much, you want to know what IP it > > resolved to and what headers you got from the backend to uniquely > > identify problems with a single POP or machine in a POP. > > Fair enough. I never saw the current hash sum mismatch output before. I > suppose it'd be helpful if apt could print more details about the > machine it fetched it from in there -- if it still has the information, > which is probably the more tricky part given pluggable transports. It is tricky, but in the end a transport can send arbitrary deb822 fields up to the apt process and apt can do whatever with them, so it should be doable if we know what we have to send up the chain: SRV hostname + IP we ended up connection to, okay, but what else? I had a look at the HTTP responses we get from both CDNs, but while there are perhaps a few interesting fields there, they are different per CDN… Answer for: http://deb.debian.org/debian/dists/sid/Release.gpg | HTTP/1.1 200 OK | Server: Apache | Last-Modified: Wed, 26 Oct 2016 03:30:41 GMT | ETag: "612-53fbc3fde0a18" | X-Clacks-Overhead: GNU Terry Pratchett | Cache-Control: public, max-age=120 | Via: 1.1 varnish | Fastly-Debug-Digest: b6ea737814cc1feed0f9205c8ee1338025c8d316c1029a16c6f4365c6a7c6cdd | Content-Length: 1554 | Accept-Ranges: bytes | Date: Wed, 26 Oct 2016 08:58:06 GMT | Via: 1.1 varnish | Age: 0 | Connection: keep-alive | X-Served-By: cache-ams4141-AMS, cache-fra1222-FRA | X-Cache: MISS, MISS | X-Cache-Hits: 0, 0 | X-Timer: S1477471085.983025,VS0,VE27 Answer for: http://deb.debian.org/debian/dists/sid/Release.gpg | HTTP/1.1 200 OK | Content-Length: 1554 | Connection: keep-alive | Date: Wed, 26 Oct 2016 08:59:15 GMT | Server: Apache | Last-Modified: Wed, 26 Oct 2016 03:30:41 GMT | ETag: "612-53fbc3fde0a18" | Accept-Ranges: bytes | X-Clacks-Overhead: GNU Terry Pratchett | Cache-Control: public, max-age=120 | X-Cache: Miss from cloudfront | Via: 1.1 b74a7a3f7ddfd685212e870d027c332d.cloudfront.net (CloudFront) | X-Amz-Cf-Id: OWWfvAJ_et1_QVyPiP07-bodyCenkWtGTz8OeRW041eyeRDuvmGgCA== I would kinda like to avoid encoding the entire answer and sending that in for display because it would be a lot of noise (and bugreporters will truncate it if it is too long trying to be helpful), so if people who actually know what they would need to deal with issues (I don't) would decide upon a set and report a bug against apt to implement it, we will see what we can do. Best regards David Kalnischkies P.S.: Fastlys Via response header seems to be important, given that it is sent twice, but apart from that… signature.asc Description: PGP signature
Re: Keysafe dynamic UID
On Wed, 26 Oct 2016 at 05:37:12 +0200, Guillem Jover wrote: > openarena Debian-openarena For what it's worth, if I was confident that renaming the user wouldn't be more disruptive than continuing to use the vendor-specific username, I'd be happy to call this one _openarena or something; but this stuff seems to always more subtle than first expected (see also #679642, and the lack of consensus on #621833 on how best to achieve system users being locked during package removal and unlocked during reinstallation) so I have erred on the side of leaving it as-is to minimize breakage. If there is now a best-practice way to rename system users (and consensus on which configurations are or aren't supported), I'm happy to follow it. S
Bug#842140: ITP: obs-signd -- open build service signer client and daemon
Package: wnpp Severity: wishlist Owner: "Andrew Lee (李健秋)" * Package name: obs-signd Version : 2.3.0 Upstream Author : Michael Schröder * URL : https://github.com/openSUSE/obs-sign * License : GPL-2+ Programming Lang: C Description : open build service signer client and daemon This daemon can be used to sign anything via gpg, but it speaks with a remote server to avoid the need to host the private key on the same server.
Re: Keysafe dynamic UID
On Wed, 26 Oct 2016 at 09:37:52 +0300, Dmitry Bogatov wrote: > > Minimizing the amount of logic in the > > actual maintainer script (ideally reduced to just running one helper > > tool with appropriate arguments), and adding a dependency on the > > helper tool that has the actual logic, would mitigate this: perhaps > > that tool could live in the adduser package? > > Problem: you can't have asume any tool in post-rm script. If you aren't doing the delete-on-purge thing any more, but instead locking the account, does it need to happen in postrm? If you lock the account in prerm and take no further action in postrm, you can rely on your package's Depends being satisfied during prerm (strictly speaking they are only guaranteed to be unpacked, but I suspect that's good enough for adduser). S
Bug#842139: ITP: node-xtend -- extend like a boss
Package: wnpp Severity: wishlist Owner: Sarath M S X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-xtend Version : 4.0.1 Upstream Author : Raynos * URL : https://github.com/Raynos/xtend * License : Expat Programming Lang: JavaScript Description : extend like a boss xtend is a basic utility library which allows you to extend an object by appending all of the properties from each object in a list. When there are identical properties, the right-most property takes precedence. . Node.js is an event-based server-side JavaScript engine.
Bug#842131: ITP: node-error-ex -- Easy error subclassing and stack customization
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-error-ex Version : 1.3.0 Upstream Author : JD Ballard * URL : https://github.com/qix-/node-error-ex#readme * License : Expat Programming Lang: JavaScript Description : Easy error subclassing and stack customization signature.asc Description: OpenPGP digital signature
