Re: Offer to make a native 32-bit system avaiable

Thank you for the offer, but no need. It is not needed in Debian infrastructure. On Sat, 13 Jan 2024, 19:18 rhys, wrote: > > > >> I know the difference between a 32-bit processor and a 64-bit processor. > > > > Obviously you don't. Or at least are not aware about consequences. > > > > > > Sinc

Re: Signature strength of .dsc

On Fri, 1 Dec 2023 at 00:20, Dimitri John Ledkov wrote: > > Hi, > > Currently dak requires signatures on .changes & .dsc uploads. .changes with > signatures are publicly announced and then .dsc are published in the archive > with signatures. .changes references .dsc. >

Re: Signature strength of .dsc

Hi, On Fri, 1 Dec 2023 at 10:50, Simon Josefsson wrote: > > Salvo Tomaselli writes: > > >> hi, on "no public key" list there are my uploads, I'm debian maintainer > >> (https://nm.debian.org/person/fantu/), I signed with my key and I have > >> DM upload right for them > >> (https://qa.debian.org

Signature strength of .dsc

Hi, Currently dak requires signatures on .changes & .dsc uploads. .changes with signatures are publicly announced and then .dsc are published in the archive with signatures. .changes references .dsc. All .dsc have Checksums-Sha256 for the files they reference, .dsc itself can be verified through

Bug#971795: ITP: git-pw -- tool for integrating Git with Patchwork

Package: wnpp Severity: wishlist Owner: Dimitri John Ledkov X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: git-pw Version : 2.0.0 Upstream Author : Stephen Finucane https://github.com/stephenfin * URL : https://github.com/getpatchwork/git-pw * License

Can Debian packaging changes require a CLA?

Can a Debian Package Maintainer require CLA for accepting packaging changes and distro patches to be uploaded into Debian itself? (case in point, debian maintainer & upstream wear the same hat, and maintain upstream code & packaging on github.com, under a company org with a CLA bot, rejecting debi

Re: Heads up: persistent journal has been enabled in systemd

On Sat, 1 Feb 2020 at 22:01, Michael Biebl wrote: > > Hi Steve > > Am 01.02.20 um 14:36 schrieb Steve McIntyre: > > Michael Biebl wrote: > >> > >> with today's upload of systemd 244.1-2 I finally enabled persistent > >> journal by default [1]. It has been a long requested feature. > >> > >> The pa

Re: Debian Buster will only be 54% reproducible (while we could be at >90%)

On Tue, 5 Mar 2019 at 13:34, Holger Levsen wrote: > > hi, > > disclaimer: this has not yet been verified by anyone other than myself, > so I could very well be wrong. Reproducible builds are about enabling > anyone to independently verify that... ;p > > > == Reproducibility in theory == > > Accord

Re: Please drop anacron from task-desktop

On Fri, 8 Mar 2019 at 15:15, Daniel Reichelt wrote: > > > And surely we support other, strange and not so strange, choices, > > sometimes more and sometimes less, but yawn. > > And yet Debian claims to support - pardon - offer init systems other > than systemd for usage. > > > Either: make a clean

Re: Please drop anacron from task-desktop

On Fri, 8 Mar 2019 at 14:48, Holger Levsen wrote: > > On Fri, Mar 08, 2019 at 01:46:59PM +, Daniel Reichelt wrote: > > > Shouldn't that be the other way around? Having .timer but not a cronjob > > > is > > > a nasty bug, having a cronjob but not .timer is fine (at least unless you > > > have

Re: julia_1.0.0-1_amd64.changes REJECTED

On Wed, 21 Nov 2018 at 15:57, Holger Levsen wrote: > > On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote: > > Why is any of this a reason for an ftpmaster REJECT ? I still think > > all of this should be handled as bugs (possibly RC bugs) in the BTS > > in the conventional way, after AC

Re: Our build system may be broken: /bin vs /usr/bin

On Mon, 19 Nov 2018 at 15:02, Dirk Eddelbuettel wrote: > > > > tl;dr: We may be messing up /bin and /usr/bin on some platforms > > > Sorry for the alarming headline but #913982 was filed, indepedently > corrobated and simultaneously discovered by upstream. > > GNU R has long been relying on sed,

Re: Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

On 20 April 2018 at 15:46, Marvin Renich wrote: > Package: base-files > Version: 10.1 > Severity: wishlist > > * Stephan Seitz [180420 07:38]: >> On Do, Apr 19, 2018 at 11:00:37 +0200, Christoph Biedl wrote: >> > But being human I prefer names over numbers, even if it's just for >> > aesthetic re

Re: Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

On 18 April 2018 at 08:18, Emilio Pozuelo Monfort wrote: > On 18/04/18 01:30, Cyril Brulebois wrote: >> That's another perfect example why udeb additions should get reviewed: >> we would have noticed another buggy package, and its bugginess might not >> have been copied over to another package. >

Re: Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

On 18 April 2018 at 00:30, Cyril Brulebois wrote: > Hi, > > Dimitri John Ledkov (2018-04-17): >> First, I apologize for not responding to this email earlier, as I have >> missed it in my mailbox. > > It's a mail from hours ago, so there's no apology ne

Re: libzstd_1.3.3+dfsg-2_multi.changes REJECTED

Hi, On 17 April 2018 at 20:00, Thorsten Alteholz wrote: > > as requested by waldi ... > With all due respect to yourself, waldi, and ftp-team (masters & assistants & wizards), I find this reject comment inappropriate, and not at all informative enough. As far as I can tell, the package uploaded

Re: Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

On 17 April 2018 at 19:01, Cyril Brulebois wrote: > Dimitri John Ledkov (2018-01-15): >> On 15 January 2018 at 00:27, Cyril Brulebois wrote: >> > Hi, >> > >> > Cyril Brulebois (2018-01-12): >> >> Your package is no longer installable (along with

Re: Planning the removal of c_rehash | mass bug filling

On 5 April 2018 at 23:22, Sebastian Andrzej Siewior wrote: > > Hi, > > the openssl package provides the c_rehash script which creates the links > from .Y to the actual certificate in /etc/ssl/certs/. During the > transition from 0.9.8 to 1.0.0 the hash (for the X part) changed from > md5 t

Re: Debian part of a version number when epoch is bumped

On 16 February 2018 at 02:00, Guillem Jover wrote: > Hi! > > Given that other parts of the original thread have started to repeat > the same that has been discussed in previous referenced discussions, > or even within this thread iteration, I've sat down and written a > dpkg FAQ entry: > > >

Re: The value of unmodified conffiles left on disk of removed, but not purged, packages

On 25 February 2018 at 22:42, Don Armstrong wrote: > On Sun, 25 Feb 2018, Dimitri John Ledkov wrote: >> A couple of conffiles were /etc/X11/Xsession.d/00upstart and >> /etc/X11/Xsession.d/99upstart which assumed that upstart would be >> alwasy be available, and in bionic afte

The value of unmodified conffiles left on disk of removed, but not purged, packages

Recently, in Ubuntu we have discovered the following upgrade fallout. On xenial -> bionic upgrades, upstart binary package was removed but not purged. As it's no longer needed for the installation, and upstart binary package is no longer shipped in bionic. However, the conffiles are left on disk,

Re: Repackaging upstream source with file modifications?

On 12 February 2018 at 10:28, Colin Watson wrote: > The developer's reference says [1]: > > A repackaged .orig.tar.{gz,bz2,xz} [...] *should not* contain any file > that does not come from the upstream author(s), or whose contents has > been changed by you. > > My recent attempt to upload gr

Re: Removal of upstart integration

; /etc/dpkg/dpkg.cfg.d/local > /etc/group.org > + /etc/init > /etc/modprobe.d/ipv6.conf > > > 2017-08-30 15:39 GMT+02:00 Dimitri John Ledkov : >> upstart - event-based init daemon has been removed from debian and is >> currently only p

Let's talk about conflicts and omissions in the udeb distribution

Unpacking libkmod2-udeb (24-1) ... dpkg: warning: overriding problem because --force enabled: dpkg: warning: trying to overwrite '/sbin/depmod', which is also in package busybox-udeb 1:1.27.2-1 dpkg: warning: overriding problem because --force enabled: dpkg: warning: trying to overwrite '/sbin/insm

Re: Mandates explicit -std=c++XY for c++ projects

On 10 October 2017 at 14:26, Michael Stone wrote: > On Tue, Oct 10, 2017 at 02:16:36PM +0100, Dimitri John Ledkov wrote: >> >> On 10 October 2017 at 14:07, Gert Wollny wrote: >>> >>> I think nobody would object if you set the flag to -std=c++98 for a >>&g

Re: Mandates explicit -std=c++XY for c++ projects

On 10 October 2017 at 14:07, Gert Wollny wrote: > Hello Mathieu, > > Am Dienstag, den 10.10.2017, 11:45 +0200 schrieb Mathieu Malaterre: > [...] > I don't think there is much to gain from it. Whenever there is a > change >> > in the major version of gcc/g++ many bugs show up and all involved >> >

Re: Mandates explicit -std=c++XY for c++ projects

On 10 October 2017 at 07:45, Mathieu Malaterre wrote: > Dear all, > > Since the GCC 6 release [1], the default mode for C++ is now > -std=gnu++14 instead of -std=gnu++98. What this means is that upon > (re)compilation a library written for c++98 will be recompiled using a > different c++ standard

Re: Removal of upstart integration

On 13 September 2017 at 13:56, Ian Jackson wrote: > Alexandre Detiste writes ("Re: Removal of upstart integration"): >> Please also sprinkle these maintainers scripts with some >> >> rmdir /etc/init --ignore-fail-on-non-empty > > That should be > > rmdir --ignore-fail-on-non-empty /etc/init >

Re: Removal of upstart integration

On 30 August 2017 at 14:44, Holger Levsen wrote: > On Wed, Aug 30, 2017 at 02:39:16PM +0100, Dimitri John Ledkov wrote: >> upstart - event-based init daemon has been removed from debian and is >> currently only present in oldstable. >> >> Many packages however sti

Removal of upstart integration

upstart - event-based init daemon has been removed from debian and is currently only present in oldstable. Many packages however still ship upstart integration. Please consider removing /etc/init/* conffiles from your packages. Do note, that typically this will require a debian/pkg.maintscript sni

Bug#867807: O: libavg -- media-centric application development platform

Package: wnpp Severity: normal I can't even remember now, how I ended up maintaining this package. I believe it was in ubuntu for a while, and then i was asked to upload it into debian too. The package is in an ok state now, but I'm not sure I will touch it again. It may need a facelift for packag

Re: github and its workflows (was Re: manpages.debian.org has been modernized!)

On 30 January 2017 at 12:53, The Wanderer wrote: > On 2017-01-30 at 07:38, Bernd Zeimetz wrote: > >> On 01/30/2017 01:32 PM, The Wanderer wrote: >> >>> If someone isn't cloning the repository locally, how is that >>> someone creating the patch which is in the git repo which is >>> requested to be

Bug#844713: ITP: partman-swapfile -- add support for creating swapfiles

Package: wnpp Owner: Dimitri John Ledkov Severity: wishlist * Package name: partman-swapfile Version : 1 Upstream Author : d-i team * URL or Web page : d-i * License : GPL Description : add support for creating swapfiles I am working on minimising number of

Re: OpenSSL 1.1.0

There is a large number of packages currently build-depending on openssl 1.0 explicitly. Supporting dual-stack 1.0 & 1.1 openssl is a lot of work. In Ubuntu, I have reverted the 1.1 migration, and forced 1.0 to be used and provided by both libssl-dev & libssl1.0-dev packages. This was done after a

Re: openssl transition

Hello, On 27 October 2016 at 11:40, Jörg Frings-Fürst wrote: > Hello, > > I have read the discussion about the openssl transition here again. > > One of the last notes was to be used openssl 1.0 and 1.1 in parallel > because of the non-trivial changes. > > So I have some questions: > > - The para

Re: When should we https our mirrors?

On 15 October 2016 at 20:25, Tollef Fog Heen wrote: > ]] Paul Tagliamonte > >> So, when are we going to push this? If not now, what criteria need to >> be met? Why can't we https-ify the default CDN mirror today? > > The usual crypto answer: because key handling is hard. > > Doing this for the per

Re: When should we https our mirrors?

On 15 October 2016 at 19:03, Paul Tagliamonte wrote: > > So, the real question: > > So, when are we going to push this? If not now, what criteria need to be > met? Why can't we https-ify the default CDN mirror today? > It is my understanding that in 2016 there is a huge difference between the fol

Re: uscan download from sourceforge doesn't download what you expect!

On 15 October 2016 at 18:47, Steve M. Robbins wrote: > ... at least not for boost. > > I downloaded the latest release manually by following the links from boost.org > to https://sourceforge.net/projects/boost/files/boost/1.62.0/ > boost_1_62_0.tar.bz2/download > Yes, this is known to me, but I d

Re: Use and abuse of the unreproducible tag

Hello, On 13 September 2016 at 12:55, Sebastiaan Couwenberg wrote: > > Dear Santiago, > > Thanks for publicly shaming me, makes me feel much better about your > bugreports. > > On 09/13/2016 01:49 PM, Santiago Vila wrote: > > You can't reproduce it, or you don't want to reproduce it? > > I added

Re: Upcoming change to perl: current directory in @INC

Hello, On 29 August 2016 at 14:39, Dominic Hargreaves wrote: > tl;dr: '.' is being removed from perl's @INC by default; some breakage > in apps expected. > > For some years[1], it's been known that perl's habit of including '.' > in its module load path, (@INC) is potentially dangerous, since it

Re: Porter roll call for Debian Stretch

Hello, On 30 August 2016 at 23:07, Lucas Nussbaum wrote: > On 22/08/16 at 19:12 +0200, Bálint Réczey wrote: >> Hi Guillem, >> >> 2016-08-21 14:02 GMT+02:00 Guillem Jover : >> > Hi! >> > >> > On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote: >> >> I'm testing a set of patches [2] for gcc

Re: Does anybody plan to keep using sbuild with Squeeze or older chroots?

Hello, On 21 August 2016 at 22:05, Johannes Schauer wrote: > Hi, > > Quoting Peter Samuelson (2016-08-21 11:45:35) >> [Johannes Schauer] >> > Old sbuild will not help you. The problem is mainly, that older >> > chroots contain an apt installation that has no support for the >> > [trusted=yes] opt

Re: Building qemu bootloaders for multiple architectures

Hello, On 21 Aug 2016 2:00 p.m., "Bastian Blank" wrote: > > Hi folks > > I currently maintain ipxe. It is usualy used by x86 qemu to do all the > network stuff. It also provides a large binary that can be loaded by > grub. > > As it is pulled in by qemu-system-x86 it needs to be installable on

Re: Bug#834756: ITP: powershell -- scripting language interpreter built on .NET

On 18 August 2016 at 18:17, Marcin Kulisz wrote: > On 2016-08-18 16:27:23, Luke W Faraone wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Luke W Faraone >> >> * Package name: powershell >> Version : 6.0.0~alpha9 >> Upstream Author : Microsoft >> * URL : https:/

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

On 12 July 2016 at 19:29, Adam Borowski wrote: > On Tue, Jul 12, 2016 at 06:39:28PM +0100, Adam D. Barratt wrote: >> On Tue, 2016-07-12 at 16:34 +0100, Simon McVittie wrote: >> > GNOME 3.22 will be released before squeeze freezes >> >> That seems a little unlikely. :) > > Yeah, it was a mistake to

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

On 11 July 2016 at 04:07, wrote: >>Say what you want. > > Now I want to know if Debian Stable can in some extreme cases, like in this > case with btrfs, replace > not_very_good kernel module that is shipped with its current kernel with a > kernel module from other (older or newer) version of Li

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

Hello, On 8 July 2016 at 16:55, wrote: > I value stability of a FS over other considerations like shiny new features > and performance. I know that Debian Stable includes only that versions of > software that were considered rock-solid and mostly bug-free. But on the > other hand I read docum

Re: BOOST-1.60 compiled with g++6, [Was: GCC 6 & binutils for the Debian stretch release]

Hello, On 27 June 2016 at 11:37, Dimitri John Ledkov wrote: > Hello, > > On 26 June 2016 at 11:31, Gert Wollny wrote: >> Hi all, >> >> considering that BOOST 1.60 changes the ABI when compiled with -std >= >> c++11 versus -std <= c++03 (cf. [1]) , and

Re: BOOST-1.60 compiled with g++6, [Was: GCC 6 & binutils for the Debian stretch release]

Hello, On 26 June 2016 at 11:31, Gert Wollny wrote: > Hi all, > > considering that BOOST 1.60 changes the ABI when compiled with -std >= > c++11 versus -std <= c++03 (cf. [1]) , and that g++-6 defaults to > -std=c++14 it would probably be a good idea if a boost >= 1.60 version > compiled with g++

Re: Dropping upstart jobs (or not)

Hello, On 4 June 2016 at 00:31, Michael Biebl wrote: > > Hi, > > I just became aware recently that upstart has been removed from the > archive (unstable/testing) [1]. > > Now I'm wondering what to do about the upstart job files that were added > to various packages. Do we > - continue to ship the

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

On 15 May 2016 at 19:49, Niels Thykier wrote: > Bálint Réczey: >> Hi, >> >> [...] >> > > Hi, > >> I think making PIE and bindnow default in dpkg (at least for amd64) would be >> perfect release goals for Stretch. >> > > I support the end goal, but I suspect we should enable PIE by default > via GC

Re: Time to reevaluate the cost of -fPIC?

On 14 May 2016 at 21:12, Niels Thykier wrote: > Marco d'Itri: >> On May 03, Josh Triplett wrote: >> >>> While this doesn't make PIC absolutely free, it does eliminate almost >>> all of the cost, to the point that it no longer seems worthwhile to >>> build without -fPIC. Apart from that, building

Re: Popular packages in Ubuntu that is missing in Debian/main

Hello, Looking at the list none of it makes sense in Debian, and the query is inherently biased. This is simply the list of packages installed by default on an Ubuntu Desktop default installation. There are some additions - e.g. nvidia stuff is automatically installed through ubuntu-drivers, if n

Re: migrating to Debian gitlab (was: Re: GitLab B.V. to host free-software GitLab for Debian project)

On 12 Feb 2016 4:59 a.m., "Holger Levsen" wrote: > > On Freitag, 12. Februar 2016, Dimitri John Ledkov wrote: > > [ -d /run/systems/system ] specifically, as per sd_booted upstream API. > > typo, you ment [ -d /run/systemd/system ] > I hate predictive text on my

Re: migrating to Debian gitlab (was: Re: GitLab B.V. to host free-software GitLab for Debian project)

On 11 Feb 2016 3:37 p.m., "Adam Borowski" wrote: > > On Thu, Feb 11, 2016 at 11:59:09PM +0530, Pirate Praveen wrote: > > Checking /proc/cmdline was working in my test machine as I had systemd before it became the default. > > > > I think checking /proc/1/cmdline will be a better method of checking

Bug#813772: ITP: openssl-ibmca -- libica based hardware acceleration engine for OpenSSL

Package: wnpp Owner: Dimitri John Ledkov Severity: wishlist * Package name: openssl-ibmca Version : 1.3.0 Upstream Author : openCryptoki Project * URL or Web page : http://sourceforge.net/projects/opencryptoki/files/libica%20OpenSSL%20Engine/ * License : OpenSSL-like

Bug#813765: ITP: libica -- hardware cryptography support for IBM System z hardware

Package: wnpp Owner: Dimitri John Ledkov Severity: wishlist * Package name: libica Version : 2.5.0 Upstream Author : openCryptoki project, IBM Corp * URL or Web page : http://sourceforge.net/projects/opencryptoki/files/libica/ * License : Common Public License V1.0

Re: Statically linked library in libdevel packages? (Was: Status of teem package (packaging moved from svn to git))

Hello, On 28 January 2016 at 14:38, Ian Jackson wrote: > Andreas Tille writes ("Statically linked library in libdevel packages? (Was: > Status of teem package (packaging moved from svn to git))"): >> I came across this question since policy says (see link above) that >> static libraries are *usu

Re: Renaming the Debian Project

Hello, Your email is highly insensitive due to impeccable timing. At the present moment Debian project mourns the passing of Ian Murdock. https://bits.debian.org/2015/12/mourning-ian-murdock.html A lot of Debian Developers and the wider Debian community have great respect for the amazing things

Re: tracker.debian.org replaces packages.qa.debian.org for email subscriptions

On 9 December 2015 at 13:58, Jakub Wilk wrote: > * Raphael Hertzog , 2015-12-09, 14:43: >>> >>> How about adding a List-Id header (RFC 2919) there? MUAs may have better >>> user interfaces for splitting on List-Id's than other headers. Just an idea. >> >> >> And we would use package name + servic

Re: Bug#807146: ITP: koji -- RPM-based build system

Please coordinate, see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806953 On 6 December 2015 at 01:42, Marek Marczykowski-Górecki wrote: > Package: wnpp > Severity: wishlist > Owner: "Marek Marczykowski-Górecki" > > * Package name: koji > Version : 1.10.0 > Upstream Autho

Re: sid on openvz

On 7 December 2015 at 14:50, Marco d'Itri wrote: > On Dec 07, Aurelien Jarno wrote: > >> Have there also backported recent glibc or systemd to these systems and >> do they support such a configuration? This is what we are talking about >> here. > The *hosts* still use Centos 6, but so far more re

Re: The sixth field (fs_passno) should be zero

On 24 November 2015 at 04:45, Christoph Anton Mitterer wrote: > On Tue, 2015-11-24 at 03:23 +0000, Dimitri John Ledkov wrote: >> btrfs check is a destructive tool, that can attempt repairing btrfs >> filesystem. it should not be run automatically, nor non-interractive, >> nor

Re: The sixth field (fs_passno) should be zero

On 24 November 2015 at 03:12, Christoph Anton Mitterer wrote: > On Tue, 2015-11-24 at 02:51 +0000, Dimitri John Ledkov wrote: >> This is currently the case for xfs and btrfs, which imho is silly. > Well sooner or later, btrfs check is declared stable and then I think > we do want

The sixth field (fs_passno) should be zero

Hello, Most filesystems support destructive operations, with a goal to recover data via some-sort check/repair functionality e.g. btrfs check/rescue, xfs_repair etc. Some filesystems also require periodic maintenance calls, e.g. something like the `harmless' fsck on each mount. Some filesystems

Re: Defaulting to i686 for the Debian i386 architecture

On 29 September 2015 at 17:24, Josselin Mouette wrote: > > As of Knights Landing, it is based on Airmont Atom cores which indeed support > x86_64. > Correct. -- Regards, Dimitri.

Re: Defaulting to i686 for the Debian i386 architecture

Hello, On 28 September 2015 at 22:44, Paul Wise wrote: > > On Mon, Sep 28, 2015 at 11:14 PM, Ben Hutchings wrote: > > > We propose to drop support for i386 processors older than 686-class in > > the current release cycle. This would include folding libc6-i686 into > > libc6, changing the default

Re: binNMU or reproducible builds (choose only one)

On 17 September 2015 at 22:29, Wookey wrote: > +++ Santiago Vila [2015-09-17 22:53 +0200]: >> [ Dropping cc and moving to devel only ]. >> >> >> Well, from the point of view of build-reproducibility, what is broken is the >> whole binNMU idea. > > It also causes a lot of trouble for multiarch. To

Re: [DH] Planning to remove deprecated commands and compat levels in debhelper

On 14 September 2015 at 11:11, Matthias Klose wrote: > On 09/14/2015 08:38 AM, Niels Thykier wrote: >> On 2015-09-13 21:02, Matthias Klose wrote: >>> [...] >>> >>> still using the globbing feature for command line arguments in DH_COMPAT=2 >>> mode. >>> Was this re-added in higher levels again? >

Re: system upgrade by systemd

On 1 September 2015 at 03:43, Marco d'Itri wrote: > On Aug 31, Dimitri John Ledkov wrote: > >> Ideally the update generators, targets and units should be split into >> a separate package and not installed by default. Since those are >> really unexpected on Debian. &g

Re: system upgrade by systemd

On 31 August 2015 at 10:43, Michael Meskes wrote: >> This is getting ridiculous, are you now claiming the Debian Gnome team >> or Gnome upstream was tracking the Windows 10 betas? > > If anything is getting ridiculous then it's people believing we know better > hen the user when a line is to be us

Re: Bug#791072: icu: library transition may be needed when GCC 5 is the default

On 2 August 2015 at 12:59, Matthias Klose wrote: > On 08/02/2015 01:44 PM, László Böszörményi (GCS) wrote: >> Control: tags -1 help >> >> Hi Matthias, >> >> On Sun, Aug 2, 2015 at 12:18 AM, László Böszörményi (GCS) >> wrote: Pretty please upload the version from experimental to unstable

Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull ’

On 10 July 2015 at 15:38, Ian Jackson wrote: > I realise I'm coming to this conversation late, but: > > I have some experience of writing a stunt git push receiver. I would > be willing to write another. > > The rough shape would be something like: > > * Instead of doing git-request-pull, submit

Re: Facilitating external repositories

On 4 June 2015 at 17:18, Wouter Verhelst wrote: > - Run "apt-get update"; > - Install the "eid-mw" and/or "eid-viewer" packages. These two steps can be accomplished with a single APT URL, e.g.: install pkg which will refresh and install request package(s). Ubuntu's software centre is the defaul

Re: git and https

On 27 May 2015 at 23:00, wrote: > On Wed, May 27, 2015 at 10:44:17PM +0100, Dimitri John Ledkov wrote: >> On 27 May 2015 at 09:08, Wouter Verhelst wrote: >> > On Mon, May 25, 2015 at 11:38:06AM -0700, Josh Triplett wrote: >> >> > While we're on the su

Re: git and https

On 27 May 2015 at 09:08, Wouter Verhelst wrote: > On Mon, May 25, 2015 at 11:38:06AM -0700, Josh Triplett wrote: >> > While we're on the subject of git security...should we stop >> > recommending that non-account-holders use git:// (most efficient, but >> > insecure against MITM unless you manuall

Re: please use signed git commits (and tags)

On 26 May 2015 at 19:25, Vincent Bernat wrote: > ❦ 26 mai 2015 14:38 -0300, Henrique de Moraes Holschuh : > >>> A solution to this without history rewriting is to tag the commits you >>> want to sign. >>> >>> You could tag any commit at any time, and sign that tag. Impractical if >>> you want to

Re: please use signed git commits (and tags)

On 25 May 2015 at 09:33, Bastian Blank wrote: > On Mon, May 25, 2015 at 09:51:41AM +0200, Thomas Koch wrote: >> On Sunday 24 May 2015 13:02:38 Thomas Koch wrote: >> > Git supports signing of commits since version 1.7.9. Everybody should sign >> > git commits always. >> There is however the argumen

Re: please use signed git commits (and tags)

On 24 May 2015 at 15:12, Iain R. Learmonth wrote: > Hi, > > On Sun, May 24, 2015 at 01:02:38PM +0200, Thomas Koch wrote: >> Git supports signing of commits since version 1.7.9. Everybody should sign >> git >> commits always. > > What is the overhead on this? I keep my main key offline these days

Re: Packages to install be default for Stretch

On 5 May 2015 at 19:45, Ansgar Burchardt wrote: > * Packages currently at "important": > - cron: > Not needed in chroot/container environments. Hm, i'd say it's not needed full-stop. There are systemd timer units and e.g. systemd-cron that satisfy the need for periodic execution, with

Half-cycle

Could we: Freeze in 6-8 months Release in 10-12 months -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUhCL4FtcwE4-m=K0G1BO8drH=4gmw1g

All Git workflows lack review / extras interchange format & thus decentralised unauthenticated review system

Heya, Interesting points. Looking at bzr/launchpad it has a nifty feature: email-in bzr bundle. Bzr bundle is like git-format-patch, however one can pull from it rather than merely apply. (Essentially it has bencoded objects at the end of the patch). The difference is complete round-trip (identica

Re: debian github organization ?

On 16 Apr 2015 12:05 pm, "Sven Bartscher" < sven.bartsc...@weltraumschlangen.de> wrote: > > On Thu, 16 Apr 2015 09:04:07 -0600 > Dimitri John Ledkov wrote: > > > I'd rather see gitlab.debian.net :) > > I don't a reason to have gitlab/github/someo

Re: debian github organization ?

I'd rather see gitlab.debian.net :) Which is similar in spirit to ask.debian.net. PS. Sorry for top reply from mobile phone. On 16 Apr 2015 7:46 am, "Jérémy Lal" wrote: > Hello, > > i was wondering if debian had a github account as an organization, where > maintainers could be added. > > This i

Re: Bug#772736: ITP: pathlib -- Set of classes to handle filesystem paths

On 12 December 2014 at 02:23, Barry Warsaw wrote: > On Dec 12, 2014, at 08:36 AM, Ben Finney wrote: > >>Even for the source package name, “pathlib” is IMO too general. This is >>specifically a library for Python programmers only; its source package >>name should not grab a generic name like “pathl

Re: Using build profiles beyond bootstrapping&cross (was: Re: Can/should we have an efi/efi-any platform architecture?)

Hello, On 12 December 2014 at 11:48, Johannes Schauer wrote: > Hi, > > Quoting Simon McVittie (2014-12-12 12:09:05) >> Yes, but I think that's exactly what I want for dbus' use-case? I want >> to build-depend on valgrind (I thought it was valgrind-dev, but it's >> actually valgrind) on exactly th

Re: Can/should we have an efi/efi-any platform architecture?

On 11 December 2014 at 20:07, Neil Williams wrote: > On Thu, 11 Dec 2014 19:36:19 +0100 > Simon Richter wrote: > >> Hi Leif, >> >> On 11.12.2014 19:08, Leif Lindholm wrote: >> >> > If we could transition this to be able to specify efi-all (or >> > whatever) instead of an explicit list of certain

Re: Age of built packages to be part of the jessie release?

Following on this conversation. I did some simple stats. There are 6361 binary packages that have the same name in stable and testing on (all, amd64) architecture. This translates into 4821 source packages. Skimming through the list of them, I've poked some that for sure will generate a diff if re

Re: Age of built packages to be part of the jessie release?

On 25 November 2014 at 20:33, Manuel A. Fernandez Montecelo wrote: > 2014-11-25 11:14 Dimitri John Ledkov: >> >> On 24 November 2014 at 18:56, Manuel A. Fernandez Montecelo >> wrote: >>> >>> >>> Would it make sense to trigger rebuilds (or binNMUs

Re: Age of built packages to be part of the jessie release?

On 24 November 2014 at 18:56, Manuel A. Fernandez Montecelo wrote: > 2014-11-23 14:27 Stuart Prescott: >> >> Svante Signell wrote: >> >>> I wonder how old a package build can be to be part of the release. Some >>> packages are built up to a year ago, and rebuilding them now FTBFS. >> >> >> As othe

Re: Jessie Freeze -> What is the next release name? (jessie+1)

On 9 November 2014 18:36, Adam D. Barratt wrote: > On 2014-11-09 9:23, Matthias Urlichs wrote: >> >> See the debian-devel archives from mid-Fenruary 2014. According to Neil >> McGovern, the code name shall be "zurg". >> > https://lists.debian.org/debian-devel/2014/02/msg00905.html >> >> >> Whi

Re: Reminder: Removing < 2048 bit keys from the Debian keyrings

On 8 November 2014 17:05, Thijs Kinkhorst wrote: > On Sat, November 8, 2014 17:09, Jonathan McDowell wrote: >> We had hoped to be down to a small number of special cases to deal with >> by this point, but with the numbers still looking this bad we're not >> yet at a stage where we can work out app

Re: dgit and git-dpm

On 3 November 2014 21:32, Bernhard R. Link wrote: > * Ian Jackson [141103 19:13]: >> The point is that the dgit user probably will have done git diff >> before dgit build / push. git diff provides a more convenient diffing >> tool than debdiff, and eyeballing the same thing twice is makework. >

Re: Where to upload official OpenStack Debian images?

On 31 October 2014 08:39, Juerg Haefliger wrote: > > > On Wed, Oct 29, 2014 at 11:53 AM, Thomas Goirand wrote: >> >> On 10/29/2014 12:54 AM, Steve McIntyre wrote: >> > On Wed, Oct 22, 2014 at 03:58:04PM +0200, Juerg Haefliger wrote: >> >> Hi, >> >> >> >> On Sat, Jul 19, 2014 at 10:12 AM, Thomas G

Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)

On 29 October 2014 05:39, Guido Günther wrote: > On Tue, Oct 28, 2014 at 07:17:49PM +, Ian Jackson wrote: >> Brian May writes ("Re: Standardizing the layout of git packaging >> repositories"): >> > However, with git-dpm, no branch is ever destroyed. Every branch is always >> > merged into the

Re: Bug#762361: build-essential: Depends: make -> make-guile

On 24 October 2014 15:23, Matthias Klose wrote: > Control: tags -1 + wontfix moreinfo > > Am 21.09.2014 um 16:27 schrieb Martin-Éric Racine: >> Package: build-essential >> Version: 11.7 >> Severity: normal >> >> Given how 'make' has priority Optional, while 'make-guile' is Standard, >> build-essen

Re: post-jessie: header only C++ library package (static?)

Hello, On 18 October 2014 17:19, Osamu Aoki wrote: > Hi, > > This is about packaging around a header only C++ library package. > > As I understand, Debian does not usually ship static libraries based on > policy "8.3 Static libraries". At the same time, Debian does not impose > any systematic wa

Re: Tests running as (real) root?

On 11 October 2014 17:27, Svante Signell wrote: > Hello, > > I have a question about how to run tests for a package needing root to > run properly, fakeroot is not sufficient. I've made one of the packages > to build properly with: sudo run_test and fixed the sudoers file. But > how to fix that so

Re: dgit and upstream git repos [and 1 more messages]

On 9 October 2014 17:24, Ian Jackson wrote: > Dimitri John Ledkov writes ("Re: dgit and upstream git repos"): >> On 9 October 2014 15:38, Ian Jackson wrote: >> > If I can feed a .pc-less source tree to dpkg-source -b and get >> > roughtly the right outp

Re: dgit and upstream git repos

On 9 October 2014 15:49, Ian Jackson wrote: > Dimitri John Ledkov writes ("Re: dgit and upstream git repos"): >> $ apt-get source sword >> $ cd sword-* >> $ rm -rf .pc >> # a tree with up-to-date debian/patches, all patches are applied (as >> e.g. git

  1   2   >