Bug#1100417: ITP: golang-github-adxgun-registry-auth -- a package to implement private docker registry token authentication server

Description : a package to implement private docker registry token authentication server registry-auth . a package to implements docker registry token authentication server as described here [https://github. com/docker/distribution/blob/1b9ab303a477ded9bdd3fc97e9119fa8f9e58fca/docs

Re: Private code: to forge, or not to forge?

On Wed Oct 16, 2024 at 1:18 PM -03, Iustin Pop wrote: > Hi all, this is offtopic (sorry!), but since we kept discussing Salsa - > I wonder, what are people doing for private code? ... > > What do people think? And thanks for reading. Hi Iustin, I use soft-serve and abuse Git hoo

Re: Private code: to forge, or not to forge?

On 2024-10-19 15:47:21, Thomas Hochstein wrote: > Iustin Pop wrote: > > > Gitea/Forgejo are common > > recommended solutions for "home hosting", but neither is packaged. > > Forgejo has unofficial Debian packages that work fine with bookworm, at > least. > >

Re: Private code: to forge, or not to forge?

Hi, On 20-10-2024 20:24, Iustin Pop wrote: I'm also glad to hear! Although, having read more, even the LTS version (of Forgejo) has a very short lifetime, not sure how this will play with Debian releases. Likely keeping sid up with LTS or most recent versions, and relying heavily on backports fo

Re: Private code: to forge, or not to forge?

On 2024-10-16 21:20:48, Jan-Benedict Glaw wrote: > On Wed, 2024-10-16 19:24:32 +0200, Daniel Baumann wrote: > > On 10/16/24 18:18, Iustin Pop wrote: > > > Gitea/Forgejo are common recommended solutions for "home hosting", but > > > neither is packaged. > > > > (jftr) I'm currently working with F

Re: Private code: to forge, or not to forge?

Iustin Pop wrote: > Gitea/Forgejo are common > recommended solutions for "home hosting", but neither is packaged. Forgejo has unofficial Debian packages that work fine with bookworm, at least.

Re: Private code: to forge, or not to forge?

On Wed, 2024-10-16 19:24:32 +0200, Daniel Baumann wrote: > On 10/16/24 18:18, Iustin Pop wrote: > > Gitea/Forgejo are common recommended solutions for "home hosting", but > > neither is packaged. > > (jftr) I'm currently working with Forgejo upstream to get one last > feature implemented that we

Re: Private code: to forge, or not to forge?

On 10/16/24 18:18, Iustin Pop wrote: > Gitea/Forgejo are common recommended solutions for "home hosting", but > neither is packaged. (jftr) I'm currently working with Forgejo upstream to get one last feature implemented that we'll need at work to switch to it, and then finish the packaging of it

Private code: to forge, or not to forge?

Hi all, this is offtopic (sorry!), but since we kept discussing Salsa - I wonder, what are people doing for private code? I have around 40 git repositories of private code that I keep, and while a subset of them are somewhat managed (living under a common `gitroot` directory), not all are. Plus

Re: Transparency into private keys of Debian

Hans-Christoph Steiner writes: >> In business, such things are confirmed (often badly) by independent >> audit. For a volunteer-driven community effort, we have to rely on >> everyone to exercise their best judgement in these sorts of matters. > > Debian could also get independent, professional a

Re: Transparency into private keys of Debian

On 2024-02-08 23:44:21 +0100 (+0100), Hans-Christoph Steiner wrote: > > In business, such things are confirmed (often badly) by independent > > audit. For a volunteer-driven community effort, we have to rely on > > everyone to exercise their best judgement in these sorts of matters. > > Debian cou

Re: Transparency into private keys of Debian

> In business, such things are confirmed (often badly) by independent > audit. For a volunteer-driven community effort, we have to rely on > everyone to exercise their best judgement in these sorts of matters. Debian could also get independent, professional audits. I think it would be a good

Re: Transparency into private keys of Debian

On 2/1/24 10:38, Simon Josefsson wrote: Hi I'm exploring how to defend against an attacker who can create valid signatures for cryptographic private keys (e.g., PGP) that users need to trust when using an operating system such as Debian. A signature like that can be used in a targetted at

Re: Transparency into private keys of Debian

> > there. > > > > If it is Iceland, then govs can easily find who to target. > > > > > > > > .hc > > > > > > > > > Hi > > > > > I'm exploring how to defend against an attacker who can > > > &g

Re: Transparency into private keys of Debian

though it is not the best > > > one > > > for our needs.  We'd of course love to move them to the best > > > jurisdiction but that is actually quite a bit of work, so we have > > > to > > > stay grounded in reality. > > > > >

Re: Transparency into private keys of Debian

d 4 are the steps for developers to upload > application packages as part of the > verification process by Google for the 'Play store' used in Android OS > devices. [...] This is already a standard practice for anyone using OpenPGP/GnuPG keys. I personally know no one who keeps the

Re: Transparency into private keys of Debian

of the people who control the keys. I think it is clear that publishing private key usage information is safe, like this key signed these things at these times. Publishing all the details about how the key was generated could help those who want to attack it more than those who rely on it. But that

Re: Transparency into private keys of Debian

keys signing each other (like CAs and leaf > certificates in X.509 PKI). PGP has subkeys and they could be used in > the release process to mitigate risks. > > Example: > 1. Debian creates a PGP key for releases. > 2. The public key is installed in Debian to verify releases. &

Re: Transparency into private keys of Debian

On 2024-02-05 08:58, Simon Josefsson wrote: What would be involved is to 1) during signing of artifacts, also sign and upload into Sigstore/Sigsum, and 2) during verification in the f-droid app, also verify that the signature has been committed to the Sigstore/Sigsum logs. Both projects have cli

Re: Transparency into private keys of Debian

and they could be used in the release process to mitigate risks. Example: 1. Debian creates a PGP key for releases. 2. The public key is installed in Debian to verify releases. 3. The release team creates subkeys for signing. 4. The main private key is stored in a restricted place. 5. The build

Re: Transparency into private keys of Debian

by the Debian APT keys, and want to explore ways to mitigate against those attacks. Understanding the private key lifecycle is one way to increase confidence in what the cost of those attacks are -- right now all we can say is that the cost of forging signatures for Debian APT keys is likely higher than

Re: Transparency into private keys of Debian

Code signing is not equal to code signing. There are a lot of differences between different code-signing strategies, many of which are often overlooked. Example: I. Typical Windows case 1. Third-party developer gets a key from a CA. 2. Third-party developer signs a program binary. 3. The user ob

Re: Transparency into private keys of Debian

exploring how to defend against an attacker who can create valid >> >> signatures for cryptographic private keys (e.g., PGP) that users need to >> >> trust when using an operating system such as Debian. A signature like >> >> that can be used in a targetted attac

Re: Transparency into private keys of Debian

On Mon, Feb 05, 2024 at 08:49:09AM +0100, Simon Josefsson wrote: > Bill Allombert writes: > > > Le Thu, Feb 01, 2024 at 10:38:03AM +0100, Simon Josefsson a écrit : > >> Hi > >> > >> I'm exploring how to defend against an attacker who can create val

Re: Transparency into private keys of Debian

> without putting a giant target on the heads of the people who control > the keys. I think it is clear that publishing private key usage > information is safe, like this key signed these things at these times. > Publishing all the details about how the key was generated could help >

Re: Transparency into private keys of Debian

Bill Allombert writes: > Le Thu, Feb 01, 2024 at 10:38:03AM +0100, Simon Josefsson a écrit : >> Hi >> >> I'm exploring how to defend against an attacker who can create valid >> signatures for cryptographic private keys (e.g., PGP) that users need to >> tru

Re: Transparency into private keys of Debian

Le Thu, Feb 01, 2024 at 10:38:03AM +0100, Simon Josefsson a écrit : > Hi > > I'm exploring how to defend against an attacker who can create valid > signatures for cryptographic private keys (e.g., PGP) that users need to > trust when using an operating system such as Debia

Re: Transparency into private keys of Debian

I think it is clear that publishing private key usage information is safe, like this key signed these things at these times. Publishing all the details about how the key was generated could help those who want to attack it more than those who rely on it. But that kind of information would be good to

Transparency into private keys of Debian

Hi I'm exploring how to defend against an attacker who can create valid signatures for cryptographic private keys (e.g., PGP) that users need to trust when using an operating system such as Debian. A signature like that can be used in a targetted attacks against one victim. For example

Bug#1037492: ITP: qt6-base-private-gles-dev -- This package contains the private header development files for building some Qt 6 applications like the Qt Creator QML Designer plugin.

Package: wnpp Severity: wishlist Owner: Leonardo Held X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : qt6-base-private-gles-dev Version : 6.4.2 Upstream Author : The Qt Company * URL : https://www.qt.io/developers/ * License : LGPL-3, GPL-2, GFDL-NIV-1.3, GPL-3 with Qt-1.0

Bug#1036924: ITP: obfuscate -- Censor private information from images

Contact: Bilal Elmoussaoui * URL : https://apps.gnome.org/app/com.belmoussaoui.Obfuscate/ * License : GPL-3+ Programming Lang: Rust Description : Censor private information from images I intend to package obfuscate. It's a neat little program to censor pr

Bug#1023102: ITP: golang-github-caarlos0-sshmarshal -- easily marshal SSH private keys

Description : Code copied from x/crypto and golang/go#37132 Library containing code copied from x/crypto (https://github.com/golang/crypto) and this patch (https://go- review.googlesource.com/c/crypto/+/218620/) so we can more easily marshal SSH private keys. Build-depend for newer versions of

Bug#1004404: ITP: cvdupdate -- ClamAV Private Database Mirror Updater Tool

: ClamAV Private Database Mirror Updater Tool cvdupdate downloads the latest ClamAV databases along with the latest database patch files. . Run this tool as often as you like, but it will only download new content if there is new content to download. If you somehow manage to download too

Bug#990946: ITP: step-ca -- private certificate authority

Package: wnpp Severity: wishlist Owner: Peymaneh Nejad * Package name: step-ca Version : 0.16.0 Upstream Author : Smallstep * URL : https://github.com/smallstep/certificates * License : Apache-2.0 Programming Lang: Go Description : private certificate

Bug#980286: RFP: signald -- A daemon that facilitates communication via Signal Private Messenger

Programming Lang: Java Description : A daemon that facilitates communication via Signal Private Messenger signald is needed for mautrix-signal, the Matrix to Signal bridge, which I intend to package. -BEGIN PGP SIGNATURE- iQJ+BAEBCgBoFiEEPJ1UpHV1wCb7F

Bug#948586: ITP: golang-github-youmark-pkcs8 -- Go package to parse and convert private keys in PKCS#8 format, as defined in RFC5208 and RFC5958

package to parse and convert private keys in PKCS#8 format, as defined in RFC5208 and RFC5958 OpenSSL can generate private keys in both "traditional format" and PKCS#8 format. Newer applications are advised to use more secure PKCS#8 format. Go standard crypto package provides a function to par

Bug#939465: ITP: python-virustotal-api -- Virus Total Public/Private/Intel API for Python

: Python Description : Virus Total Public/Private/Intel API for Python This package contains Python 3 API bindings for VirusTotal's public, private and intelligence APIs. The VirusTotal API lets you upload and scan files or URLs, access finished scan reports and make automatic comments withou

Bug#888115: ITP: git-secret -- store encrypted private data inside a git repository

encrypted private data inside a git repository git-secret is a bash tool to store your private data inside a git repo. How’s that? Basically, it just encrypts, using gpg, the tracked files with the public keys of all the users that you trust. -- ChangZhuo Chen (陳昌倬) czchen@{czchen,debconf,debian}.org

Virtual Private Network (VPN) Leads

Hello, I realize that we haven't had any past contact, yet I'm connecting with enlighten you concerning our new Virtual Private Network (VPN) Clients' records. We do have different advancements like: ExpressVPN, Purevpn, NordVPN, SAFERVPN, ZenMate, Avira Phantom, Norton, IP

Bug#875849: ITP: r-cran-pkgconfig -- Private Configuration for 'R' Packages

Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-pkgconfig Version : 2.0.1 Upstream Author : Gábor Csárdi * URL : https://cran.r-project.org/package=pkgconfig * License : MIT Programming Lang: GNU R Description : Private

Bug#867521: ITP: golang-github-mikesmitty-edkey -- edkey allows you to write ED25519 private keys in the OpenSSH private key format

g: Go Description : edkey allows you to write ED25519 private keys in the OpenSSH private key format edkey edkey allows you to marshal/write ED25519 private keys in the OpenSSH private key format.

Re: Find all consumers of private symbols

and > > > internal > > > symbols for their plugins libraries. Sadly the internal symbols > > > are > > > exposed in libibverbs. Upstream wants to make these symbols > > > private, > > > but without bumping the soname. > > > > > >

Re: Find all consumers of private symbols

e > > exposed in libibverbs. Upstream wants to make these symbols private, > > but without bumping the soname. > > > > The rdma-core source package will ship libibverbs and all library > > plugins. So this source package can ensure that no incompatible > >

Re: Find all consumers of private symbols

Am 31.01.2017 um 13:31 schrieb Benjamin Drung: > Hi, > > libibverbs provides symbols for their public library API and internal > symbols for their plugins libraries. Sadly the internal symbols are > exposed in libibverbs. Upstream wants to make these symbols private, > but w

Find all consumers of private symbols

Hi, libibverbs provides symbols for their public library API and internal symbols for their plugins libraries. Sadly the internal symbols are exposed in libibverbs. Upstream wants to make these symbols private, but without bumping the soname. The rdma-core source package will ship libibverbs and

Bug#850672: ITP: gnome-shell-extension-show-ip -- Shows the urrent private or public IP address in the GNOME Shell status drop-down menu

: Javascript Description : A GNOME Shell Extesion that shows the urrent private or public IP address in the status drop-down menu Show-IP is a GNOME Shell extension that shows the current private or public IP address. It allows the user to set whcih device to display if there are

Bug#850237: ITP: node-private -- Utility for associating truly private state with any JavaScript object

Package: wnpp Severity: wishlist Owner: Ameya Apte X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-private Version : 0.1.6 Upstream Author : Ben Newman * URL : http://github.com/benjamn/private * License : Expat Programming Lang: JavaScript

Results for Declassifying debian-private

, Devotee (on behalf of Debian Project Secretary) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Starting results calculation at Sun Oct 23 00:00:04 2016 Option 1 "Repeal previous GR" Option 2 "Acknowledge difficulty" Option 3 "Remain private" Option 4 "Further Discuss

Re: GR: Declassifying debian-private: First call for votes

- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- d495b767-7754-4e61-80ea-8b31c07f3595 [ 2 ] Choice 1: Repeal previous GR [ 1 ] Choice 2: Acknowledge difficulty [ 4 ] Choice 3: Remain private [ 3 ] Choice 4: Further Discussion - - -=-=-=-=-=- Don't Delete Anythi

Results for Declassifying debian-private

, Devotee (on behalf of Debian Project Secretary) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Starting results calculation at Sun Aug 21 00:00:12 2016 Option 1 "Allow declassifying parts of debian-private" Option 2 "Further Discussion" In the following table, tally[row x][col y]

Re: Results for Declassifying debian-private

Please ignore this e-mail. It never happened. Kurt

Results for Declassifying debian-private

, Devotee (on behalf of Debian Project Secretary) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Starting results calculation at Sun Aug 14 00:00:23 2016 Option 1 "Allow declassifying parts of debian-private" Option 2 "Further Discussion" In the following table, tally[row x][col y]

howto move threads away from -private@ (was: CLASSIFIED)

On Tue, Aug 09, 2016 at 12:52:33PM -0700, Steve Langasek wrote: > Nothing I've written here is private. You may quote me on a public mailing > list, but not on debian-private ;) LOL that's a really good one, to be repeated many times. thanks! :) (originally intended to send p

Re: GR: Declassifying debian-private: First call for votes

On Sun, 2016-08-07 at 01:48 +0200, Debian Project Secretary - Kurt Roeckx wrote: > Hi, > > This is the first call for vote on the General Resolution about > declassifying debian-private. > >  Voting period starts  2016-08-07 00:00:00 UTC >  Votes must be receive

Bug#779137: ITP: liblexical-accessor-perl -- true private attributes for Moose/Moo/Mouse

: Artistic or GPL-1+ Programming Lang: Perl Description : true private attributes for Moose/Moo/Mouse Lexical::Accessor generates coderefs which can be used as methods to access private attributes for objects. . The private attributes are stored inside-out, and do not add any accessors

Re: Again ask for a mentor who can help me by private mail

On Tue, Feb 4, 2014 at 1:35 AM, Roelof Wobben wrote: > Again ask for a mentor who can help me by private mail I would strongly suggest *not* doing things in private. In Debian we do as much as possible in public and this includes mentoring. If you have any questions, ask them on the deb

Re: FW: Again ask for a mentor who can help me by private mail

You may have better luck on debian-mentors (but I echo what others are saying… it sounds like your mentor is not behaving in the spirit of open source software) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.de

Re: FW: Again ask for a mentor who can help me by private mail

On Mon, Feb 03, 2014 at 07:56:57PM +0100, Arno Töll wrote: > If so, not you should be hit with the holy hammer of clue, but your mentor. Uh, yeah. What the hell? Who is this guy (Eribo) and why does not think it's not OK for you to take freely licensed code and use it in-line with their licensing?

Re: FW: Again ask for a mentor who can help me by private mail

Hi Roelof, On 03.02.2014 19:51, Roelof Wobben wrote: > But because I copied a few things from a package he maintains he wants to > stop mentoring me. This was a really really stupid thing to do and it will > never happen again do I understand it correct, that your (former) mentor stopped mentorin

FW: Again ask for a mentor who can help me by private mail

Hello, A few days ago I ask here for a mentor who can help me with becoming a Debian Maintainer. Eribo has volunteered me where I thank him a lot. But because I copied a few things from a package he maintains he wants to stop mentoring me. This was a really really stupid thing to do and it will ne

Re: Bug severity and private data disclosure

On Mon, Jun 10, 2013 at 08:10:22PM +0600, Andrey Rahmatullin wrote: > Life for the maintainer or for the user? Well, the severity of a bug, from a user POV, makes no guarantee on how serious the maintainer takes it, nor whether they will actually fix it. Admittely some users get comfort from being

Re: Bug severity and private data disclosure

On 2013-06-10 23:28:28 +0600, Andrey Rahmatullin wrote: > On Mon, Jun 10, 2013 at 04:15:27PM +0200, Vincent Lefevre wrote: > > This is important for apt-listbugs, which takes into account RC bugs by > > default > Which too is not ideal: for example, I don't think users should care about > such RC

Re: Filtering bugs from apt-listbugs reports (was Re: Bug severity and private data disclosure)

On Mon, Jun 10, 2013 at 02:40:17PM -0400, James McCoy wrote: > > > > It's amazing how much simpler Debian life becomes if one simply > ignores > > > > bug severities entirely. Of course harder to do nearer to release, but > > > > we live in a time of relative luxury right now… > > > > > > This is i

Filtering bugs from apt-listbugs reports (was Re: Bug severity and private data disclosure)

On Jun 10, 2013 1:28 PM, "Andrey Rahmatullin" wrote: > > On Mon, Jun 10, 2013 at 04:15:27PM +0200, Vincent Lefevre wrote: > > > It's amazing how much simpler Debian life becomes if one simply ignores > > > bug severities entirely. Of course harder to do nearer to release, but > > > we live in a ti

Re: Bug severity and private data disclosure

On Mon, Jun 10, 2013 at 04:15:27PM +0200, Vincent Lefevre wrote: > > It's amazing how much simpler Debian life becomes if one simply ignores > > bug severities entirely. Of course harder to do nearer to release, but > > we live in a time of relative luxury right now… > > This is important for apt-

Re: Bug severity and private data disclosure

Vincent Lefevre writes ("Re: Bug severity and private data disclosure"): > Note that this is a regression. Using the testing version (= stable > currently) is fine w.r.t. this bug. Oh, I see. In that case I agree with you. Have you asked the release team ? They are the right

Re: Bug severity and private data disclosure

On 2013-06-10 17:16:12 +0200, Cyril Brulebois wrote: > Since you seem concerned about apt-listbugs, make it support listing > security bugs (optionally with a given severity threshold, so as to > ignore minor or normal bug reports tagged security), and there you go. > > [ From a quick look at the

Re: Bug severity and private data disclosure

Vincent Lefevre (10/06/2013): > I reported a bug involving private data disclosure, more precisely, > on some network, when printing a file with CUPS 1.6, the file is > printed on a wrong printer[*]. The bug severity was downgraded to > important (i.e. non-RC), despite the obvi

Re: Bug severity and private data disclosure

Hi Ian, Le lundi, 10 juin 2013 16.11:26, Ian Jackson a écrit : > (I have CC'd cups-client@packages.) (I'd prefer the discussion to happen on the bug.) > I'm not sure exactly what consequences you think should have flowed > from the bug's RC severity. Do you think the release should have been >

Re: Bug severity and private data disclosure

On 2013-06-10 15:11:26 +0100, Ian Jackson wrote: > I agree with you that that bug is a potential security vulnerability. > I think the maintainer adopted an overly-close and legalistic reading > of the bug severity guidelines. On the other hand I think the > maintainer makes good points about the

Re: Bug severity and private data disclosure

On 2013-06-10 15:05:05 +0100, Jonathan Dowland wrote: > It's amazing how much simpler Debian life becomes if one simply ignores > bug severities entirely. Of course harder to do nearer to release, but > we live in a time of relative luxury right now… This is important for apt-listbugs, which takes

Re: Bug severity and private data disclosure

(I have CC'd cups-client@packages.) Vincent Lefevre writes ("Bug severity and private data disclosure"): > I reported a bug involving private data disclosure, more precisely, > on some network, when printing a file with CUPS 1.6, the file is > printed on a wrong printer[

Re: Bug severity and private data disclosure

On Mon, Jun 10, 2013 at 03:05:05PM +0100, Jonathan Dowland wrote: > It's amazing how much simpler Debian life becomes if one simply ignores > bug severities entirely. Life for the maintainer or for the user? -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a

Re: Bug severity and private data disclosure

It's amazing how much simpler Debian life becomes if one simply ignores bug severities entirely. Of course harder to do nearer to release, but we live in a time of relative luxury right now… -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Troubl

Re: Bug severity and private data disclosure

On Mon, Jun 10, 2013 at 1:15 PM, Vincent Lefevre wrote: > I reported a bug involving private data disclosure, more precisely, > on some network, when printing a file with CUPS 1.6, the file is > printed on a wrong printer[*]. The bug severity was downgraded to > important (i.e. non-

Bug severity and private data disclosure

I reported a bug involving private data disclosure, more precisely, on some network, when printing a file with CUPS 1.6, the file is printed on a wrong printer[*]. The bug severity was downgraded to important (i.e. non-RC), despite the obvious security problem. The given reason was that this kind

Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo

On 04/18/2011 08:47 PM, Steve Langasek wrote: > On Tue, Apr 19, 2011 at 02:14:27AM +0800, Thomas Goirand wrote: >> On 04/18/2011 03:03 PM, Soren Hansen wrote: >>> Making the package lintian [clean] is a great goal! > >> It's not a goal, it's a requirement for any DD before uploading to the >> arch

Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo

2011/4/18 Thomas Goirand : > As for the fact that you had to release it with a schedule date, I > *guessed* it myself. Only, saying it explicitly would have helped > communication. Sorry, I don't understand what you're saying here. >> "most" being the operative word. You've proposed a bunch of ch

Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo

On Tue, Apr 19, 2011 at 02:14:27AM +0800, Thomas Goirand wrote: > On 04/18/2011 03:03 PM, Soren Hansen wrote: > > Making the package lintian [clean] is a great goal! > It's not a goal, it's a requirement for any DD before uploading to the > archive. No, it's not. -- Steve Langasek

Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo

e work we put into the packages. I'd appreciate if you tried not to take anything as personal attacks. I will try even harder to only write about technical things only. I *have* to stick with the Debian policy. My point isn't to do "lecturing on Debian policy", but to explain what I'

Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo

On 04/17/2011 01:05 PM, Charles Plessy wrote: > Le Sat, Apr 16, 2011 at 10:43:43AM +0800, Thomas Goirand a écrit : >> >> Again, if other DDs want to participate to this packaging effort, you'd >> be welcome. Especially, it seems that the current version of euca tools >> are broken (uec-publish-tarb

Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo

clean (the Ubuntu package, really, is not), and > I have done loads of patches to have the package to fit in Debian, > comply with the policy, and be lintian clean ..along with your above mentioned lecturing on Debian Policy, I feel you're degrading the work we put into the packa

Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo

2011/4/18 Clint Adams : > On Sun, Apr 17, 2011 at 11:29:07PM +0200, Soren Hansen wrote: >> This, even more than your constant lecturing on Debian policy, frankly >> pisses me off. >> >> If you have something to say, at the very least have the guts to say >> it in public, otherwise this collaboratio

Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo

On 04/18/2011 05:29 AM, Soren Hansen wrote: > 2011/4/16 Thomas Goirand : >> On 04/16/2011 01:32 PM, Lucas Nussbaum wrote: >>> On 16/04/11 at 10:43 +0800, Thomas Goirand wrote: >>> What the state of collaboration with the upstream packagers? >> Replied more extensively privately to that one. > > Th

Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo

On Sun, Apr 17, 2011 at 11:29:07PM +0200, Soren Hansen wrote: > This, even more than your constant lecturing on Debian policy, frankly > pisses me off. > > If you have something to say, at the very least have the guts to say > it in public, otherwise this collaboration ends right here. I find it

Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo

2011/4/16 Thomas Goirand : > On 04/16/2011 01:32 PM, Lucas Nussbaum wrote: >> On 16/04/11 at 10:43 +0800, Thomas Goirand wrote: >> What the state of collaboration with the upstream packagers? > Replied more extensively privately to that one. This, even more than your constant lecturing on Debian p

Re: Bug#620018: Openstack Compute nova, Cactus release, Squeeze built available in our private repo

- Original message - > Le Sat, Apr 16, 2011 at 10:43:43AM +0800, Thomas Goirand a écrit : > > > > Again, if other DDs want to participate to this packaging effort, you'd > > be welcome. Especially, it seems that the current version of euca tools > > are broken (uec-publish-tarball got me

Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo

Le Sat, Apr 16, 2011 at 10:43:43AM +0800, Thomas Goirand a écrit : > > Again, if other DDs want to participate to this packaging effort, you'd > be welcome. Especially, it seems that the current version of euca tools > are broken (uec-publish-tarball got me stuck on my work for a week), and > woul

Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo

On 04/16/2011 01:32 PM, Lucas Nussbaum wrote: > On 16/04/11 at 10:43 +0800, Thomas Goirand wrote: >> Hi, >> >> This is a short email to let everyone know about the current status of >> the package. >> >> Cactus, the first serious release of Openstack Compute - nova, has been >> released yesterday.

Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo

On 16/04/11 at 10:43 +0800, Thomas Goirand wrote: > Hi, > > This is a short email to let everyone know about the current status of > the package. > > Cactus, the first serious release of Openstack Compute - nova, has been > released yesterday. I have done loads of patches to have the package to >

Openstack Compute nova, Cactus release, Squeeze built available in our private repo

Hi, This is a short email to let everyone know about the current status of the package. Cactus, the first serious release of Openstack Compute - nova, has been released yesterday. I have done loads of patches to have the package to fit in Debian, comply with the policy, and be lintian clean. The

Re: Private-only debconf templates for preseeding

Quoting Frans Pop (elen...@planet.nl): > IMO the use you describe can be valid in particular cases. > > One example would be when the setting is intended to only influence > behavior of the maintainer scripts during installation of the package as > part of system installation using Debian Insta

Re: Private-only debconf templates for preseeding

Russ Allbery wrote: > My initial reaction was that anything that's worth making available for > configuration via preseeding is worth a low-priority debconf prompt, and > that having preseeding be the only interface is a weird way to use > debconf. IMO the use you describe can be valid in particul

Re: Private-only debconf templates for preseeding

On Sun, Jan 11, 2009 at 07:25:03PM -0800, Russ Allbery wrote: > Hello everyone, > The background for this question is Lintian Bug#492626. > There are several packages in the archive that use private debconf > templates where the only interface to them is preseeding. Examples &

Private-only debconf templates for preseeding

Hello everyone, The background for this question is Lintian Bug#492626. There are several packages in the archive that use private debconf templates where the only interface to them is preseeding. Examples include the readahead package (where the preseed was added for Debian Edu) and

Bug#495418: ITP: RSAKeyFinder -- A tool for locating RSA private and public keys.

Package: wnpp Severity: wishlist Owner: Debian Forensics <[EMAIL PROTECTED]> * Package name: RSAKeyFinder Version : 1.0.0 * URL : http://citp.princeton.edu/memory/code/ * License : BSD Programming Lang: C++ Description : A tool for locating RSA p

Re: dpkg-shlibdeps and private libraries

${ARB_HOME}/lib > > FWIW, I don't agree that this is a fix. In one sense it makes /usr/lib > > "cleaner" by moving private libs into a private directory; however: > > - Because Debian uses ldconfig, the runtime cost of having additional > > librarie

Re: dpkg-shlibdeps and private libraries

On Sat, Nov 17, 2007 at 04:24:18PM +, Ian Jackson wrote: > Steve Langasek writes ("Re: dpkg-shlibdeps and private libraries"): > > On Tue, Nov 06, 2007 at 08:51:05AM +0100, Andreas Tille wrote: > > FWIW, I don't agree that this is a fix. In one sense it makes /u

Re: dpkg-shlibdeps and private libraries

Steve Langasek writes ("Re: dpkg-shlibdeps and private libraries"): > On Tue, Nov 06, 2007 at 08:51:05AM +0100, Andreas Tille wrote: > FWIW, I don't agree that this is a fix. In one sense it makes /usr/lib > "cleaner" by moving private libs into a private dire

Re: dpkg-shlibdeps and private libraries

On Tue, 13 Nov 2007, Steve Langasek wrote: FWIW, I don't agree that this is a fix. In one sense it makes /usr/lib "cleaner" by moving private libs into a private directory; however: Well, I'm perfectly willing to adopt your suggestions, but I have to admit that the auth

  1   2   3   >