Package: wnpp
Severity: wishlist
Owner: Michael Lustfield
* Package name: libjs-semantic
Version : 2.2.13
Upstream Author : semantic-ui.com
* URL : https://github.com/Semantic-Org/Semantic-UI
* License : Expat
Programming Lang: Javascript
Description :
Package: wnpp
Severity: wishlist
Owner: Michael Lustfield
* Package name: libjs-swaggerui
Version : 3.1.4
Upstream Author : 2017 SmartBear Software
* URL : https://github.com/swagger-api/swagger-ui
* License : Apache-2.0
Programming Lang: Javascript
Descrip
Package: wnpp
Severity: wishlist
Owner: Michael Lustfield
* Package name: libjs-vue
Version : 2.4.2
Upstream Author : 2013-2017 Yuxi (Evan) You
* URL : https://github.com/vuejs/vue
* License : Expat
Programming Lang: Javascript
Description : JS library
Package: wnpp
Severity: wishlist
Owner: Michael Lustfield
* Package name: libjs-pdfjs
Version : 1.8.188
Upstream Author : 2012 Mozilla Foundation
* URL : https://github.com/mozilla/pdf.js
* License : Apache-2.0
Programming Lang: Javascript
Description :
Package: wnpp
Severity: wishlist
Owner: Michael Lustfield
* Package name: libjs-cssrelpreload
Version : 1.3.1
Upstream Author : 2016 Filament Group
* URL : https://github.com/filamentgroup/loadCSS
* License : Expat
Programming Lang: Javascript
Description
Package: wnpp
Severity: wishlist
Owner: Michael Lustfield
* Package name: libjs-jquery-minicolor
Version : 2.2.6
Upstream Author : 2017 A Beautiful Site, LLC
* URL : https://github.com/claviska/jquery-minicolors
* License : Expat
Programming Lang: Javascript
Package: wnpp
Severity: wishlist
Owner: Anthony Fok
* Package name: golang-github-markbates-inflect
Version : go.r60+git20170411.16.6cacb66-1
Upstream Author : Mark Bates, Chris Farmiloe, David Heinemeier Hansson
* URL : https://github.com/markbates/inflect
* License
On 2017-08-07 20:12, James McCoy wrote:
> On Mon, Aug 07, 2017 at 03:11:18PM -0400, Ralph Amissah wrote:
> > I believe this is the reason I am currently unable to backup my
> > gmail account with isync/ mbsync
>
> That's because isync defaults to TLSv1 unless you tell it to do
> otherwise.
>
> ht
Package: wnpp
Severity: wishlist
Owner: Anthony Fok
* Package name: golang-github-jdkato-syllables
Version : 0.1.0+git20170409.10.8961fa0-1
Upstream Authors: Joseph Kato, mtso, Titus Wormer
* URL : https://github.com/jdkato/syllables
* License : Expat
Program
On Sat, Aug 05, 2017 at 10:28:36PM +0200, Adam Borowski wrote:
> It's easy to quite reliably detect the presence of such instructions
> (probably no one JITs such code). There's no real way to check if it's
> executed unconditionally, though -- a lot of software has optimized code
> paths that are
Jonathan Carter writes:
> I get the following:
> […]
>
> I looked for tofu but there only seems to be a python-tofu package and
> not a python3-tofu package, something I'm missing?
Thanks. Please report it as a bug in the Debian BTS.
--
\ “We can't depend for the long run on disti
On Mon, Aug 07, 2017 at 03:11:18PM -0400, Ralph Amissah wrote:
> I believe this is the reason I am currently unable to backup my
> gmail account with isync/ mbsync
That's because isync defaults to TLSv1 unless you tell it to do
otherwise.
https://sources.debian.net/src/isync/1.2.1-2/src/drv_imap.
Hi Ben
On 06/08/2017 20:34, Ben Finney wrote:
> Please try your strange uploads, and anything else you use ‘dput(1)’ and
> ‘dcut(1)’ for, with varying configurations. If there are any regressions
> I want you to report them in the Debian BTS, so they can be investigated
> before a wider release.
>
On Mon, Aug 7, 2017 at 2:59 PM, Colin Tuckley wrote:
> On Mon, Aug 7, 2017 at 2:38 PM, Kurt Roeckx wrote:
>
>> If I upload things to experimental and ask people to test it,
>> I will get no feedback at all.
>
> None the less, that is the correct thing to do.
>
> After an upload to unstable the fi
On 07/08/17 19:38, Kurt Roeckx wrote:
> If I upload things to experimental and ask people to test it,
> I will get no feedback at all.
None the less, that is the correct thing to do.
After an upload to unstable the first thing that will happen is that
every DD will file an RC bug against it to s
On Aug 07, Joerg Jaspert wrote:
> Thats nice for any environment where on can freely define that
> everything works like this.
>
> Unfortunately real world doesnt work like it.
I think that I live in a real enough world (commercial web hosting), and
my customers have been asking for a while to
On Mon, Aug 07, 2017 at 05:53:07PM +0200, Michael Meskes wrote:
> > > This will likely break certain things that for whatever reason
> > > still don't support TLS 1.2. I strongly suggest that if it's not
> > > supported that you add support for it, or get the other side to
> > > add support for it.
On Mon, Aug 07, 2017 at 05:22:51PM +0200, Joerg Jaspert wrote:
> I wonder if there is a middle way that ensures that all new stuff does
> go TLS1.2 (or later, whenever), but does allow older stuff still to
> work. Which isnt the case if they are just disabled.
I could change the default settings t
On Aug 7, 2017 8:23 AM, "Joerg Jaspert" wrote:
On 14757 March 1977, Kurt Roeckx wrote:
> This will likely break certain things that for whatever reason
> still don't support TLS 1.2. I strongly suggest that if it's not
> supported that you add support for it, or get the other side to
> add suppo
On Mon, Aug 7, 2017 at 8:30 AM, Antonio SJ Musumeci wrote:
> My users span several generations of Debian (and other) Linux distributions.
> Early 2.9.X versions of libfuse had bugs which led to "random" crashes.
> These versions are still in wide use (I get 2.8.x users on occasion too).
> Over pas
> > This will likely break certain things that for whatever reason
> > still don't support TLS 1.2. I strongly suggest that if it's not
> > supported that you add support for it, or get the other side to
> > add support for it.
>
> In many cases this isnt possible.
Wouldn't it make sense to start
On Mon, Aug 07, 2017 at 09:59:20AM +0200, Leon Klingele wrote:
> Does this also apply for libssl?
This applies to libssl1.1 package and everything making use of it.
Kurt
On 14757 March 1977, Kurt Roeckx wrote:
> I've just uploaded a version of OpenSSL to unstable that disables
> the TLS 1.0 and 1.1 protocol. This currently leaves TLS 1.2 as the
> only supported SSL/TLS protocol version.
Thats nice for any environment where on can freely define that
everything wor
On Aug 07 2017, Antonio SJ Musumeci wrote:
[libfuse]
> There are secondary issues related to v2 being no longer maintained
What makes you think so? I'm not adding new features, but it's
definitely still being maintained.
Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FC
Package: wnpp
Severity: wishlist
Owner: Lucas Nussbaum
* Package name: vmtouch
Version : 1.3.0
Upstream Author : Doug Hoyte
* URL : https://hoytech.com/vmtouch/
* License : BSD-3-clause
Programming Lang: C
Description : Portable file system cache diagn
On Sat, Aug 05, 2017 at 04:29:34PM -0700, Russ Allbery wrote:
>...
> since teams are less likely to only have a single leaf package.
Approximate data based on grep'ing Packages[1]:
- 466 teams maintaining packages in unstable
- 8 is the median number of packages maintained by a team
- 73 teams mai
On Sun, Aug 6, 2017 at 12:14 PM, Stefan Fritsch wrote:
> Is there some tool that parses /proc/maps and the build-ids fields from
> the apt repository to determine which dbgsym packages to install?
Not AFAIK but I guess that Fedora probably has a script for this somewhere.
The service to map buil
I have Ubuntu running on another box. I haven't had any trouble (to my
knowledge) that has been caused from apparmor. Ubuntu being perceived as an
entry OS for linux, I would think Canonical wouldn't have included it if it
would introduce pain to desktop users. What sort of "pain" might apparmor
I'm not sure that Ritesh did a good job of explaining why I've embedded
libfuse2 into mergerfs.
My users span several generations of Debian (and other) Linux
distributions. Early 2.9.X versions of libfuse had bugs which led to
"random" crashes. These versions are still in wide use (I get 2.8.x use
On Mon, Aug 7, 2017 at 9:08 AM, Ritesh Raj Sarraf wrote:
> But for desktop users, I worry this would cause more pain.
My point is that it hasn't so far and Ubuntu and SUSE has had millions
of people using it for a decade, more or less.
Thanks,
Jeremy Bicha
Hello Jeremy,
On Mon, 2017-08-07 at 08:47 -0400, Jeremy Bicha wrote:
> While there are plenty of people who recommend disabling SELinux by
> default on Fedora/RHEL (at least in the past), it's far, far less
> common to hear about anyone recommending disabling AppArmor. And
> that's one reason AppA
Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant
* Package name: spyder-notebook
Version : 0.1.0
Upstream Author : Spyder Development Team
* URL : https://github.com/spyder-ide/spyder-notebook
* License : Expat
Programming Lang: Python
Descr
On Mon, Aug 7, 2017 at 8:28 AM, Ritesh Raj Sarraf wrote:
> On most systems, people tend to disable LSM first. Because many a times
> an inadequate policy hinders the use of the tool. And on the desktop
> machine this becomes more common an issue.
While there are plenty of people who recommend dis
On Fri, 2017-08-04 at 19:31 -0400, intrigeri wrote:
> tl;dr: I hereby propose we enable AppArmor by default in testing/sid,
> and decide one year later if we want to keep it this way in the
> Buster release.
On most systems, people tend to disable LSM first. Because many a times
an inadequate poli
On 2017-08-07 09:59:20 [+0200], Leon Klingele wrote:
> Does this also apply for libssl?
Yes, libssl1.1 and all its users to be exact. libssl1.0 does not have
this change but we plan to have it removed for Buster.
Sebastian
On 08/07/2017 12:15 PM, Adrian Bunk wrote:
> Packages that genuinely cannot work on the architecture baseline are
> very rare, these are a tiny part of the packages that are not binary-any.
In general I agree with you that we should not allow too much
fragmentation. I suppose at the point where we
On Mon, 2017-08-07 at 10:32 +0200, Nikolaus Rath wrote:
> On Aug 07 2017, Ben Finney wrote:
> > By your description, the upstream code doesn't do that. One obvious
> > workaround is to remove the embedded library in the Debian
> > ‘mergerfs’
> > package ‘clean’ target, patch the software to instea
On Mon, 2017-08-07 at 16:43 +1000, Ben Finney wrote:
> > Any advise on what should be our take further ?
>
> You have correctly identified that the embedded library should not be
> used in Debian, and instead the Debian ‘mergerfs’ package should use
> only the first-class Debian ‘libfuse’ package.
On Sat, Aug 05, 2017 at 07:53:02PM +0200, Adam Borowski wrote:
>...
> Dropping baseline support is giving up, but let's at least surrender nicely.
>
> Thus, here's a proposed solution: in unstable, there's now a bunch of
> packages that do such checking in preinst, and thus refuse (overridably) to
Christian Seiler schrieb:
> Another thing to consider: if a profile is too restrictive, but the
> part that is too restrictive isn't in the upstream kernel yet, then
> things could break if you upgrade the kernel to a newer version from
> e.g. backports later on. How would you deal with that kind
On Aug 07 2017, Ben Finney wrote:
> By your description, the upstream code doesn't do that. One obvious
> workaround is to remove the embedded library in the Debian ‘mergerfs’
> package ‘clean’ target, patch the software to instead use Debian's
> packaged ‘libfuse’ library, and maintain that patch
Does this also apply for libssl?
> Am 07.08.2017 um 03:42 schrieb Kurt Roeckx :
>
> Hi,
>
> I've just uploaded a version of OpenSSL to unstable that disables
> the TLS 1.0 and 1.1 protocol. This currently leaves TLS 1.2 as the
> only supported SSL/TLS protocol version.
>
> This will likely brea
42 matches
Mail list logo
