Bug#782171: Updates?

[Matthieu Caneill]

Hi,

On Mon, May 20, 2024 at 06:48:38AM +, Zhang, Wentao wrote:
> I noticed that in the "package info" box of sources.debian.org, the "SLOC" 
> field
> doesn't recognize Rust. Example [1]. 
> 
> After doing some research I believe it's because of the somewhat outdated
> sloccount program. Similar report can be found here regarding Scala [2].

Indeed, unfortunately sloccount doesn't seem to be actively
maintained, a merge request for Rust support didn't get any attention:
https://sourceforge.net/p/sloccount/code/merge-requests/5/

> Do we have any plan of updating this infrastructure? In my use cases, I turn 
> to
> sources.debian.org and that SLOC field quite often if the package is not
> maintained on Salsa.

I'd love to see support for more languages. We'd need to:

- Find a suitable alternative (supports a superset of sloccount
  languages, has decent performances).

- Replace the execution and parsing of sloccount output by this
  alternative (in
  
https://salsa.debian.org/qa/debsources/-/blob/master/lib/debsources/plugins/hook_sloccount.py?ref_type=heads).

- To keep things consistent, run it on the whole archive to replace
  sloccount results.

Insights on the first point are particularly welcome.

Cheers,
--
Matthieu


signature.asc
Description: PGP signature

Bug#977367: debsources: search results point to not existing sources?

[Matthieu Caneill]

On Wed, Apr 28, 2021 at 10:40:54PM +0200, Michael Stapelberg wrote:
> > Yes - clearly. The bug to implement tarballs-in-tarballs unpacking has
> > been open forever, so I think it's quite unlikely it's gonna be picked
> > up within a reasonable timeframe. I myself won't have time to take
> > care of this anytime soon.
> >
> 
> I can empathize regarding not having enough time, but just want to point
> out that the change itself ended up being quite simple in terms of lines of
> code and mental complexity:
> https://github.com/Debian/dcs/commit/2c94a341f785e2c7552a02500289b95dfe75a83d
> — as you can see, we just loop over *.tar.* and call “tar xf”.
> 
> I’m not saying this to push you to implement it, just mentioning this for
> your information should you eventually get around to it :)

Thank you very much! CCing the original bug for reference, might come
handy sooner or later. :)

Cheers,
--
Matthieu


signature.asc
Description: PGP signature

Bug#977367: debsources: search results point to not existing sources?

[Matthieu Caneill]

Hi Michael,

On Sun, Apr 11, 2021 at 10:41:10AM +0200, Michael Stapelberg wrote:
> We introduced unpacking tarballs in https://github.com/Debian/dcs/issues/80
> (from 2017!),
> but apparently didn’t think it through far enough regarding sources.d.o :)

Thanks for your answer! And I think we can reasonably assume this edge
case doesn't happen too often. :)

> Would adding support for unpacking tarballs be something you would consider
> in debsources?
> I know that tarballs *technically are the source*, but humans clearly find
> the contents of these tarballs more interesting.

Yes - clearly. The bug to implement tarballs-in-tarballs unpacking has
been open forever, so I think it's quite unlikely it's gonna be picked
up within a reasonable timeframe. I myself won't have time to take
care of this anytime soon.

> Otherwise, we could handle these with our own /show handler by checking if
> the source is present in debsources first,
> but that obviously involves one additional request per /show handler, so
> it’s not exactly cheap.

That'd work indeed. Doing nothing also sounds like a reasonable
strategy, given the (assumed) low rate of this failure and the efforts
involved to implement a work-around.

But I'm glad we know where that comes from. Thanks for your thoughts!

Cheers,
--
Matthieu


signature.asc
Description: PGP signature

Bug#977367: debsources: search results point to not existing sources?

[Matthieu Caneill]

Control: usertag -1 debsources
Control: merge 761077 -1

Hi Tomas,

On Mon, Dec 14, 2020 at 02:13:49PM +0100, Tomas Pospisek wrote:
> Go to 
> https://codesearch.debian.net/search?q=Client+sent+an+HTTP+request+to+an+HTTPS+server
> select first link 
> https://codesearch.debian.net/show?file=gcc-10_10.2.1-1%2Fgcc-10.2.0%2Flibgo%2Fgo%2Fnet%2Fhttp%2Fserver.go=1798
> get a 404 with a list of 12 alternative source files of different
> versions of gcc-XX/XX.Y.Z-W/gcc-XX.V.U/libgo/go/net/http/server.go
> each returning a 404.
> 
> I have now clicked through quite a few links to source files, but
> have yet to find one that won't return a 404...?
> 
> Maybe the search index would need to be purged of source files that
> have disappeared (been updated) or something?

Thank you very much for the detailed bug report, and apologies for the
delay in getting back to you.

After further inspection, it turns out the tarball containing the
source for gcc-10 contains embedded tarballs. See
http://deb.debian.org/debian/pool/main/g/gcc-10/gcc-10_10.2.1.orig.tar.xz
and https://sources.debian.org/src/gcc-10/10.2.0-3/

Debsources unpacked the first tarball, and the embedded ones are
technically the "source" of gcc-10. The path you obtained from
codesearch.debian.net points to a file inside the tarball inside the
tarball; this is unfortunately not supported by sources.d.o.

I didn't know codesearch supported this feature. CCing Michael, in
case you have an idea on how not to point to sources.d.o for code
results originating from unpacked archives. :)

Cheers,
--
Matthieu


signature.asc
Description: PGP signature

Bug#928544: debsources: wheezy gone missing

[Matthieu Caneill]

Hi Jakub,

On Mon, May 06, 2019 at 09:58:28PM +0200, Jakub Wilk wrote:
> Some (all?) wheezy packages have disappeared from sources.d.o.

Thank you for catching that. We failed to take the necessary measures
to prevent wheezy from disappearing from debsources after it
disappeared from the mirrors. I'm now re-adding the packages, which
takes some time to process.

Cheers,
--
Matthieu


signature.asc
Description: PGP signature

Bug#818792: qa.debian.org: improve license rendering

[Matthieu Caneill]

Hi Ryan,

On Fri, Jun 15, 2018 at 08:28:22AM +0800, Ryan wrote:
> Am I missing something or do the links in the report no longer seem to appear 
> as
> reported. 

Could you please provide more details? Are the links missing on a
particular URL?

Thanks,
--
Matthieu

Bug#884341: debsources: Unnecessary vertical scroll bar interferes src view scrolling

[Matthieu Caneill]

Hi,

On Mon, Dec 18, 2017 at 11:05:28AM +0800, Boyuan Yang wrote:
> See also the attached image (the same).
> 
> The scrollbar will disappear if I set "overflow-y: hidden" to the pre tag 
> highlighted in the screenshot.

Thanks for the screenshot. I failed to reproduce it or understand
where the scrollbar comes from. I also notice an horizontal scrollbar
below the code that is not supposed to be there.

Since the element or its parents don't have any height set, there
shouldn't be a scrollbar.

While I don't mind applying this CSS hack, I'd prefer to fix this
properly. Are you using any extension that might change how the
elements are displayed, or any parameter I'm not aware of that could
have an impact?

Thanks in advance,
--
Matthieu


signature.asc
Description: PGP signature

Bug#890076: PTS: broken "browse source code" links

[Matthieu Caneill]

Hi,

On Sat, Feb 10, 2018 at 09:56:03PM +0100, Jakub Wilk wrote:
> On , "browse source code" points
> to , which is 404.

Sounds like a debsources bug, however it doesn't 404 for me, it
redirects correctly to
. Maybe it was a
temporary glitch, is it still broken for you?

Cheers,
--
Matthieu


signature.asc
Description: PGP signature

Bug#819013: debsources: deduplicate the html setting the background image

[Matthieu Caneill]

Hi,

On Sun, Jan 21, 2018 at 06:43:41PM +0100, pixthor wrote:
> i know that this bug is a little bit outdated, but i'd like to tackle it
> anyway.

You're very welcome to do that! Don't hesitate to join
#debian-debsources on irc if you have any question.

Cheers,
--
Matthieu


signature.asc
Description: PGP signature

Bug#884341: debsources: Unnecessary vertical scroll bar interferes src view scrolling

[Matthieu Caneill]

Control: user qa.debian@packages.debian.org
Control: usertag -1 debsources


signature.asc
Description: PGP signature

Bug#884341: debsources: Unnecessary vertical scroll bar interferes src view scrolling

[Matthieu Caneill]

Control: usertags -1 debsources

Hi,

On Thu, Dec 14, 2017 at 02:58:28PM +0800, Boyuan Yang wrote:
> For any random page that shows the content of source code, there is an
> unnecessary vertical scroll bar between the line number and the content of
> source code. When the user put focus (e.g., by clicking the content of src),
> the whole page will not be able to scroll up or down anymore till the user
> moves the focus out the the webpage itself.
> 
> I believe we could eliminate the vertical scroll bar completely and solves 
> this
> problem.
> 
> I'm using Debian unstable with Firefox 57. I tested Chromium and the page on
> Chromium seems don't get affected by the problem.

Thanks for reporting this bug. However I could not reproduce it, with
either Firefox 57 or older. Could you maybe provide a screenshot, or
try to identify the broken element/property through the inspector?

Thanks,
--
Matthieu


signature.asc
Description: PGP signature

Bug#862058: python-debian: required dependency on python-apt

[Matthieu Caneill]

Control: reopen -1
Control: tags -1 + patch 

Hi Stuart,

On Sun, Sep 10, 2017 at 01:47:22AM +1000, Stuart Prescott wrote:
> That iter_paragraphs works with compressed indexes at all is somewhat 
> accidental. I don't believe it is documented anywhere that this is a 
> supported 
> use of iter_paragraphs. (But it's rather handy that it does work!) In fact, 
> the documentation says that iter_paragraphs accepts:
> 
>  sequence: a string, or any any object that returns a line of
> input each time, normally a file.
> 
> (not a compressed file).
> 
> Further, my feeling is that if a user chooses to break a Recommends, they get 
> what is coming to them and policy is quite clear about that. 

Thanks for your explanation, I agree with your conclusions.

> As a user of the iter_paragraphs (and other!) functions, if you are in a 
> position to add to the docstrings of these functions so that this contract is 
> more clear to programmer, then that would be greatly appreciated. Building 
> some API docs with sphinx is something we should aim for but at present, 
> there 
> is not nearly enough documentation to make that worthwhile.

I attached a patch that adds a couple lines of doc. In the process I
realised there was a deprecated example with shared_storage in a
README, which I took the opportunity to remove.

Cheers,
--
Matthieu
From 86df0a5b86ec44f07e4fa624d33a5a002a479359 Mon Sep 17 00:00:00 2001
From: Matthieu Caneill <m...@brokenwa.re>
Date: Fri, 6 Oct 2017 21:47:35 +0200
Subject: [PATCH] deb822: add clarifications for iter_paragraphs with
 compressed files

---
 README.deb822| 6 ++
 lib/debian/deb822.py | 4 +++-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/README.deb822 b/README.deb822
index 89e7d64..4480c87 100644
--- a/README.deb822
+++ b/README.deb822
@@ -68,10 +68,8 @@ For example:
 print src['Package'], src['Version']
 
 This method uses python-apt if available to parse the file, since it
-significantly boosts performance. The downside, though, is that yielded
-objects share storage, so they should never be kept accross iterations.
-To prevent this behavior, pass a "shared_storage=False" keyword-argument
-to the iter_paragraphs() function.
+significantly boosts performance. If python-apt is not present and the
+file is a compressed file, it must first be decompressed manually.
 
 
 Sample usage (TODO: Improve)
diff --git a/lib/debian/deb822.py b/lib/debian/deb822.py
index 26f4b68..84af3c2 100644
--- a/lib/debian/deb822.py
+++ b/lib/debian/deb822.py
@@ -313,7 +313,9 @@ class Deb822(Deb822Dict):
 
 :param sequence: a string, or any any object that returns a line of
 input each time, normally a file.  Alternately, sequence can
-be a dict that contains the initial key-value pairs.
+be a dict that contains the initial key-value pairs. When
+python-apt is present, sequence can also be a compressed object,
+for example a file object associated to something.gz.
 
 :param fields: if given, it is interpreted as a list of fields that
 should be parsed (the rest will be discarded).
-- 
2.8.1



signature.asc
Description: PGP signature

Bug#862058: python-debian: required dependency on python-apt

[Matthieu Caneill]

Package: python-debian
Version: 0.1.28
Severity: normal

Dear Maintainer,

python-debian has a Recommends: dependency on python-apt, and a
mechanism to import alternatives when it is not present.

However, when using Sources.iter_paragraphs(f), with f being a file
object of a compressed file (e.g. Sources.gz), python-debian will
decompress the file when python-apt is present, and try to read the
compressed file when it is not (and fail with an expected
UnicodeDecode error).

This affects all current versions.

Cheers,
--
Matthieu

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-debian depends on:
ii  python-chardet  2.3.0-2
ii  python-six  1.10.0-3
pn  python:any  

Versions of packages python-debian recommends:
ii  python-apt  1.1.0~beta4

Versions of packages python-debian suggests:
ii  gpgv  1.4.20-6

-- no debconf information


signature.asc
Description: PGP signature

Bug#861379: debsources: /patches/api/list/ contains packages with no patches (such as 0xffff)

[Matthieu Caneill]

Hi,

On Fri, Apr 28, 2017 at 03:30:58PM +0800, Paul Wise wrote:
> The debsources patches list API mentions the package 0x but this
> package doesn't contain any patches according to the debsources website
> and apt-file and downloading the source package.

Thanks for the report.
I'm not sure this is a bug. The /api/list endpoint was meant to list
all packages, containing 0 or more patches.

Orestis, any memory of this rationale?

Cheers,
--
Matthieu


signature.asc
Description: PGP signature

Bug#861168: qa.debian.org: msg parameter inserts extra line numbers

[Matthieu Caneill]

Hi,

On Tue, Apr 25, 2017 at 01:49:13PM -0400, James McCoy wrote:
> When I view that URL, it looks as per your expectations.  After
> disabling Javascript, I see that the line numbers aren't adjusted.

Thanks for the report and the additional information!

I've dug it a bit, and it indeed comes from the fact the additional
space needed between line numbers to align well (when a popup message
is present) is done in javascript in debsources.js.

A solution could be adding these empty lines server-side. It was the
case before e246fcf, but it was needed to fix #762941…

Cheers,
--
Matthieu


signature.asc
Description: PGP signature

Bug#850173: qa.debian.org: debsources: Please provide link from decorated patch view to download/raw view

[Matthieu Caneill]

Package: qa.debian.org
Severity: wishlist
User: qa.debian@packages.debian.org
Usertags: debsources

[Forwarding the message below, from Christoph Biedl, to BTS.]
--
Matthieu


Hello,

the patch view at e.g.

https://sources.debian.net/patches/vblade/23-1/manpage-escape-dash.patch/

adds some decoration to a patch, suitable for human inspection. It was
nice if that page could contain a link to the raw view which is


https://sources.debian.net/data/main/v/vblade/23-1/debian/patches/manpage-escape-dash.patch

At the moment, you'd have to pick the version number from the
breadcrumb to get the full patch, then identify the applicable one and
click "download". While feasible, a shortcut as above would be of some
help, espcially for people outside the Debian project, in my case:
upstream.

Christoph


signature.asc
Description: PGP signature

Bug#839773: qa.debian.org: debsources: packages with upstream signature listed in .dsc are not added

[Matthieu Caneill]

Package: qa.debian.org
Severity: important
User: qa.debian@packages.debian.org
Usertags: debsources

debsources fails to unpack source packages, complaining on upstream
signatures being listed in the .dsc:

dpkg-source: error: unrecognized file for a v2.0 source package:
libtool_2.4.6.orig.tar.xz.asc
dpkg-source: info: extracting libtool in 
/srv/debsources/sources/main/libt/libtool/2.4.6-2

This is due to our outdated version of dpkg-source.
Relevant discussion can be found at
https://lists.debian.org/debian-dpkg/2016/05/msg00041.html

Cheers,
--
Matthieu

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


signature.asc
Description: PGP signature

Bug#835033: debsources: Retain line context on 404s by appending the hash for specific links

[Matthieu Caneill]

On Thu, Aug 25, 2016 at 03:27:28PM +0100, Chris Lamb wrote:
> Has it been deployed yet? I don't see it on, for example:
> 
>   https://sources.debian.net/src/nostalgy/0.2.33-1/build.sh/#L75

It is now!

Cheers,
--
Matthieu


signature.asc
Description: PGP signature

Bug#828831: debsources: merge all config files in the repo into an unique one

[Matthieu Caneill]

Hi John!
Sorry for late reply.

On Mon, Jul 18, 2016 at 01:07:13PM +0200, John Giannelos wrote:
> I was wondering what's your opinion on moving towards a 12factor app
> config structure on debsources [1]? In many of the web projects I am
> involved we've been using python-decouple [2] for that.
> 
> The idea is that you can separate configuration from code by having a
> single config module with default settings (optional) that gets
> overridden by values on each different env. These values can be defined
> in either a local config file (eg. settings.ini or .env file) or as
> environment variables.
> 
> If you think that's a good way forward I would be interested to work on
> that. python-decouple is not yet packaged for Debian but I am also
> interested to help on that too.

It looks really exciting! And honestly, perfectly answers the
problem. :)

I read the page you mentioned, but I'm not familiar with the tool. I
suppose keeping the values in files is the way to proceed, since
environment variables would have to be guessed/remembered somehow at
every deploy, including the Docker one that we do every day on our dev
machines.

Also, keep in mind the current configuration files are read in many
different places on the codebase (updater, webapp, etc), so it might
incur many changes here and there.

I would suggest to create an RFP or ITP bug for
python-decouple. Unfortunately I doubt I'll have time to help on that
front. However I will happily review any patch on debsources when we
get to that.

Thank you for working on this!

Cheers,
--
Matthieu


signature.asc
Description: PGP signature

Bug#828831: debsources: merge all config files in the repo into an unique one

[Matthieu Caneill]

Package: qa.debian.org
Severity: normal
Usertags: debsources

Currently we have many config files around:
- etc/config.ini, used for sources.d.n
- contrib/docker/config.ini used for docker images
- etc/config.travis.ini used for travis
- doc/examples/sample-config.local.ini as a documentation example

It is difficult to keep them up-to-date, and finding a way to have an
unique one would make things easier.

Cheers,
--
Matthieu

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#761083: #761083 - debsources: inject binary packages metadata into the DB

[Matthieu Caneill]

On Fri, Jun 24, 2016 at 04:41:57PM +0200, Raphael Hertzog wrote:
> > I don't mind at all you using sources.d.n for that purpose, but why
> > not tracker.d.o?
> 
> I thought the same when I saw this report... and the reason is likely that
> the tracker has almost no REST API at all right now and that it thus looked
> harder to implement there.

Thanks for the clarification Raphael!
Makes sense indeed to use debsources for that purpose.

Cheers,
--
Matthieu

Bug#761083: #761083 - debsources: inject binary packages metadata into the DB

[Matthieu Caneill]

Hi Luciano,

On Thu, Jun 09, 2016 at 12:01:09PM +0200, Luciano Bello wrote:
> In the security team we would like to give information about which packages 
> you should update when we release a DSA (currently, we give to the user the 
> source package name). It would be easier for us if we have a way to get the 
> binaries for packages in (old)stable. Sources.d.n is the way to go, I think. 
> For that, this bug needs to be done :)

I don't mind at all you using sources.d.n for that purpose, but why
not tracker.d.o?

Code comments below:

> diff --git a/debsources/app/infobox.py b/debsources/app/infobox.py
> index dd6585c..3f75131 100644
> --- a/debsources/app/infobox.py
> +++ b/debsources/app/infobox.py
> @@ -14,7 +14,7 @@ from __future__ import absolute_import
>  from flask import url_for, current_app
>  
>  from debsources.models import (
> -PackageName, Package, Suite, SlocCount, Metric, Ctag)
> +PackageName, Package, Suite, SlocCount, Metric, Ctag, Binary, BinaryName)
>  from debsources.excepts import Http500Error, Http404Error
>  
>  PTS_PREFIX = "https://tracker.debian.org/pkg/;
> @@ -63,6 +63,22 @@ class Infobox(object):
>  
>  return [x[0] for x in suites]
>  
> +def _get_binary_names(self):
> +""" binary package names """
> +try:
> +print self.package, self.version

unnecessary debug line?

> +binaries = (self.session.query(BinaryName.name)
> +.filter(PackageName.name == self.package,
> +  Package.version == self.version,
> +  Package.name_id == PackageName.id,
> +  Binary.package_id == Package.id,
> +  Binary.name_id == BinaryName.id)
> +.all())
> +except Exception as e:  # pragma: no cover
> +raise Http500Error(e)
> +
> +return [x[0] for x in binaries]
> +
>  def _get_sloc(self):
>  """ sloccount """
>  try:
> @@ -160,3 +176,9 @@ class Infobox(object):
>  pkg_infos['copyright'] = False
>  
>  return pkg_infos
> +
> +def get_binaries(self):
> +"""
> +Retrieves the binary package names, in a list.
> +"""
> +return self._get_binary_names()

I don't understand why you don't store the binary names in pkg_infos,
instead of creating a different method?

> diff --git a/debsources/app/views.py b/debsources/app/views.py
> index e241f83..8ede294 100644
> --- a/debsources/app/views.py
> +++ b/debsources/app/views.py
> @@ -510,7 +510,9 @@ class PackageVersionsView(GeneralView):
>  # INFO PAGES #
>  class InfoPackageView(GeneralView):
>  def get_objects(self, package, version):
> -pkg_infos = Infobox(session, package, version).get_infos()
> +ib = Infobox(session, package, version)
> +pkg_infos = ib.get_infos()
> +binaries = ib.get_binaries()

Same remark as above, having everything in pkg_infos.get_infos would
be simpler IMHO. Unless I'm missing something?

>  return dict(pkg_infos=pkg_infos,
>  package=package,
> -version=version)
> +version=version,binaries=binaries)
> diff --git a/debsources/db_storage.py b/debsources/db_storage.py
> index 7f58c10..e6ed437 100644
> --- a/debsources/db_storage.py
> +++ b/debsources/db_storage.py
> @@ -14,7 +14,7 @@ from __future__ import absolute_import
>  import logging
>  
>  from debsources import fs_storage
> -from debsources.models import File, Package, PackageName, SuiteInfo, Suite
> +from debsources.models import File, Package, PackageName, SuiteInfo, Suite, 
> BinaryName, Binary
>  from debsources.models import VCS_TYPES
>  
>  
> @@ -65,6 +65,21 @@ def add_package(session, pkg, pkgdir, sticky=False):
>  session.flush()
>  file_table[relpath] = file_.id
>  
> +for binpkg in pkg['binary'].split(', '):
> +logging.debug('add to db %s (binary) ...' % binpkg)
> +
> +binary_name = session.query(BinaryName) \
> +  .filter_by(name=binpkg) \
> +  .first()
> +
> +if not binary_name:
> +binary_name = BinaryName(binpkg)
> +session.add(binary_name)
> +session.flush()
> +
> +
> session.add(Binary(name_id=binary_name.id,package_id=db_package.id))
> +
> +session.flush()
>  return file_table
>  
>  
> diff --git a/debsources/models.py b/debsources/models.py
> index c0e4583..468d28b 100644
> --- a/debsources/models.py
> +++ b/debsources/models.py
> @@ -207,8 +207,10 @@ class Binary(Base):
>  ForeignKey('packages.id', ondelete="CASCADE"),
>  index=True, nullable=False)
>  
> -def __init__(self, version, area="main"):
> -self.version = version
> +def __init__(self, name_id, package_id, version=None):
> +

Bug#764961: debsources: port to Python 3

[Matthieu Caneill]

On Sun, 12 Oct 2014 17:40:45 +0200 Stefano Zacchiroli  wrote:
> As per subject: please port Debsources to Python 3.x.

To prevent duplicated efforts: I'm working on this!

Cheers,
--
Matthieu

Bug#782171: Benchmark of linux and chromium

[Matthieu Caneill]

Hey,

On Wed, Apr 06, 2016 at 07:37:53AM +0200, Orestis Ioannou wrote:
> (I had to run latest cloc from github because the one in testing has an
> older release that affects chromium :D )

That point makes me feel pretty confident that cloc can be broken for
other packages. It would be relevant to carefully log errors when we
run the plugin on the whole archive!

> - time cloc-1.66.pl --by-file-by-lang -csv linux-4.4.6
> 
> files,language,blank,comment,code
> 22558,C,2217923,2064183,11330129

That is awesome to have the comments, it adds a good value IMO. Can't
wait to query debsources, asking which license is the most popular
among non-commented code, and other funny queries :)

> 159.95s user 
> 21.10s system 
> 81% cpu 
> 3:40.93 total

That's significantly slower than sloccount, but well, looks ok for
something as big as the linux package. Have you had the chance to see
if it parallelizes well?

> 14,Ruby,59,81,309
> 8,vim script,75,112,264
> 2,Racket,17,51,255
> 4,DTD,44,166,245
> 1,Korn Shell,39,46,223
> 4,XAML,30,50,90
> 4,Standard ML,9,0,61
> 4,Groovy,17,96,57
> 4,PHP,9,0,54
> 9,Verilog-SystemVerilog,0,0,52
> 4,sed,12,21,38
> 1,R,5,5,37
> 1,Prolog,1,-1,32
> 1,Swift,2,0,7

... is that even true? That's off-topic now, but I'm looking forward
to see in which files of chromium we can find php and ML :)

Thanks for you work on this bug!
Cheers,
--
Matthieu

Bug#819861: contributors.debian.org: the From: email header is not in rfc822 format

[Matthieu Caneill]

Package: nm.debian.org
Severity: normal
Tags: patch

Dear Maintainer,

When claiming a new email through the web interface, I receive a
confirmation email with this header:

  From: ('Debian New Member Frontdesk', 'n...@debian.org')

which doesn't display well in email clients (they expect rfc822
format).

Attached is a patch to fix it!

Cheers,
--
Matthieu

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

>From d8b268491422180e06a8ea03c5a3e6745fec1d8f Mon Sep 17 00:00:00 2001
From: Matthieu Caneill <matthieu.cane...@imag.fr>
Date: Sun, 3 Apr 2016 09:46:45 +0200
Subject: [PATCH] Fix email 'From:' format when emailing a claim message

Instead of having:
  From: ('Debian New Member Frontdesk', 'n...@debian.org')
we now get:
  From: Debian New Member Frontdesk <n...@debian.org>

This is to respect rfc822.
---
 contributor/views.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/contributor/views.py b/contributor/views.py
index 1420632..a2a7de6 100644
--- a/contributor/views.py
+++ b/contributor/views.py
@@ -179,8 +179,10 @@ Thank you,
 
 contributors.debian.org
 """.format(user=email, claim=claim, url=url)
+mail_from = '{0} <{1}>'.format(settings.ADMINS[0][0],
+   settings.ADMINS[0][1])
 send_mail('Verify contributors.debian.org claim', message,
-  settings.ADMINS[0], [claim], fail_silently=False)
+  mail_from, [claim], fail_silently=False)
 messages.warning(request, 'Email sent to ' + claim +
  '. Click on the verification link to complete the process')
 return redirect("contributor_detail", name=email)
-- 
2.7.0

Bug#819013: debsources: deduplicate the html setting the background image

[Matthieu Caneill]

Package: qa.debian.org
Severity: minor
Tags: newcomer
User: qa.debian@packages.debian.org
Usertags: debsources

The few lines of html setting the background image on some pages are
duplicated many times (try grepping bg_wrapper).
It would be nice to see this in a separate file that would be included
on demand!

Cheers,
--
Matthieu

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#783584: debsources: improve webapp 404 handling (e.g. jessie - stretch move)

[Matthieu Caneill]

Package: qa.debian.org
Severity: normal
Usertags: debsources

During the move jessie-stretch, many 404 errors were not logged, and
hence more difficult to debug. It would be nice to log the type of
errors that lead to massive 404s.

Cheers,
--
Matthieu


-- System Information:
Debian Release: 7.8
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782171: debsources: consider using cloc instead of sloccount

[Matthieu Caneill]

Package: qa.debian.org
Severity: wishlist
Usertags: debsources

cloc (http://cloc.sourceforge.net/#Languages) supports more languages
than sloccount (e.g. Scala, Javascript), and could be used to count
the lines of code in every package.

This has to be carefully tested, since it needs to run of very big
packages, and be fast enough.

Cheers,
--
Matthieu

-- System Information:
Debian Release: 7.8
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774808: debsources: line number undefined

[Matthieu Caneill]

On 9 January 2015 at 05:05, Jason Pleau ja...@jpleau.ca wrote:
 I was wrong in my previous email, the code I mentionned is not the cause
 of the bug in question. It was an error that I did not catch when
 testing with Firefox.

 Matthieu, can you test the attached patch and see if it fixes the issue
 for you?

Hi Jason,
Thank you for your fast answer. I encountered this week-end hardware
problems and won't be able to test your patch before I fix my laptop.
I'll come back here later, sorry.

Cheers,
--
Matthieu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774808: debsources: line number undefined

[Matthieu Caneill]

On 7 January 2015 at 20:43, Reiner Herrmann rei...@reiner-h.de wrote:
 I'm using Iceweasel 34.0, and when I'm viewing a source file
 on sources.debian.net and click on a line number, it jumps
 to the current URL with #Lundefined appended (instead of e.g. #L123).

 It is working correctly with konqueror, but it occurs even with
 a new iceweasel profile (i.e. no addons installed).

Hi,
Thanks for the report.
I can reproduce this bug. As it works fine when I manually enter such
an URL, I believe the bug is due to the new javascript module
(debsources.js) which automatically highlights lines with internal
links (#L42).
Jason: any idea where this comes from?

Cheers,
--
Matthieu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#770365: debsources: 403 on /src/beignet/1.0.0-1/README.md/

[Matthieu Caneill]

Hi,
Thanks for your report!

On 20 November 2014 at 20:05, Jérémy Bobbio lu...@debian.org wrote:
 When visiting https://sources.debian.net/src/beignet/1.0.0-1/README.md/
 I'm told “403 Permission Denied”. This is a bit annoying as the file is
 listed on https://sources.debian.net/src/beignet/1.0.0-1/

Due to security reasons, we deactivated all symbolic links on
Debsources (even the ones internal to a package, but this isn't
implemented yet).
Zack what do you think?

Cheers,
--
Matthieu


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#744818: ITP: adagios -- Adagios is an alternative web configuration (and status) interface to nagios/icinga/shinken

[Matthieu Caneill]

On Tue, Aug 19, 2014 at 04:14:25PM +0200, Páll Sigurðsson wrote:
 What does the debian package for shinken do ? If they bundle their
 javascripts i see no reason for us not to do the same.

I don't know how it's done in Shinken, but it doesn't change the fact
that having embedded javascript shouldn't be the way to go.

Anyway, I've implemented the use of Bower for the front-end
dependencies management:
https://github.com/savoirfairelinux/adagios/compare/savoirfairelinux:master...feature-bower-dependencies?expand=1

It should help to easily sort packages and use Debian dependencies
whenever they exist :-)

Let me know if you saw things like this.

Cheers,
--
Matthieu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#744818: ITP: adagios -- Adagios is an alternative web configuration (and status) interface to nagios/icinga/shinken

[Matthieu Caneill]

On Mon, Aug 04, 2014 at 08:46:15PM +0200, Páll Sigurðsson wrote:
 Yeah that is a bug which you are more than welcome to fix. Instead of
 @darkstar i use @opensource.is
 
 Does debian specifically oppose bundling javascripts ? What are projects
 like foreman doing ?

Using bower (http://bower.io) could be the way to go. Then, at build-time,
* depend on already-packaged JS libs,
* and bower install the others.
Does that seem reasonable?

The only downside I can see would be the adjustment of paths, which
could be done by a patch to the Apache configuration.

Thoughts?

Cheers,
--
Matthieu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#744818: ITP: adagios -- Adagios is an alternative web configuration (and status) interface to nagios/icinga/shinken

[Matthieu Caneill]

[Adding Tomas in the loop]

On Thu, Jul 24, 2014 at 06:16:16PM +0200, Páll Sigurðsson wrote:
 to my knowledge no debian/ directory other than the one you mention.
 
 That one has the status of: 'works for me'.

It also works for me, though lintian reports many errors.

* palli@darkstar is used many times in debian/changelog, is that on
  purpose or do you agree to change it to your regular email address?

* we still have the problem of included javascript libraries, does
  anybody have news regarding this? Tomas?

Cheers,
--
Matthieu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#744818: ITP: adagios -- Adagios is an alternative web configuration (and status) interface to nagios/icinga/shinken

[Matthieu Caneill]

Hi,

On Tue, 15 Apr 2014 18:36:29 +, Pall Sigurdsson:
 Ok, love the idea of using git.

What's the most up-to-date information regarding this debian/ folder?
Is there a git repo somewhere else than
https://github.com/opinkerfi/adagios ?

I'd like to contribute to the packaging.

Thanks,
--
Matthieu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org