>> It just comes to my mind that Maybe it does not fit well with my convention
>> for exeprimental numbering whcih is
>> blablab_x.y.z-t~exp1
>> so maybe the best way would be to use
>> blalbla_x.y.z-t~~alba+1
>So, you would not use the "bpo9" part for the packages built for stretch?
Not at all,
Package: wnpp
Severity: wishlist
Owner: Liubov Chuprikova
* Package name: genometester
Version : 4.0
Upstream Author : University of Tartu
* URL : https://github.com/bioinfo-ut/GenomeTester4
* License : GPL-3+
Programming Lang: C
Description : toolkit f
GitLab is the right technology for us and a good improvement comparing to
Alioth.
I think it is great that we've chosen GitLab as successor to Alioth but how
would it make you feel if you were told that Salsa is not running on Debian?
That's how I feel... Specifically I'm concerned how GitLab i
I think it's a low blow to us.
I think this should have been known from the beginning. We need each of the
Debian projects, intervene the Debian itself.
Why don't start a new Debian project similar to GitLab, but based on Debian
OS.
Regards!
Emmanuel
El lun., 4 de jun. de 2018 a la(s) 07:47, Dm
Dmitry Smirnov writes ("concerns about Salsa"):
> Imagine my surprise when I've found that Salsa is not using our own
> GitLab package at all.
Salsa is hardly the first Debian production service to not be running
the packaged version of its primary application, and it won't be the
last. ftp.debia
Hi James,
On Sun, Jun 03, 2018 at 06:20:03PM +0100, James Cowgill wrote:
> Hi,
>
> On 03/06/18 16:08, Nicolas Braud-Santoni wrote:
> > X-Debbugs-CC: debian-devel@lists.debian.org
> >
> > Hi Debianites !
> >
> > On Tue, May 22, 2018 at 10:23:33AM +0200, Nicolas Braud-Santoni wrote:
> >> [libu2f-
On Mon, 04 Jun 2018, eamanu15 wrote:
> I think it's a low blow to us.
>
> I think this should have been known from the beginning. We need each of the
> Debian projects, intervene the Debian itself.
>
> Why don't start a new Debian project similar to GitLab, but based on Debian
> OS.
of course it
On Mon, 04 Jun 2018, Ian Jackson wrote:
> Dmitry Smirnov writes ("concerns about Salsa"):
> > Imagine my surprise when I've found that Salsa is not using our own
> > GitLab package at all.
>
> Salsa is hardly the first Debian production service to not be running
> the packaged version of its prim
El lun., 4 de jun. de 2018 a la(s) 09:08, Alexander Wirt <
formo...@debian.org> escribió:
> On Mon, 04 Jun 2018, eamanu15 wrote:
>
> > I think it's a low blow to us.
> >
> > I think this should have been known from the beginning. We need each of
> the
> > Debian projects, intervene the Debian itse
On Mon, 04 Jun 2018, eamanu15 wrote:
> El lun., 4 de jun. de 2018 a la(s) 09:08, Alexander Wirt <
> formo...@debian.org> escribió:
>
> > On Mon, 04 Jun 2018, eamanu15 wrote:
> >
> > > I think it's a low blow to us.
> > >
> > > I think this should have been known from the beginning. We need each o
On 06/04/2018 12:29 PM, Dmitry Smirnov wrote:
> GitLab is the right technology for us and a good improvement comparing to
> Alioth.
>
> I think it is great that we've chosen GitLab as successor to Alioth but how
> would it make you feel if you were told that Salsa is not running on Debian?
>
>
Hi Ian
On Mon, Jun 04, 2018 at 12:54:32PM +0100, Ian Jackson wrote:
> Salsa is hardly the first Debian production service to not be running
> the packaged version of its primary application, and it won't be the
> last. ftp.debian.org isn't running the packaged version of dak.
Running packaged ve
On Mon, 04 Jun 2018, Thomas Goirand wrote:
> On 06/04/2018 12:29 PM, Dmitry Smirnov wrote:
> > GitLab is the right technology for us and a good improvement comparing to
> > Alioth.
> >
> > I think it is great that we've chosen GitLab as successor to Alioth but how
> > would it make you feel if
Package: wnpp
Severity: wishlist
Owner: ro...@debian.org
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-svgpath
Version : 2.2.1
Upstream Author : Sergey Batishchev
* URL : https://github.com/fontello/svgpath#readme
* License : Expat
Programmi
On 6/3/18 7:20 PM, James Cowgill wrote:
> This can be done by running "udevadm trigger". By default every device
> on the system will be triggered which is a bit heavyweight, so you
> probably want to add some *match parameters to restrict this to the
> devices you're interested in (see the udevadm
On Mon, Jun 04, 2018 at 12:54:32PM +0100, Ian Jackson wrote:
> Salsa is hardly the first Debian production service to not be running
> the packaged version of its primary application, and it won't be the
> last. ftp.debian.org isn't running the packaged version of dak.
No, this has been happening
On 2018-06-04 21:52 +, Clint Adams wrote:
> On Mon, Jun 04, 2018 at 12:54:32PM +0100, Ian Jackson wrote:
> > Salsa is hardly the first Debian production service to not be running
> > the packaged version of its primary application, and it won't be the
> > last. ftp.debian.org isn't running the
On Monday, 4 June 2018 10:08:00 PM AEST Alexander Wirt wrote:
> It just doesn't packages - which were just not available at the
> time we needed them (the available package were several major versions
> behind).
IMHO it should have create enough incentive to (help) updating gitlab package
and the
On Monday, 4 June 2018 9:54:32 PM AEST Ian Jackson wrote:
> Salsa is hardly the first Debian production service to not be running
> the packaged version of its primary application, and it won't be the
> last. ftp.debian.org isn't running the packaged version of dak.
I think dak is quite different
On Jun 04, Philipp Kern wrote:
> Is this synchronous, or does one also need a call to "udevadm settle"? I
> had a problem with kpartx where the loop devices were not available
> after the package was installed, likely because of a race. I wonder if a
Yes, events in udev are asynchronous no matter
On Mon, Jun 4, 2018 at 6:29 PM, Dmitry Smirnov wrote:
> IMHO we should have been working on improving GitLab package in order to make
> is suitable for Salsa if it is not suitable already. What are the blockers?
In my opinion the biggest blocker is that, the node.js ecosystem is
not security supp
On Tue, Jun 5, 2018 at 9:05 AM, Dmitry Smirnov wrote:
> * dak is very internal to Debian project. We don't have to package it just
> for internal consumption.
dak is used by Debian derivatives (at least LiMux and Tanglu).
https://wiki.debian.org/Derivatives/CensusFull
--
bye,
pabs
https://wi
Hello all,
I want to read the DEPs [1] on dep.debian.net and find that
this site has forced HTTPS access with wrong certificate that
is only valid for *.pages.debian.net and pages.debian.net.
Could this issue be fixed recently?
Thanks,
Boyuan Yang
[1] https://wiki.debian.org/DEP
signature.as
Boyuan Yang <073p...@gmail.com> writes:
> I want to read the DEPs [1] on dep.debian.net and find that
> this site has forced HTTPS access with wrong certificate that
> is only valid for *.pages.debian.net and pages.debian.net.
> Could this issue be fixed recently?
It looks like you now want ht
在 2018年6月5日星期二 CST 上午11:39:49，Russ Allbery 写道：
> Boyuan Yang <073p...@gmail.com> writes:
> > I want to read the DEPs [1] on dep.debian.net and find that
> > this site has forced HTTPS access with wrong certificate that
> > is only valid for *.pages.debian.net and pages.debian.net.
> >
> > Could th
On Monday, 4 June 2018 11:25:41 PM AEST Alexander Wirt wrote:
> Please don't expect us to ever switch to packages - that will not happen.
That's an interesting statement. Why?
Do you think Praveen did all the enormous effort of packaging GitLab for
nothing? Do you reckon that packaging software
On Tue, 05 Jun 2018, Dmitry Smirnov wrote:
> On Monday, 4 June 2018 11:25:41 PM AEST Alexander Wirt wrote:
> > Please don't expect us to ever switch to packages - that will not happen.
>
> That's an interesting statement. Why?
>
> Do you think Praveen did all the enormous effort of packaging Git
On Tue, 05 Jun 2018, Dmitry Smirnov wrote:
> On Monday, 4 June 2018 10:08:00 PM AEST Alexander Wirt wrote:
> > It just doesn't packages - which were just not available at the
> > time we needed them (the available package were several major versions
> > behind).
>
> IMHO it should have create eno
On Tuesday, 5 June 2018 3:45:42 PM AEST Alexander Wirt wrote:
> We don't have root.
That actually makes sense... I didn't realize that Salsa is locked so tightly
that even you don't have root access... That makes things much harder than it
should be...
Do you think there will be a potential to
On Tue, 05 Jun 2018, Dmitry Smirnov wrote:
> On Tuesday, 5 June 2018 3:45:42 PM AEST Alexander Wirt wrote:
> > We don't have root.
>
> That actually makes sense... I didn't realize that Salsa is locked so tightly
> that even you don't have root access... That makes things much harder than it
>
30 matches
Mail list logo
