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
>
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 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 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 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
在 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
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
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
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
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 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 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 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 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 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 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
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 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
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 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?
>
>
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
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, 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
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
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-
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
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
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
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
>> 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,
30 matches
Mail list logo