Re: concerns about Salsa

[Alexander Wirt]

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 
> should be...
> 
> Do you think there will be a potential to move services to containers, 
> probably on "rkt" runtime[*] ?
No idea, managing the hosts itself is DSA area. 

Alex



signature.asc
Description: PGP signature

Re: concerns about Salsa

[Dmitry Smirnov]

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 move services to containers, 
probably on "rkt" runtime[*] ?

Thanks.

[*]: Because Docker sucks...

-- 
All the best,
 Dmitry Smirnov.

---

Belief means not wanting to know what is true.
-- Friedrich Nietzsche


signature.asc
Description: This is a digitally signed message part.

Re: concerns about Salsa

[Alexander Wirt]

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 enough incentive to (help) updating gitlab package 
> and then use it.
> To me it was perfectly OK to use older GitLab up until newer package became 
> available...
Your choice, I prefer recent versions without security problems. 

Alex



signature.asc
Description: PGP signature

Re: concerns about Salsa

[Alexander Wirt]

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 GitLab for 
> nothing? Do you reckon that packaging software adds no value?
The effort is not for us. Do you think we did all the effort for a proper
administration for nothing? 

> 
> I understand trade-off between stability of a package versus convenient 
> volatility of git repository that you can patch at your own discretion.
> Yet I think that official Debian service ideally should be based on official 
> Debian package and that service administrators should be working together 
> with package maintainers, helping each other.
> 
> It is not viable to install everything from git. So how would you chose when 
> to use packages and when to use git?
> 
> What about "gitaly"? This particular component of GitLab is written in Golang 
> and it needs to be built from source. Why do you compile "gitaly" from source 
> Gentoo-style instead of using properly built Debian package?
Because we want to react fast, without dsa. We don't have root. 
> 
> What makes Salsa so special to say that using properly packaged components 
> from "main" is inappropriate?
Its not special, most services are run like that.

> "This will not happen" is a strong statement. Is packaging software for 
> Debian so hopeless that there is nothing GitLab maintainers could ever do to 
> make you change your mind and embrace work of fellow Debian developers?
Unless the ways services are run on DSA managed hosts changes, we will not
move to packages. 

Alex


signature.asc
Description: PGP signature

Re: concerns about Salsa

[Dmitry Smirnov]

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 adds no value?

I understand trade-off between stability of a package versus convenient 
volatility of git repository that you can patch at your own discretion.
Yet I think that official Debian service ideally should be based on official 
Debian package and that service administrators should be working together 
with package maintainers, helping each other.

It is not viable to install everything from git. So how would you chose when 
to use packages and when to use git?

What about "gitaly"? This particular component of GitLab is written in Golang 
and it needs to be built from source. Why do you compile "gitaly" from source 
Gentoo-style instead of using properly built Debian package?

What makes Salsa so special to say that using properly packaged components 
from "main" is inappropriate?

"This will not happen" is a strong statement. Is packaging software for 
Debian so hopeless that there is nothing GitLab maintainers could ever do to 
make you change your mind and embrace work of fellow Debian developers?

-- 
Cheers,
 Dmitry Smirnov.

---

Our difficulties and our dangers will not be removed by closing our eyes on
them.
-- Winston Churchill


signature.asc
Description: This is a digitally signed message part.

Re: dep.debian.net unavailable now (force HTTPS with wrong cert?)

[Boyuan Yang]

在 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 this issue be fixed recently?
> 
> It looks like you now want https://dep-team.pages.debian.net/ (probably
> because the repository migrated to Salsa).

Thanks for the quick answer. However I believe it's worthwhile to restore the 
dep.debian.net access since it is referenced all around the net.

--
Regards,
Boyuan Yang

signature.asc
Description: This is a digitally signed message part.

Re: dep.debian.net unavailable now (force HTTPS with wrong cert?)

[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 this issue be fixed recently?

It looks like you now want https://dep-team.pages.debian.net/ (probably
because the repository migrated to Salsa).

-- 
Russ Allbery (r...@debian.org)   

dep.debian.net unavailable now (force HTTPS with wrong cert?)

[Boyuan Yang]

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.asc
Description: This is a digitally signed message part.

Re: concerns about Salsa

[Paul Wise]

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://wiki.debian.org/PaulWise

Re: concerns about Salsa

[Paul Wise]

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 supported by Debian because of libv8 not being security
supported. In addition, there is no-one in Debian tracking
vulnerabilities in the node.js ecosystem reported by NodeSecurity and
importing the issues into the Debian security tracker. I used to do
this occasionally to see how many issues we were ignoring but it needs
to be done in a systematic way by people interested in JavaScript
security. The biggest problem with this is that a lot of NodeSecurity
reported issues do not get a CVE, this seems to be improving though.
After that, the ones that did get a CVE were either still reserved
with no info or in 'check' mode and needed to be classed as not-for-us
or applying to a certain Debian package.

https://nodesecurity.io/advisories

I have no idea how that compares with the security support provided by
GitLab upstream though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#899299: libu2f-udev: Post-inst script should make udev reload rules

[Marco d'Itri]

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 the origin (kernel or 
udevadm).

> feature request would make sense to integrate udev with debhelper so
> that the correct snippet could be generated for various packages'
> postinsts instead of everyone who ships a rules file hand-rolling it. Of
> course if people actually need to write complicated rules to select the
> rules to re-trigger, that seems much more difficult to do...
Indeed.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: concerns about Salsa

[Dmitry Smirnov]

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 in two ways:

 * dak is very internal to Debian project. We don't have to package it just 
for internal consumption.

 * gitlab was already packaged. If we package it for everybody then we should 
be able to use it as well.


> In practice, I have found that it is much easier to deploy a
> production service directly from its git tree.  This makes it much
> easier to make changes.

Interesting. I tend to deploy packages and use whatever problems I experience 
as incentive to update packaging. "Fix it for yourself and for everyone else" 
kind of thing is a powerful concept although not always the fastest...

-- 
Cheers,
 Dmitry Smirnov.

---

Do your duty as you see it, and damn the consequences.
-- George S. Patton


signature.asc
Description: This is a digitally signed message part.

Re: concerns about Salsa

[Dmitry Smirnov]

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 then use it.
To me it was perfectly OK to use older GitLab up until newer package became 
available...

-- 
Best wishes,
 Dmitry Smirnov.

---

Perhaps is is better to be irresponsible and right, than to be responsible
and wrong.
-- Winston Churchill


signature.asc
Description: This is a digitally signed message part.

Re: concerns about Salsa

[Wookey]

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 packaged version of dak.
> 
> No, this has been happening forever, and this failure to dogfood has
> also been a disservice to our users forever.

Buildds don't run the packaged version either, and this contributes to
it being much harder than it should be to set up local buildd
infrastructure. There are good reasons for this from the admin's POV,
but the side-effects are signifcant and I'd like us to try harder to
use packaged stuff.

But I've not done the necessary work myself, so can't really
complain. I just observe that it is a real issue for people setting up
their own CI infra. One day I may have the tuits to improve things in
this area (I plan to start retiring soon, which might help, or may
simply introduce different distractions :-)
 
Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: concerns about Salsa

[Clint Adams]

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 forever, and this failure to dogfood has
also been a disservice to our users forever.

Re: Bug#899299: libu2f-udev: Post-inst script should make udev reload rules

[Philipp Kern]

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 man page).

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
feature request would make sense to integrate udev with debhelper so
that the correct snippet could be generated for various packages'
postinsts instead of everyone who ships a rules file hand-rolling it. Of
course if people actually need to write complicated rules to select the
rules to re-trigger, that seems much more difficult to do...

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Bug#900770: ITP: node-svgpath -- Low level transforms on svg path element

[Bastien ROUCARIES]

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
  Programming Lang: JavaScript
  Description :
This package implements transform attribute on SVG file path element
 directly using JavaScript.
 .
 This package is useful for static computation of path or when you want
 to keep browser load minimal.
 .
 The transform attribute of a SVG file defines a list of transform
 definitions that are applied to an element and the element's children.
 The items in the transform list are separated by whitespace and/or commas,
 and are applied from right to left.
 .
 Scalable Vector Graphics (SVG) is an XML-based vector image format for
 two-dimensional graphics with support for interactivity and animation.
 .
 Node.js is an event-based server-side JavaScript engine.

Re: concerns about Salsa

[Alexander Wirt]

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 you were told that Salsa is not running on Debian?
> > 
> > That's how I feel... Specifically I'm concerned how GitLab is installed on 
> > Salsa.
> 
> Hi Dmitry,
> 
> I very much share your feeling, though there's one major blocker atm:
> the NEW queue. Pirate Praveen uploaded lots of node packages which are
> needed for gitlab, and it's still waiting for approval. Until that's
> done, then there wont be any up-to-date Gitlab package in Debian. And
> really, version 10.x is so much nicer than 8.x. Of course, not having
> 12.x in Unstable prevents it from having an official Stretch backport...
> 
> At the same time, I have sympathy for both the FTP masters: that's A LOT
> of packages to review, and the Salsa admins: when they've set the Salsa
> service online, there wasn't all of this packaging available, and they
> needed it ASAP.
> 
> Let's just hope that all of this goes fast in the right direction so
> that the situation is fixed.
Please don't expect us to ever switch to packages - that will not happen. 

Alex

Re: concerns about Salsa

[Bastian Blank]

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 versions also means that only the system admins can
actually update the code.  However they don't want to run the services.
Until we have user-installable packages, this won't change.

> However, I hope it's not running vendor-provided binaries.  That would
> be quite poor IMO and a big departure from our normal practice.  Are
> you sure that that is the case ?

GitLab and all the associated stuff is pulled from git repositories and
built on the system.  However, we actually pull in some external
binaries, for node, yarn and go.

You can find out how everything is done in our repository with Ansible
stuff at https://salsa.debian.org/salsa/salsa-ansible.  If you know a
better way to do something, just send patches the usual way.

Regards,
Bastian

-- 
Schshschshchsch.
-- The Gorn, "Arena", stardate 3046.2

Re: concerns about Salsa

[Thomas Goirand]

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?
> 
> That's how I feel... Specifically I'm concerned how GitLab is installed on 
> Salsa.

Hi Dmitry,

I very much share your feeling, though there's one major blocker atm:
the NEW queue. Pirate Praveen uploaded lots of node packages which are
needed for gitlab, and it's still waiting for approval. Until that's
done, then there wont be any up-to-date Gitlab package in Debian. And
really, version 10.x is so much nicer than 8.x. Of course, not having
12.x in Unstable prevents it from having an official Stretch backport...

At the same time, I have sympathy for both the FTP masters: that's A LOT
of packages to review, and the Salsa admins: when they've set the Salsa
service online, there wasn't all of this packaging available, and they
needed it ASAP.

Let's just hope that all of this goes fast in the right direction so
that the situation is fixed.

Cheers,

Thomas Goirand (zigo)

Re: concerns about Salsa

[Alexander Wirt]

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 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 was all known and announced in advance and it is running on
> > debian. It just doesn't packages - which were just not available at the
> > time
> > we needed them (the available package were several major versions behind).
> >
> 
> Ah ok, So Salsa is running on a Debian server?
Of course.

Alex

Re: concerns about Salsa

[eamanu15]

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 itself.
> >
> > Why don't start a new Debian project similar to GitLab, but based on
> Debian
> > OS.
> of course it was all known and announced in advance and it is running on
> debian. It just doesn't packages - which were just not available at the
> time
> we needed them (the available package were several major versions behind).
>

Ah ok, So Salsa is running on a Debian server?

Alex
>
-- 
Arias Emmanuel
https://www.linkedin.com/in/emmanuel-arias-437a6a8a
http://eamanu.com

Re: concerns about Salsa

[Alexander Wirt]

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 primary application, and it won't be the
> last.  ftp.debian.org isn't running the packaged version of dak.
> 
> Even my own git.dgit.d.o isn't running the packaged version of
> dgit-infrastructure; it executes out of a git clone.  (I took the
> trouble to implement `dgit clone-dgit-repos-server' and the
> corresponding server end so make sure that the source code for the
> server is always public.)
> 
> > I would understand if there were no choice but Salsa admins clearly
> > chosen to discard GitLab package in favor of vendor binaries
> 
> However, I hope it's not running vendor-provided binaries.  That would
> be quite poor IMO and a big departure from our normal practice.  Are
> you sure that that is the case ?
We use git. 
https://salsa.debian.org/salsa/ansible


Alex

Re: concerns about Salsa

[Alexander Wirt]

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 was all known and announced in advance and it is running on
debian. It just doesn't packages - which were just not available at the time
we needed them (the available package were several major versions behind). 

Alex

Re: Bug#899299: libu2f-udev: Post-inst script should make udev reload rules

[Nicolas Braud-Santoni]

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-udev's post-inst script should make udev reload rules.]
> >> Otherwise, the rules are not active until the next reboot (or until the 
> >> user
> >> manually calls `udevadm control -R`).
> > 
> > To fix this bug, I need to call `udevadm` from the postinstall script,
> > meaning that libu2f-udev needs to Pre-Depends on udev.
> 
> Running a command from another package in postinst only requires a
> normal Depends - not a Pre-Depends.

OK.  I had assumed calling udevadm before udev was configured was wrong,
thanks for the clarification.


> However, I don't think you need to run "udevadm control -R" at all. udev
> will monitor rules from /lib/udev/rules.d while its running and
> automatically reload them when changed.

Interesting; when I tested libu2f-udev, I ran into cases where the rules seemed
not to be loaded yet, though it might be my testing was wrong.

I will likely keep the explicit reload, though, as I need the script anyhow.


> For the second half of this bug:
> > Consider investigating whether it is possible to apply the udev rules to
> > already-plugged-in devices (as setting tag uaccess should be idempotent).
> 
> 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 man page).

Yes, I wrote a bash abomination which parses the installed rules and issues
a series of `udevadm trigger` calls with the right filters  :)

  
https://salsa.debian.org/auth-team/libu2f-host/commit/c9ef9a71415ef69ab2cf872473f1d875b0293df9


Thanks again for the feedback, I will just remove the Pre-Depends (and make it
a regular Depends).


Best,

  nicoo

Re: concerns about Salsa

[Ian Jackson]

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.debian.org isn't running the packaged version of dak.

Even my own git.dgit.d.o isn't running the packaged version of
dgit-infrastructure; it executes out of a git clone.  (I took the
trouble to implement `dgit clone-dgit-repos-server' and the
corresponding server end so make sure that the source code for the
server is always public.)

> I would understand if there were no choice but Salsa admins clearly
> chosen to discard GitLab package in favor of vendor binaries

However, I hope it's not running vendor-provided binaries.  That would
be quite poor IMO and a big departure from our normal practice.  Are
you sure that that is the case ?

> Aren't we sending a wrong message that packaging is not important?

In practice, I have found that it is much easier to deploy a
production service directly from its git tree.  This makes it much
easier to make changes.

With modern red-queen's-race[1] webby stuff there are also sometimes
problems with a mismatch of security update models.  IDK how bad that
problem is in the Ruby ecosystem.

Ian.

[1] https://en.wikipedia.org/wiki/Red_Queen%27s_race

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Ian.

Re: concerns about Salsa

[eamanu15]

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, Dmitry Smirnov 
escribió:

> 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 is installed on
> Salsa.
>
> For almost two years I've been administrating GitLab at work. I've
> installed
> it from official Debian package and helped GitLab maintainer to bring it
> to
> shape. I've introduced GitLab-Runner to Debian, contributed systemd
> support
> for GitLab and helped with testing and fixing various GitLab packaging
> problems in GitLab, gitaly, gitlab-shell, etc. I had no reason to believe
> that Salsa wouldn't use packaged GitLab... It was a big work to get it
> packaged due to large dependency tree.
>
> Official GitLab packages should have become foundation for Salsa, right?
> Sadly somehow that's not the case...
>
> Imagine my surprise when I've found that Salsa is not using our own GitLab
> package at all. When at work I was using latest packaged GitLab, Salsa was
> using much newer version of GitLab than was available from "unstable"
> clearly
> installed by other means than using official GitLab package in Debian.
>
> I would expect Salsa admins and GitLab maintainer to work side by side yet
> they are working independently...
>
> _What makes it OK to run official Debian services on unpackaged vendor
> software distributions?_
>
> I would understand if there were no choice but Salsa admins clearly chosen
> to
> discard GitLab package in favor of vendor binaries while Debian's GitLab
> package (although not without minor problems) is useful.
> At least GitLab package is built on Debian with effort to make it policy
> compliant...
>
> Aren't we sending a wrong message that packaging is not important?
>
> 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?
> Why packaged GitLab is not used to drive Salsa?
>
> --
> Best wishes,
>  Dmitry Smirnov.
>
> ---
>
> Continuous effort - not strength or intelligence - is the key to unlocking
> our potential.
> -- Winston Churchill
>
-- 
Arias Emmanuel
https://www.linkedin.com/in/emmanuel-arias-437a6a8a
http://eamanu.com

concerns about Salsa

[Dmitry Smirnov]

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 is installed on 
Salsa.

For almost two years I've been administrating GitLab at work. I've installed 
it from official Debian package and helped GitLab maintainer to bring it to 
shape. I've introduced GitLab-Runner to Debian, contributed systemd support 
for GitLab and helped with testing and fixing various GitLab packaging 
problems in GitLab, gitaly, gitlab-shell, etc. I had no reason to believe 
that Salsa wouldn't use packaged GitLab... It was a big work to get it 
packaged due to large dependency tree.

Official GitLab packages should have become foundation for Salsa, right? 
Sadly somehow that's not the case...

Imagine my surprise when I've found that Salsa is not using our own GitLab 
package at all. When at work I was using latest packaged GitLab, Salsa was 
using much newer version of GitLab than was available from "unstable" clearly 
installed by other means than using official GitLab package in Debian.

I would expect Salsa admins and GitLab maintainer to work side by side yet 
they are working independently...

_What makes it OK to run official Debian services on unpackaged vendor 
software distributions?_

I would understand if there were no choice but Salsa admins clearly chosen to 
discard GitLab package in favor of vendor binaries while Debian's GitLab 
package (although not without minor problems) is useful.
At least GitLab package is built on Debian with effort to make it policy 
compliant...

Aren't we sending a wrong message that packaging is not important?

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?
Why packaged GitLab is not used to drive Salsa?

-- 
Best wishes,
 Dmitry Smirnov.

---

Continuous effort - not strength or intelligence - is the key to unlocking
our potential.
-- Winston Churchill


signature.asc
Description: This is a digitally signed message part.

Bug#900752: ITP: genometester -- toolkit for performing set operations on k-mer lists

[Liubov Chuprikova]

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 for performing set operations on k-mer lists
 Toolkit for performing set operations - union, intersection and
 complement - on k-mer lists.
 .
 GenomeTester4 toolkit, which contains a novel tool GListCompare for
 performing union, intersection and complement (difference) set
 operations on k-mer lists. It contains examples of how these
 general operations can be combined to solve a variety of biological
 analysis tasks.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/genometester

RE:Feedback request about the Alba Upstream to Debian packaging effort

[PICCA Frederic-Emmanuel]

>> 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, I would use the bpo, this is just that sometimes we use 
experimental in order to prepare transitions.
And I use ~expN  which is > ~alba+N

So I am wondering if you want to create

blabla_x.y.z-t~exp1~alba+1

just wondering.

Cheers

Fred