On 6/17/23 12:29, Timo Röhling wrote:
Being backwards compatible is CMake's greatest blessing and greatest
curse at the same time, because people still run into crappy,
20 year old tutorials and needlessly complicated (but working) code
snippets from CMake 2.x on the Internet, making them believ
On 8/20/21 2:37 PM, Simon Richter wrote:
This is a use case where HTTPS does hurt, and where I can't think of
any good mitigation strategies that wouldn't be worse from a security
PoV than the status quo.
Such situations are the exception rather than the norm. If https is
detrimental to the
On 8/20/21 10:56 AM, Russ Allbery wrote:
Do you think using HTTPS makes security worse?
No idea whether I qualify as a "security expert" but as someone who has
spent a fair amount of time working in security, my concern is making
advice simple enough for people to follow. Complicated, condition
On 8/19/21 3:46 PM, Simon Richter wrote:
For the most part, users would configure https if they are behind a
corporate firewall that disallows http, or modifies data in-flight so
signature verification fails, everyone else is better off using plain
http.
Or they might configure https on the s
On 8/12/21 2:32 AM, Vincent Bernat wrote:
❦ 12 August 2021 10:39 +05, Andrey Rahmatullin:
I just ran across this article
https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
the attacks on Debian 11 and they work successfully giving me a root
shell prompt.
I don't think cal
On 8/11/21 7:34 AM, Horler, Johannes wrote:
Dear Debian Team,
hopefully I am writing this to the right email address. (In case I am
not, I would be happy about being refered.) Recently I got interested
in operating systems. Now I want to try to experiment with modifying one.
Is the complet
On 7/1/21 2:45 PM, Jeremy Stanley wrote:
Check out the sources.list manpage:
"The files list one source per line (one-line style) or contain
multiline stanzas defining one or more sources per stanza
(deb822 style), ..."
And then there's an entire DEB822-STYLE FORMAT section which
On 7/1/21 2:19 PM, Jeremy Stanley wrote:
Also, as other's have stated, deb822 might be a cleaner way to
express this.
I'm a little confused - I thought deb822 was just a generic format used
in various places throughout Debian, including in the Release files.
Where specifically would the signe
On 7/1/21 10:40 AM, Jeremy Stanley wrote:
Yes, that's a community-maintained wiki article with a few editors
(at least most of whom are also DDs in this case), started in
2017-03-22 to describe a specific model which discourages it, but
nowhere does that claim use of /etc/apt/trusted.gpg.d is off
On 7/1/21 9:27 AM, Jeremy Stanley wrote:
It's not clear (to me at least) that placing keys into
/etc/apt/trusted.gpg.d is deprecated
According to https://wiki.debian.org/DebianRepository/UseThirdParty it is:
> The key MUST NOT be placed in /etc/apt/trusted.gpg.d or loaded by
apt-key add.
T
On 7/1/21 8:27 AM, Julian Andres Klode wrote:
I don't want to advertise signed-by=. We should aim to get deb822 format
supported in python-apt next cycle, and then advertise a consistent use
of deb822 .sources files.
Including, but not limited to, having d-i create
sources.list.d/.sources instea
On 10/30/20 8:29 AM, Domenico Andreoli wrote:
First things first, we need to have many copies of that and make it
available it all over the net.
Do you have a complete git repo that can be cloned?
This one is still online at the time of writing:
https://github.com/youtube-dl2/youtube-dl
Kyle
On Thu, 2020-06-25 at 22:19 +0200, Emmanuel Bourg wrote:
> I'm not sure to understand what bothers you. In this case the final
> version will be nearly identical. The JakartaEE APIs consist
> basically
> in the JavaEE versions that have been stable and in use for years
> with
> the base package ren
On Tue, 2020-05-19 at 14:25 +, Kseniya Fedoruk wrote:
> Hi team,
>
> I'm Kseniya from ONLYOFFICE. We are developing open-source office
> applications, including the absolutely free ONLYOFFICE Desktop
> Editors that provide alternatives to MS Office Word, Excel, and
> PowerPoint distributed und
Hi Alastair,
On Tue, 2020-05-12 at 10:47 +0100, Alastair McKinstry wrote:
> Dear Kyle,
>
> I'm willing to sponsor this.
Thank you very much for the sponsorship offer - I gladly accept! :)
So what's next? I am new to Debian development, and this is my first
time submitting a package.
> It overl
Forwarded Message
From: Kyle Edwards
Reply-to: Kyle Edwards ,
959...@bugs.debian.org
To: Debian Bug Tracking System
Subject: Bug#959057: RFS: dh-cmake/0.4 [ITP] -- Debhelper programs for
CMake projects
Date: Tue, 28 Apr 2020 20:54:33 +
> Package: sponsorship-reque
On Wed, 2020-04-29 at 10:21 +0100, Alastair McKinstry wrote:
> I think vendoring libraries that are only used by this package is
> fine.
>
> I would however put them in a "public" place and namespace (eg
> /usr/lib/$ARCH/libatl.* ) rather than a subdir or namespace
> ('libatl-adios') so that ther
On Sat, 2020-04-25 at 20:31 +0200, Thomas Goirand wrote:
> I'd say that it depends, and that it should be addressed on the
> case-by-case basis.
I do have another scenario I'd like to address. ADIOS uses a stack of
closely related but separate projects, all developed by Greg
Eisenhauer, which, as
On Sat, 2020-04-25 at 20:31 +0200, Thomas Goirand wrote:
> If the library you need to package isn't needed by any other package,
> simply apply the needed patch and upload. Even better if it's only a
> build-dependency, in which case it wont ever be a problem.
This brings up an interesting questio
On Sat, 2020-04-25 at 00:02 +0200, Mattia Rizzolo wrote:
> If the upstream maintainer of that library is not available anymore
> and
> the project is clearly dormient, perhaps you can take over
> officially?
> Or if that patch is "acceptable" just leave it on the bug tracker,
> and
> within debian
Hello,
I have a question about how Debian handles modifications to third-party
dependencies. Sometimes a project relies on another project, but has
made modifications to that project that never went into upstream,
either because upstream has abandoned the project or because the
changes are not ap
On Wed, 2020-04-15 at 16:05 +0300, Constantine Ryzhikov wrote:
> Hello.
> Today, my main programming language is Python. I have worked with
> other
> programming languages.
> I'd like to become a stronger developer, and be able to write
> performance code.
> I'm interested in developing applicati
On Thu, 2020-03-26 at 19:57 +0100, Andrej Shadura wrote:
> An example: commercial users. They need to know *exactly* what they
> are running and under which licenses. They often want to be holier
> not
> only than the Pope, but holier than the whole population of Poland,
> Italy and Spanish-speakin
On Fri, 2020-03-06 at 20:38 +0700, Bagas Sanjaya wrote:
> 1. The script builds OLS using specific version of CMake (3.14.5) and
> Go
> (1.6), though it did mention installing cmake as build dependency
> from
> apt. The script downloads both build tools and install them to
> `/usr/local` (which D
On Fri, 2019-10-04 at 12:27 -0600, Daniele Nicolodi wrote:
> For those not following closely, can you please point to the reasons
> why
> bazel (cannot?) is (yet?) packaged for Debian? I recently pumped
> into
> another software that proposes to use bazel as its build system, thus
> I
> would like
On Tue, 2019-08-06 at 21:05 +0200, Jonas Smedegaard wrote:
> Quoting Holger Wansing (2019-08-06 20:30:56)
> >
> > [Adding debian-devel for a bigger audience]
> >
> >
> > Hi,
> >
> > Holger Wansing wrote:
> > >
> > > Control: retitle -1 Replace grave accents/single quotes by
> > > in gpl.xml
On Thu, 2019-07-25 at 09:45 -0700, Russ Allbery wrote:
> Tobias Frost writes:
>
> >
> > I think there is another option, as embedding lua is a bad idea for
> > the
> > reason you have already quoted: There are currently two (three with
> > experimental) lua versions available in Debian, so you s
Hi all,
As per Debian policy, programs and libraries are generally not allowed
to embed their own copies of libraries that are present in another
package, in order to avoid duplication of code and to enable security
updates by updating shared libraries. In general, this is a good rule,
but I'm won
On Tue, 2019-07-16 at 10:22 +, Javeed Ahmed wrote:
> sir/madam
> can i make my own os using debian as a base and distribute it?
Absolutely! Debian is free software, and you are free to use, modify,
and distribute it for any purpose. Please make sure to follow the rules
of each package's licen
On Thu, 2019-07-11 at 23:25 +0800, Yao Wei wrote:
> Hi,
>
> Following to Mo Zhou's thread of Conda and Debian, it reminds me
> that,
> could Debian reduced into a "proof of concept" as an operating system
> with collection of apps and things composed of completely free
> software,
> as more and mo
On Mon, 2019-06-10 at 16:56 +, Jeremy Stanley wrote:
> 2. Don't place all your trust key revocation, instead plan a
> rotation schedule so that even if a key falls into the wrong hands
> it's more likely users will smell something fishy when they see it
> used to sign new artifacts after expira
On Sat, 2019-06-08 at 02:25 +0200, Matthias Klumpp wrote:
> Am Do., 6. Juni 2019 um 20:33 Uhr schrieb Kyle Edwards
> :
> >
> >
> > Hello all,
> >
> > I have been preparing Ubuntu releases for CMake on our own APT
> > repository for several mo
Hello all,
I have been preparing Ubuntu releases for CMake on our own APT
repository for several months now. We did this by preparing our own
repository infrastructure - we have a machine that builds packages, and
a machine that hosts an Aptly instance and pushes the repository to our
web server.
On Mon, 2019-04-08 at 16:05 +, PICCA Frederic-Emmanuel wrote:
> now we have the salsa pipeline.
>
> does it fit your needs ?
Does this allow non-DD's to host packages? Nobody at Kitware is a DD,
we just host an unofficial third-party repository, similar to PPA.
Kyle
On Mon, 2019-04-08 at 00:02 -0400, Peter Silva wrote:
> > If one needs to keep a close eye on changes to make sure they can
> > still
> > be installed even on a years-old OS, the resulting packages can be
> > placed in a custom repository set up with the instructions at
> > https://wiki.debian.org/
On Wed, 2018-07-11 at 08:57 -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> But no, my real fear here was a tool more in the cpack kind. Years
> ago we had packagers trying to get their stuff in by using cpack.
> While it might be of some help for non official packages it was not
> really fit f
On Tue, 2018-07-10 at 12:52 -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> Well, there are cases when upstream is doing things the right way
> with respect to Debian but... what about derivatives (distributions
> which base themselves in Debian)? Sometimes they need something
> different, and
On Fri, 2018-07-06 at 21:00 +0100, Colin Watson wrote:
> If the libraries in question are DFSG-free themselves, there's no
> DFSG issue and you don't need to remove them from the tarball (and
> we'd generally encourage not modifying the upstream tarball
> unnecessarily for upload to Debian). The p
On Thu, 2018-07-05 at 14:04 -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> From what you write above I tend to think that simply by not using
> dh-cmake whatever upstream has defined as packaging it will be simply
> ignored (ie, it will become a "standard" CMake project).
Yes, this is true. d
So, to clarify: we've changed VTK to use GNUInstallDirs, which *itself*
sets the proper directories for Debian, as I will explain below.
On Thu, 2018-07-05 at 15:38 +0100, Simon McVittie wrote:
> debhelper's Debian::Debhelper::BuildSystem::cmake already passes
> -DCMAKE_INSTALL_LIBDIR=lib/$DEB_HOS
On Wed, 2018-07-04 at 11:30 +0200, Andreas Tille wrote:
> I think you can solve the lintian warning
> W: dh-cmake source: ancient-python-version-field x-python3-version
> 3.2
> by simply removing
> X-Python3-Version: >= 3.2
> from d/control.
Thanks for the tip, we will fix this in the next rel
Hi Lisandro,
Thank you for expressing your concerns. You bring up some very valid
points, and I will try to address all of them here.
On Wed, 2018-07-04 at 14:40 -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> I even use it for 99% of my personal/job projects!
Glad to hear it!
> If upstream
Hello everyone!
My name is Kyle. I work at Kitware, Inc., the upstream maintainer of
the CMake buildsystem (https://www.cmake.org/) and VTK, the
Visualization Toolkit (https://www.vtk.org/). As some of you on the
Debian Science list may have heard, we are making an effort to
officially support our
43 matches
Mail list logo
