Bug#649300: marked as done (dpkg-www: [dpkg-www] generates bad links)

2019-03-15 Thread Debian Bug Tracking System
Your message dated Sat, 16 Mar 2019 14:28:33 +0900
with message-id <20190316052833.ga15...@goofy.osamu.debian.net>
and subject line dpkg-www: [dpkg-www] generates bad links for =
has caused the Debian Bug report #649300,
regarding dpkg-www: [dpkg-www] generates bad links
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
649300: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649300
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: dpkg-www
Version: 2.54+nmu1
Severity: important

When using the '=Value' argument, dpkg-www generates a page with bad links.

For example, http://localhost/cgi-bin/dpkg?query=%3Dfirewall gives:
ii  gufw   
11.04.2-1graphical user interface for ufw



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (700, 'testing'), (700, 'stable'), (500, 'oldstable'), (50, 
'experimental'), (50, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf-8, LC_CTYPE=fr_FR.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dpkg-www depends on:
ii  apache2-mpm-prefork [httpd]  2.2.21-2  
ii  apt  0.8.15.9  
ii  dwww 1.11.6
ii  info2www 1.2.2.9-24
ii  perl [perl5] 5.12.4-6  

dpkg-www recommends no packages.

Versions of packages dpkg-www suggests:
ii  amaya [www-browser]  9.55~dfsg.0-1  
ii  dctrl-tools [grep-dctrl] 2.19   
ii  dlocate  1.02   
ii  epiphany-browser [www-browser]   3.0.4-1
ii  galeon [www-browser] 2.0.7-2.1+b1   
ii  iceape [www-browser] 2.0.14-9   
ii  icecat [www-browser] 5.0-custom1
ii  iceweasel [www-browser]  7.0.1-4
ii  kazehakase [www-browser] 0.5.8-4
ii  konqueror-trinity [www-browser]  4:3.5.13-0debian9+r1261450+pr19~squeeze
ii  links [www-browser]  2.3-1  
ii  lynx-cur [www-browser]   2.8.8dev.9-2   
ii  man2html 1.6g-6 
ii  midori [www-browser] 0.4.1-2
ii  netsurf [www-browser]2.8-1  
ii  netsurf-gtk [www-browser]2.8-1  
ii  opera [www-browser]  11.52.1100 
ii  tasksel  3.07   
ii  uzbl [www-browser]   0.0.0~git.20110412-2   
ii  w3m [www-browser]0.5.3-4
ii  xemacs21-mule [www-browser]  21.4.22-3.1+b1 

-- no debconf information


--- End Message ---
--- Begin Message ---
Version: 2.59

Hi,

I don't experience any problem as reported in 2011 now(2019).

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---===
ii  dpkg-www   2.59 all  Debian package management web 
interface

Considering this bug report is more than 8 years old with very scant
facts to do any productive bug fix, and no one else filed similar thing.
Its probably fixed between 2.55-2.59.  This is best closed now.

Osamu--- End Message ---


Bug#615807: dpkg-www case sesitivity issue

2019-03-15 Thread Osamu Aoki
Hi,

The situation of case sensitivity can be summarized for web browser page
opened by the "dpkg-www" as:

Search term with tailing "*": case sensitive

Search term without tailing "*": case insensitive

As I read Policy 4.3.0
  https://www.debian.org/doc/debian-policy/ch-controlfields.html#source

| Package names (both source and binary, see Package) must consist only of
| lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs,
| and periods (.). They must be at least two characters long and must
| start with an alphanumeric character.  Search term with tailintg "*":
| case sensitive

So search should be forced to case insensitive by lower casing the
search term for package name before doing anything to be more friendly.

But inputting mC or aPt is known bad input. This program just sanitizes
its input for a select case only.   The current behavior isn't too bad
at all while it can be improved.

Osamu




 



Bug#914515: dpkg: please provide an interface to bootstrap dpkg from zero

2019-03-15 Thread Johannes Schauer
Hi Guillem,

Quoting Guillem Jover (2019-03-15 05:22:32)
> On Sat, 2018-11-24 at 10:24:09 +0100, Johannes 'josch' Schauer wrote:
> > lintian recently tagged mmdebstrap with uses-dpkg-database-directly because
> > mmdebstrap contains the string "/var/lib/dpkg" in several places. Instead
> > of overwriting the lintian tag in mmdebstrap, dpkg could also gain an
> > interface which avoids mmdebstrap having to do anything with /var/lib/dpkg
> > inside the chroot. Specifically, what mmdebstrap does is the following:
> > 
> >  - create /var/lib/dpkg, /var/lib/dpkg/triggers, /var/lib/dpkg/info,
> >/var/lib/dpkg/alternatives and /var/lib/dpkg/updates because dpkg
> >throws an error if these directories are not present
> Right, will handle those.
> 
> >  - an empty /var/lib/dpkg/status because dpkg refuses to work without
> >the file being present
> I've fixed this one now in a local next/bootstrap branch which I'll push out
> tomorrow-

Cool! But I'll only follow up on this in mmdebstrap once we release Buster. :)

Another file that I found is required is /var/lib/dpkg/available. If this file
does not exist (it can even be empty) then package removals will fail.

> >  - adds architectures to /var/lib/dpkg/arch because $(dpkg
> >--add-architecture) doesn't work without any packages inside the
> >chroot
> This sould already work when passing --root= or --admindir=, it should even
> work w/o being root. :)

How then are the foreign architectures communicated to dpkg if not via
/var/lib/dpkg/arch?

> >  - cleans up leftover /var/lib/dpkg/lock-frontend and /var/lib/dpkg/lock
> As mentioned on IRC, this should not be necessary, these are range-locks, and
> they work not based on their presence, but whether they process has acquired
> locks within them.

Agreed. mmdebstrap already does not remove them anymore.

Thanks!

cheers, josch


signature.asc
Description: signature