On Thu, 05 Oct 2017 at 21:43:20 +0200, Tollef Fog Heen wrote:
> However, if you just do the IMO more common sudo $command, you get a lot
> more:
>
> $ sudo env | wc -l
> 87
Is that under default configuration? My /etc/sudoers{,.d/*} don't mention
env_reset, and "sudo env" clears most of the envir
On Thu, 05 Oct 2017 at 20:10:02 +0200, Sven Joachim wrote:
> On 2017-10-05 09:09 +0100, Simon McVittie wrote:
> > Unfortunately, dpkg's cputable doesn't seem to
> > have a column for "what is a normal uname -m on this architecture?",
>
> The closes
On Thu, 05 Oct 2017 at 20:10:02 +0200, Sven Joachim wrote:
> On 2017-10-05 09:09 +0100, Simon McVittie wrote:
> > It's also common
> > to identify architecture by uname -m in ad-hoc project-specific build
> > systems
>
> Using uname -m seems to be wr
On Thu, 05 Oct 2017 at 03:52:56 +0200, Adam Borowski wrote:
> The package in question, lepton, is a tool to losslessly recompress JPEG
> files. It does so faster if your CPU is equipped with SSE4.1, thus the
> upstream build system hard-codes this requirement, even though it seems
> that generic c
On Thu, 05 Oct 2017 at 11:01:42 +0800, Paul Wise wrote:
> Anything that generates different code depending on the instructions
> supported by the build CPU is going to break reproducible builds. So
> whatever mechanism is used, it needs to be deterministic. [...]
> I'd like to see CMAKE_SYSTEM_PROC
On Wed, 04 Oct 2017 at 12:43:59 +0100, Chris Lamb wrote:
> Any which we do not ship compiled files cannot be affected (eg. we do not
> ship Python's .pyc files; they are generated at installation-time)
This is not generally the case for distros other than Debian, so is
worth being aware of for Pyt
On Wed, 04 Oct 2017 at 17:05:03 +0530, Pirate Praveen wrote:
> As these packages are always uploaded as binary included and never built
> on the buildd (as buildds already prohibit network access during build).
As far as I'm aware, they currently don't. Policy says it would be valid
if they did, a
On Tue, 03 Oct 2017 at 12:12:54 +0530, Pirate Praveen wrote:
> I cannot accept arbitrary interpretations of policy. When build tools
> are not available in main, they cannot go to main, and if the software
> itself is Free Software, it can go to contrib. If you disagree, please
> get the policy cla
On Fri, 01 Sep 2017 at 09:40:25 +, Holger Levsen wrote:
> On Fri, Sep 01, 2017 at 09:26:44AM +0300, Adrian Bunk wrote:
> > AFAIK the only place where we currently still need binary packages that
> > have been built on a maintainer machine is for [...]
>
> the fun part is that once a package
Package: wnpp
Severity: wishlist
Owner: Simon McVittie
* Package name: flatpak-builder
Version : 0.9.8+$n_commits (until a release is made)
Upstream Author : Alexander Larsson and others
* URL : https://github.com/flatpak/flatpak-builder
* License : LGPL
On Thu, 10 Aug 2017 at 12:00:15 -0700, John Johansen wrote:
> but ideally would be enabled by the dbus code advising the
> kernel module it is mediating
"The" dbus code? There can be several parallel instances of dbus-daemon,
possibly different versions of the executable, certainly differently
On Wed, 09 Aug 2017 at 17:17:17 -0700, John Johansen wrote:
> The dbus code went through several revisions as well. While the dbus
> code doesn't require a lot from the kernel, it did have some influence
> on the kernel support interfaces.
I'm curious: is the kernel side of D-Bus mediation specifi
On Sat, 05 Aug 2017 at 09:03:12 -0500, Steve Robbins wrote:
> The news bit refers to "test corpus", so removal would presumably not change
> the output. But I have to wonder: are there not cases where the malware is
> present for *training* a detection system? If so, I would imagine removal
>
On Sat, 05 Aug 2017 at 06:50:00 +, Niels Thykier wrote:
> Can we integrate these LSM policies into our testing frameworks (e.g.
> autopkgtests), so we can start having automated tests of even basic
> functionality. Or will that happen "out of the box" if we enable it by
> default (and, possibl
On Fri, 04 Aug 2017 at 12:10:03 +0200, Ansgar Burchardt wrote:
> So I have been wondering several times whether we should move the
> maintainer information elsewhere. For example, tracker.d.o could be
> extended to record maintainer information. It could also understand
> the concept of "teams" l
On Sun, 30 Jul 2017 at 19:34:42 +0900, Benda Xu wrote:
> As far as I can see, the easiest relocations are those modifiable in a
> plain text, like configuration file, script shebang, etc. The medium
> ones are ELF, with which we have tools like patchelf and chrpath, etc.
> The most difficult part
On Sat, 22 Jul 2017 at 12:28:04 +0200, Steffen Möller wrote:
> And quite some packages in our
> distribution do not really need to be installed as root if they were
> installed where the user has write permissions. There would hence be
> little overhead over what we have now. Should we not somehow
On Tue, 11 Jul 2017 at 13:45:25 +0200, Bjørn Mork wrote:
> I got to ask: Why? We do not have stable names for e.g. disks. Why do
> we need it for network devices?
We do have stable names for disks: look in /dev/disk/by-* and you'll see
a bewildering variety of ways to refer to the same disk or p
On Sat, 24 Jun 2017 at 16:04:32 +0200, Michael Biebl wrote:
> Am 24.06.2017 um 15:09 schrieb Michael Gilbert:
> > I entirely lost interest in the problem it was trying to solve when
> > the init system "debate" concluded. It should be removed.
>
> FYI, I've filed #865752 for that.
That doesn't s
On Sun, 12 Mar 2017 at 17:36:30 +, Simon McVittie wrote:
> Most packages in Debian that run autoreconf currently build-depend
> directly or indirectly on automake (version 1.14.1 in jessie, released
> 2013; version 1.15 in stretch/sid, released in 2015). However, 58
> packages
On Wed, 07 Jun 2017 at 10:36:17 +0200, Wouter Verhelst wrote:
> On Tue, Jun 06, 2017 at 03:55:48PM +0200, Adam Borowski wrote:
> > freedoom | game-data-packager: prboom-plus
> > * DEBATABLE: freedoom is too ugly to live, shareware Doom has assets missing
> > for running pretty much anything Doom-
On Tue, 06 Jun 2017 at 09:06:46 -0700, Russ Allbery wrote:
> Adam Borowski writes:
> > More seriously, though, let's go through the list of 94 unsatisfied ones
> > on my desktop; the list below is transposed to collate recommendees.
>
> And what happens here is, I think, typical: any one person o
On Thu, 01 Jun 2017 at 07:43:49 +, Anthony DeRobertis wrote:
> On May 31, 2017 3:51:33 AM EDT, Simon McVittie wrote:
> >dracut defaults to creating a general-purpose initramfs that is not
> >meant
> >to hard-code anything and can be used to boot "most" hardwar
On Wed, 31 May 2017 at 11:32:29 +1200, Ben Caradoc-Davies wrote:
> Trust is not transitive. Perhaps Recommends should not be either?
Recommends are for the relationship "wanting foo but not bar is unusual".
If A Recommends B and B Recommends C, and if we assume for example
that "unusual" means 10%
On Wed, 31 May 2017 at 00:20:18 +, Anthony DeRobertis wrote:
> AFAIK, mdadm's default (and maybe only supported, without some custom
> scripting) way to report a degraded array is email.
Can't it report this via the system log? (syslog, systemd-journald)
> OTOH, seems weird for Dracut to reco
On Fri, 19 May 2017 at 11:50:51 +0200, Lee Garrett wrote:
> I will be maintaining it alone.
[...]
> I'm open to co-maintaining this package if any individual or team is
> interested.
> I will need a sponsor for this package.
Please consider joining the Games Team. We have Quake enthusiasts who
ca
On Wed, 17 May 2017 at 13:33:06 +0100, Ian Jackson wrote:
> * Websites which reorganise themselves through CSS and/or JavScript
>to try to produce a better selection of visibloe bits depending on
>the screen size.
>
>I find these mildly annoying, but I don't use a smartphone and
>
On Tue, 16 May 2017 at 09:58:11 -0700, Russ Allbery wrote:
> Another thing that would be a really neat addition to a wrapper around
> Minecraft would be to run it inside a restrictive namespace by default.
Yes, that's why I suggested Flatpak. It would also be possible to use
a long bwrap command-l
On Mon, 15 May 2017 at 18:40:34 -0300, Carlos Donizete Froes wrote:
> * Package name: minecraft
> Version : 0.1
> Upstream Author : Carlos Donizete Froes
> * URL : https://minecraft.net
> * License : BSD-2-Clause
> Programming Lang: Shell
This information doe
On Tue, 09 May 2017 at 22:48:23 +, Boylan, Ross wrote:
> I'm a little nervous about doing a chroot when the host system and
> the one in the chroot are from so many generations apart.
wheezy (Debian 7) to jessie (Debian 8) is only one release cycle. I would
expect a wheezy chroot to run well o
On Tue, 11 Apr 2017 at 13:03:14 +1000, Andrew Pollock wrote:
> There's potential functionality overlap with firejail
... and bubblewrap, which is probably a closer equivalent?
(AIUI firejail does the equivalent of Flatpak's convenience layer around
bubblewrap, and more, in the same setuid binary,
Source: efl
Version: 1.8.6-2.5
On Thu, 23 Mar 2017 at 08:55:10 -0400, Ross Vandegrift wrote:
> You only need [to pass --enable-fb explicitly] because you're calling
> debian/rules directly. If you use dpkg-buildpackage then
> DEB_HOST_ARCH_OS will be set, and the Makefile will automatically
> add
On Wed, 15 Mar 2017 at 00:03:21 +0200, Adrian Bunk wrote:
> The relevant question is whether there is a non-zero amount of packages
> where a 1.11 -> 1.15 switch would be hard.
Yes. Based on my admittedly hazy recollections of upgrading the Autotools
build systems in upstream projects across that
Most packages in Debian that run autoreconf currently build-depend
directly or indirectly on automake (version 1.14.1 in jessie, released
2013; version 1.15 in stretch/sid, released in 2015). However, 58
packages in sid still build with automake1.11, released in 2009. This
doesn't seem desirable fo
On Thu, 09 Mar 2017 at 17:52:05 -0500, Marvin Renich wrote:
> If more upstreams were careful to use dynamic loading in these
> situations, it would be less of a problem. In a perfect world, the
> solution would be for foo's maintainer to convince upstream to switch to
> dynamic loading.
(For cont
On Thu, 23 Feb 2017 at 10:02:55 -0800, Nikolaus Rath wrote:
> Yes, but last time I checked a "apt-get source && debuild -us -uc" still
> defaults to using just a single CPU unless you explicitly set
> DEB_BUILD_OPTIONS=parallel.
Check again - dpkg-buildpackage now defaults to -Jauto
(it sets DEB_B
On Thu, 23 Feb 2017 at 12:53:40 +, Ian Jackson wrote:
> We could
> decorate the suite instead, but that does not have any effect on
> generated binaries.
It does have an effect on the changelog inside the source and binary
packages, and on the changes file (which is precisely the signed
instru
On Tue, 21 Feb 2017 at 23:35:44 +, Ben Hutchings wrote:
> Having said that, some ioctls that make sense for block-backed
> filesystems, such as FS_IOC_FIEMAP, won't work on a tmpfs (or nfs,
> ubifs, etc.).
One notable omission is that tmpfs doesn't do generic "user." extended
attributes (due t
On Mon, 20 Feb 2017 at 10:41:49 +0100, Santiago Vila wrote:
> You are somehow trying to equate RC-ness with "it FTBFS in buildd.debian.org".
No, I'm saying that a sufficiently repeatable FTBFS on buildd.debian.org
is effectively release-critical whether Policy says it is or not,
because if we can'
On Mon, 20 Feb 2017 at 01:00:33 +0100, Santiago Vila wrote:
> Wait a moment. How we do define "common" when applied to a "build
> environment"?
Do we rely on it for Debian to function, or was it set up to determine
what works (e.g. for QA)? The former is common; the latter might not
be, and failin
On Fri, 17 Feb 2017 at 18:08:01 -0500, Jeremy Bicha wrote:
> GNOME 3.24 modules have begun including meson build scripts.
It looks as though Meson approximately follows the Autotools-like
build pipeline that dh assumes, so something like this should work:
override_dh_auto_clean:
rm -fr de
On Mon, 13 Feb 2017 at 10:53:18 -0600, Gunnar Wolf wrote:
> Interesting discussion. This (and not particularly your message, but
> this whole thread even leads me to questioning: Does our "finalized"
> changelog lines make *any* sense nowadays?
In the actual upload to the archive (as opposed to th
On Mon, 13 Feb 2017 at 09:42:32 +1100, Ben Finney wrote:
> Simon McVittie writes:
> > This works fine if every commit is final and immutable and is sent
> > directly to the master VCS immediately, but works very poorly if you
> > are proposing commits for someone els
On Sun, 12 Feb 2017 at 09:44:53 -0500, Jeremy Bicha wrote:
> On Sun, Feb 12, 2017 at 9:22 AM, Simon McVittie wrote:
> > I think this is too generic. The upstream name is Recipes, and that name is
> > fine within the context of GNOME
>
> Thanks. I requested that the develop
On Sun, 12 Feb 2017 at 07:55:18 -0500, Jeremy Bicha wrote:
> Package Name: recipes
I think this is too generic. The upstream name is Recipes, and that name is
fine within the context of GNOME (particularly when its machine-readable
name is actually org.gnome.Recipes), but within Debian/Ubuntu it w
On Sun, 12 Feb 2017 at 12:48:35 +, Ian Jackson wrote:
> What do people think ?
I think you're the only person I've ever seen using unfinalized
changelog entries for Debian packages.
If I'm understanding correctly, your motivation to do so is that you
have a strong belief that building a Debia
On Sun, 12 Feb 2017 at 11:33:22 +0100, Alec Leamas wrote:
> On 12/02/17 11:16, Bastien Roucaries wrote:
> > Last time braille stuff break (brick) a FPGA device with a jtag adaptator
> > (serial to jtag). So i really dislike package that bind to all char device.
> >
> > Btw if you do this you need
On Thu, 09 Feb 2017 at 16:47:05 -, Pirate Praveen wrote:
> And short
> description says "tty module from node core for browsers".
Does this mean that this is a polyfill/compatibility shim for
running JavaScript designed for node.js in non-node.js environments
like browsers?
If so, I can't hel
On Fri, 03 Feb 2017 at 12:35:07 +0100, Emilio Pozuelo Monfort wrote:
> On 03/02/17 11:42, Thibaut Paumard wrote:
> > Is there a usertag defined for such issues?
>
> There isn't (yet).
For functional failures triggered by using the Wayland-enabled GNOME Shell,
I started using pkg-gnome-maintain...
On Wed, 01 Feb 2017 at 11:02:08 +0100, Vincent Danjean wrote:
> In an MT context, such a program should probably use setenv between
> the fork and the exec (ie not in MT context)
Calling non-async-signal safe functions after fork but before exec, in
a process that uses threads, is undefined behavi
On Tue, 31 Jan 2017 at 11:15:32 +0100, Mathieu Malaterre wrote:
> I'd like to discuss addition of a new lintian checks for
> getenv/setenv/putenv used in shared libraries.
A massive number of libraries call getenv(). This is not something that
you can just ban. In many cases (any D-Bus implementat
On Mon, 16 Jan 2017 at 10:38:42 +0200, Lars Wirzenius wrote:
> A failing test means there's a bug. It might be in the test itself, or
> in the code being tested. It might be a bug in the test environment.
Nobody is disputing this, but we have bug severities for a reason:
not every bug is release-c
On Sun, 15 Jan 2017 at 01:18:00 +0100, Michael Biebl wrote:
> Am 14.01.2017 um 20:00 schrieb Steve Langasek:
> > I recall this being a misguided attempt to move it out of /dev "because it's
> > not a device". The migration did not go well, especially in the face of
> > chroots that need to have it
Package: initscripts
Version: 2.88dsf-59.8
Severity: normal
On Sat, 14 Jan 2017 at 11:00:51 -0800, Steve Langasek wrote:
> On Fri, Jan 13, 2017 at 03:54:30PM +0000, Simon McVittie wrote:
> > If I'm reading the initscripts code correctly, sysvinit does the reverse
> > by defa
On Fri, 13 Jan 2017 at 18:22:53 +, Ian Jackson wrote:
> Maybe an intermediate position would be to respond to a CI failure by:
> * Increasing the migration delay for the affecting package
> * Notifying the affected package maintainers
I think this makes sense: it gives the maintainer and oth
On Fri, 13 Jan 2017 at 14:14:09 +, Holger Levsen wrote:
> how should /dev/shm be mounted? and how /run/shm?
I believe the "API" is that /dev/shm is either a tmpfs with
/tmp-like permissions (01777), or a symlink to such a tmpfs.
My understanding is that /run/shm is considered to be an
implemen
On Mon, 09 Jan 2017 at 14:28:07 -0800, Michael Lustfield wrote:
> If 3.5 to 3.6 was a typical "minor version," our expectation
> would be that the update comes with security updates and bug fixes
> (not feature changes).
That isn't semver. Semver minor version increments add features in a
backward
On Sat, 07 Jan 2017 at 22:18:45 +, Holger Levsen wrote:
> On Sat, Jan 07, 2017 at 11:11:02PM +0100, Mattia Rizzolo wrote:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677673
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755420
See also https://bugs.debian.org/cgi-bin/bugreport
On Wed, 04 Jan 2017 at 02:10:56 +, Ian Jackson wrote:
> Michael Biebl writes ("Re: "not authorised" doing various desktoppy things"):
> > Check if your session is marked as active and local
> > $ loginctl show-session $XDG_SESSION_ID
>
> I see (amongst other things):
>
> Remote=no
> Activ
On Wed, 04 Jan 2017 at 13:59:26 +0800, Paul Wise wrote:
> On Wed, Jan 4, 2017 at 1:30 PM, Nikolaus Rath wrote:
> > But I am not sure if a package structure like
> >
> > mypkg/upstream/*
> > mypkg/debian/*
> > mypkg/patches/* (?)
> >
> > would have any *practical* benefits over the current situation
On Tue, 03 Jan 2017 at 22:17:33 -0800, Russ Allbery wrote:
> Usually what I have to do (and I think this is a pretty common use case
> for anyone who customizes Debian packages) is that I need to start from a
> package from unstable (or at least newer than stable, or oldstable, or
> ancient Ubuntu,
On Tue, 03 Jan 2017 at 21:59:05 +, Sune Vuorela wrote:
> If I recall correctly, for most
> networky (and removable media things), the default policykit
> configuration is that 'local logged in users' are allowed to do this.
They must usually be active as well as locally logged in. (This means
On Wed, 14 Dec 2016 at 09:21:27 -0500, Sandro Tosi wrote:
> > The replacement for python-vte is:
> >
> > Depends: python3-gi, gir1.2-vte-2.91
> >
> > import gi
> > gi.require_version('Vte', '2.91')
> > from gi.repository import Vte
>
> Thanks Simon, i'll have a look at it again (bu
On Wed, 14 Dec 2016 at 08:50:30 -0500, Sandro Tosi wrote:
> > I took a try and the error message is broken as well. It suggests that the
> > user
> > should install python-vte (Python 2 version!), which is misleading and
> > useless.
> > Also there is no such a package like "python3-vte".
>
> i
Sorry for the long delay to this response; it got pre-empted by
something more urgent, and then I forgot about it.
On Sun, 18 Sep 2016 at 22:19:38 +0900, Osamu Aoki wrote:
> So listing im-config in MBF seems to be FALSE POSITIVE if it is only
> based on this string in the comment.
Yes, looks like
On Thu, 08 Dec 2016 at 07:55:33 +0100, Lucas Nussbaum wrote:
> [0] for services that currently run via cron, it would be interesting to
> transition to running them using systemd service + timer, so that it's
> easy to run the service manually in the same environment when run
> manually (systemctl
On Mon, 28 Nov 2016 at 12:57:35 +0530, Pirate Praveen wrote:
> Features:
> 1. It will build in a clean chroot using sbuild,
> 2. it will run autopkgtest in an lxc container,
> 3. it will offer to run autopkgtest of any or all reverse dependencies,
> 4. it will also offer to rebuild all or any rever
On Wed, 23 Nov 2016 at 02:30:24 +0100, Guillem Jover wrote:
> And although this got enabled by default in gcc-6 6.2.0-7 when PIE
> also got enabled, it seems it got disabled in 6.2.0-10 when I pointed
> out that enabling bindnow in gcc w/o enabling relro too didn't seem to
> make much sense, but th
On Tue, 22 Nov 2016 at 17:48:44 +, Iain R. Learmonth wrote:
> The root certificate has constraints
> that it can only be used to sign domains ending with .dn42
Does this package insert the dn42 CA into the system-wide default CA
store?
(If it does, then I think it would be necessary to tread
On Wed, 09 Nov 2016 at 17:03:45 +1100, Brian May wrote:
> Another situation: You are not listed as the maintainer of the package
> you really care about, and the real maintainer ignores the autoremoval
> notifications. Other people looking at the package bug reports (there
> may be none) may not re
Package: wnpp
Severity: wishlist
Owner: Simon McVittie
Package name: vectis
Version : (unreleased, not ready for wide use yet)
Upstream Author : Simon McVittie
URL : https://git.pseudorandom.co.uk/vectis.git
https://github.com/smcv/vectis
License
On Tue, 01 Nov 2016 at 18:11:27 +0100, Thibaut Paumard wrote:
> The -dbg package is Multi-Arch same. It Depends on the packages for
> which it provides debugging symbols, some of which are Multi-Arch:
> allowed. Lintian complains when I don't specify an architecture for
> those packages:
>
> W: gy
On Mon, 31 Oct 2016 at 17:02:53 +0200, Adrian Bunk wrote:
> The ChangeLog file in the "source" tarball of the hello package is
> generated from the git metadata.
>
> You are saying it is a bug that .git is not shipped in the source
> tarball of GNU hello?
I don't think it is, but I also can't a
On Mon, 31 Oct 2016 at 00:38:22 +0200, Adrian Bunk wrote:
> The "hello" package still builds after you autoreconf the package,
> but the program no longer knows what version it is (automake tries to
> run build-aux/git-version-gen which is not in the source tarball).
I think that's an upstream bu
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?
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; bu
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 mitig
On Tue, 25 Oct 2016 at 10:31:00 +0300, Dmitry Bogatov wrote:
> It may be worth to mention my dh-sysuser debhelper here:
...
>* unless another package requires same users, they are
> removed on package purge
>* if possible, ensures, that install-purge-install cycle saves
>
On Mon, 24 Oct 2016 at 01:28:27 +0500, Lev Lamberov wrote:
> * Package name: bind-key
This seems like a very generic package name, and gives no indication
that it is to do with Emacs.
I suggest talking to an Emacs-related packaging team (for example
Debian Emacs addons team
seems to maintain
On Fri, 14 Oct 2016 at 16:55:25 -0400, Joachim Breitner wrote:
> Hi,
>
> Am Freitag, den 14.10.2016, 19:44 +0200 schrieb Andrew Shadura:
> > It was previously based on pandoc, and a pandoc backend will be
> > available again soon, but the dependency tree with a hard pandoc
> > dependency was just
On Fri, 07 Oct 2016 at 10:09:34 +0200, Philip Hands wrote:
> I only stumbled across 'firejail' recently, but it seems possible that
> one could run the build under it, to lock things down and/or get reports
> of naughtiness.
firejail is a "do what I mean" approach to sandboxing, AIUI. It might
be
On Thu, 15 Sep 2016 at 23:50:33 +0200, Thomas Goirand wrote:
> Recently, the upload python-cryptography broke pyopenssl, and pyopenssl
> had to be upgraded to support the new python-cryptography (I don't have
> the exact details, but it doesn't mater much here...).
The situation here is that pyope
On Sat, 10 Sep 2016 at 00:48:09 +0200, Matthias Klose wrote:
> The arm-linux-gnueabi is not that well defined, so it may include the hard
> float
> variant as well. However Debian default to armv4t, while the default
> configuration for upstream is armv5. However with the selected defaults
> Deb
On Fri, 09 Sep 2016 at 18:11:05 +0200, Markus Koschany wrote:
> On 08.09.2016 21:54, Ralf Treinen wrote:
> > That is certainly not true for orphaned packages with minimal maintenance
> > by the QA team. At least when I do a QA upload I usually don't bump the
> > Standards-Version field, simply bec
On Thu, 08 Sep 2016 at 08:44:54 -0700, Russ Allbery wrote:
> I don't see any inherent reason why that
> should have to be the case (other than, of course, that this Python
> behavior is long-standing and lots of software depends on it
I suspect that Python scripts relying on their own directory be
On Sun, 04 Sep 2016 at 17:30:43 +0100, Jonathan de Boyne Pollard wrote:
> Simon McVittie:
> > To the best of my knowledge, the listenable address "unix:runtime=yes"
> > (as in "dbus-daemon --address=unix:runtime=yes") does work on generic
> > Un
On Sun, 04 Sep 2016 at 19:24:09 +0100, Jonathan de Boyne Pollard wrote:
> You think that a good "replacement directory" is /run/user/$EUID . Alright.
> Then when your program is told address=unix:runtime=yes and there's no
> XDG_RUNTIME_DIR, please make it fall back to using the directory that you
On Mon, 29 Aug 2016 at 15:49:55 +0100, Jonathan de Boyne Pollard wrote:
> One can run PCDMd,
> kdm, gdm, and lxdm under nosh service management, and it would be good for the
> programs in the login session(s) to just expect "/run/user/$UID/..." sockets,
> as one already obtains from running "user"
biss
onioncircuits (U)
Scott Kitterman
pyqt5 (U)
python-qt4 (U)
quassel (U)
Sebastian Dröge
dbus (U)
dbus-glib (U)
dbus-python (U)
libbonobo (U)
libunique (U)
libunique3 (U)
vala (U)
Sebastian Reichel
vala (U)
Sebastien Delafond
aptly
Sergey "
On Sat, 27 Aug 2016 at 10:33:36 +0300, Dmitry Bogatov wrote:
>
> > > > * conntrackd & systemd are very good integrated (using libsystemd)
> > >
> > > I hugely support idea of dynamically loading libsystemd.
> >
> > Please don't, no. While I do think packages should keep sysvinit
> > support as l
On Mon, 15 Aug 2016 at 18:17:52 +0200, Stefano Zacchiroli wrote:
> The problem we're having here is clearly about *tooling*. If we had a
> good toolchain to compile and audit machine-readable debian/copyright
> files without sweating, nobody would complain.
I have three slightly devil's-advocate r
On Wed, 10 Aug 2016 at 22:51:47 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Re: copyright precision"):
> > Self-imposed policy of documenting copyright information:
>
> Personally, I think it would be much better if binary packages had
> accurate centrally
On Wed, 10 Aug 2016 at 11:12:55 +0800, Paul Wise wrote:
> The only possible way to solve this in general terms is, accurate
> document the copyright/license of the source package using the
> machine-readable format and during builds, track the transformation of
> input files in the source package t
On Wed, 03 Aug 2016 at 21:47:38 +0100, Simon McVittie wrote:
> dbus-default-session-bus: Debian's preferred implementation of
> dbus-session-bus
Andreas Henriksson points out on IRC that default-dbus-session-bus is
more like the situation with mail-transport-agent and default-mta
Package: debian-policy
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org
I propose two new virtual packages:
dbus-session-bus: anything providing the D-Bus well-known session bus
for user login sessions
dbus-default-session-bus: Debian's preferred implementation of
dbus-session-bus
On Mon, 01 Aug 2016 at 12:48:26 +0200, Guus Sliepen wrote:
> Last time I looked at it, systemd-networkd required several
> configuration files just to bring up a single interface.
What were the others, beyond the .network file? This is live configuration
from my home server, which has two network
On Mon, 01 Aug 2016 at 12:40:37 +0200, Adam Borowski wrote:
> On Mon, Aug 01, 2016 at 12:31:14PM +0200, Marco d'Itri wrote:
> > We should also think hard about switching to a new default since
> > currently many other major distributions are moving to NetworkManager
> > and/or systemd-networkd (w
On Fri, 29 Jul 2016 at 11:00:52 +0100, Paul Sladen wrote:
> Previous packaging working had been done since 2009, and published
> in the APT repositary documented at:
>
> http://soft.g-vo.org/repo
> http://vo.ari.uni-heidelberg.de/debian
>
> Thus, despite this being the initial upload to Debia
On Thu, 28 Jul 2016 at 08:33:21 -0400, Marvin Renich wrote:
> * Simon McVittie [160727 20:04]:
> > On Wed, 27 Jul 2016 at 18:02:32 +0200, Laurent Bigonville wrote:
> > > Shouldn't this
> > > dependency only be declared at some other level (libdbus, GDBus,...)?
>
On Wed, 27 Jul 2016 at 23:48:42 -0700, Josh Triplett wrote:
> I can think of another reason that this might change: if we introduce an
> (experimental, and eventually non-experimental) variant based on a
> future stable version of kdbus.
The usual difficulties of depending on kernel features aside
601 - 700 of 1151 matches
Mail list logo
