Re: systemd-fsck?

[Russ Allbery]

Dimitri John Ledkov  writes:

> My only complaint against systemd-fsck at the moment is (poor?)
> integration with graphical plymouth themes. I'd like to see:
> "Checking disk 2/3... 78% done"
> or some such.
> Which one can see on desktops & servers with upstart/mountall/plymouth
> matched combo.

> Any idea if something like that is in the works? Or is working, but
> just not setup/configured correctly yet?

I don't know if that's in the works, but it looks like it would be pretty
easy to add based on the 204 source.  (I haven't looked at a later version
to see if it already added something like that.)  Currently, it just sends
output to /dev/console, but it's already processing the fsck output and
turning it into a human-readable message like that.  I don't know much
(well, anything) about how plymouth works, but presumably there's just
someplace else to send output like that other than /dev/console that would
produce the correct effect.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a9ar1y0q@windlord.stanford.edu

Re: systemd-fsck?

[Dimitri John Ledkov]

On 9 May 2014 02:42, Russ Allbery  wrote:
> Svante Signell  writes:
>
>> I'm trying to install as little as possible of systemd stuff, and guess
>> what happens: When booting one of the laptops boot starts with:
>> systyemd-fsck 
>
>> Is systemd taking over everything?? How to reduce the number of
>> systemd-* features.
>
> It's a small wrapper around fsck that handles status reporting in a way
> that works well with the journal and with systemd boot-time status
> reporting and takes care of some dbus coordination and whatnot.  I believe
> It's basically the equivalent of all the shell logic in checkroot.sh and
> checkfs.sh.  In other words, well within the mandate for anything that
> handles early boot, replacing shell scripts that were previously provided
> by initscripts.
>
> The actual fsck work is still done by the separate fsck binary, just like
> it always has been.
>

My only complaint against systemd-fsck at the moment is (poor?)
integration with graphical plymouth themes. I'd like to see:
"Checking disk 2/3... 78% done"
or some such.
Which one can see on desktops & servers with upstart/mountall/plymouth
matched combo.

Any idea if something like that is in the works? Or is working, but
just not setup/configured correctly yet?

systemd-fsck output on server / textual boot is fine, but on the
desktop i'd like to see something prettier.

I guess i can patch systemd-fsck to send user-friendly message updates
to plymouth, but i thought it would be available out of the box.

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/canbhluhdzqvpmqqikfn77xqyxyyg5zodhjzsycqcrksygpt...@mail.gmail.com

Re: systemd-fsck?

[Russ Allbery]

Svante Signell  writes:

> I'm trying to install as little as possible of systemd stuff, and guess
> what happens: When booting one of the laptops boot starts with:
> systyemd-fsck 

> Is systemd taking over everything?? How to reduce the number of
> systemd-* features.

It's a small wrapper around fsck that handles status reporting in a way
that works well with the journal and with systemd boot-time status
reporting and takes care of some dbus coordination and whatnot.  I believe
It's basically the equivalent of all the shell logic in checkroot.sh and
checkfs.sh.  In other words, well within the mandate for anything that
handles early boot, replacing shell scripts that were previously provided
by initscripts.

The actual fsck work is still done by the separate fsck binary, just like
it always has been.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oaz720d8@windlord.stanford.edu

Work-needing packages report for May 9, 2014

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 569 (new: 1)
Total number of packages offered up for adoption: 135 (new: 0)
Total number of packages requested help for: 59 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   clipf (#746696), orphaned 6 days ago
 Description: command line minimalistic personal finance manager
 Installations reported by Popcon: 17

568 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 135 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apt-xapian-index (#567955), requested 1557 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: ept-cache fuss-launcher goplay packagesearch
 Installations reported by Popcon: 80014

   athcool (#278442), requested 3481 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 52

   balsa (#642906), requested 956 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 813

   cardstories (#624100), requested 1109 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 14

   chromium-browser (#583826), requested 1439 days ago
 Description: Chromium browser
 Reverse Depends: chromedriver chromium chromium-dbg chromium-l10n
   mozplugger
 Installations reported by Popcon: 25490

   csv2latex (#746158), requested 11 days ago
 Description: a CSV to LaTeX file converter
 Installations reported by Popcon: 163

   cups (#532097), requested 1797 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups chromium cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client cups-core-drivers cups-daemon
   cups-dbg (62 more omitted)
 Installations reported by Popcon: 140235

   debtags (#567954), requested 1557 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popcon: 2471

   fbcat (#565156), requested 1576 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 156

   freeipmi (#628062), requested 1078 days ago
 Description: GNU implementation of the IPMI protocol
 Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect
   freeipmi-tools libfreeipmi-dev libfreeipmi12 libipmiconsole-dev
   libipmiconsole2 libipmidetect-dev libipmidetect0 (3 more omitted)
 Installations reported by Popcon: 4936

   gnat-gps (#496905), requested 2079 days ago
 Description: co-maintainer needed
 Reverse Depends: gnat-gps gnat-gps-dbg
 Installations reported by Popcon: 526

   gnokii (#677750), requested 691 days ago
 Description: Datasuite for mobile phone management
 Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql
   gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6
   xgnokii
 Installations reported by Popcon: 1774

   gnupg (#660685), requested 808 days ago
 Description: GNU privacy guard - a free PGP replacement
 Reverse Depends: 0install-core apt arriero bootstrap-base
   cdebootstrap cdebootstrap-static cdebootstrap-udeb
   clamav-unofficial-sigs cloud-utils debian-archive-keyring (55 more
   omitted)
 Installations reported by Popcon: 170150

   gpa (#663405), requested 789 days ago
 Description: GNU Privacy Assistant (GPA)
 Installations reported by Popcon: 605

   gradle (#683666), requested 644 days ago
 Description: Groovy based build system
 Reverse Depends: gradle libgradle-plugins-java
 Installations reported by Popcon: 87

   gridengine (#703256), requested 417 days ago
 Description: Distributed resource management
 Reverse Depends: gridengine-client gridengine-drmaa-dev
   gridengine-exec gridengine-master gridengine-qmon logol
 Installations reported by Popcon: 1186

   grub2 (#248397), requested 3650 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: grml-rescueboot grml2usb grub-coreboot
   grub-coreboot-bin grub-coreboot-dbg grub-disk grub-efi
   grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-dbg (33 more
   omitted)
 Installations reported by Popcon

Re: Ghostscript licensing changed to AGPL

[Clint Byrum]

Excerpts from Riley Baird's message of 2014-05-08 14:02:49 -0700:
> >> So if Debian provides, say, a web frontend to Ghostscript, then with 
> >> AGPL Ghostscript running that web frontend as a service for others 
> >> only require an interface serving its sources if the _webmaster_ 
> >> changes the code for that frontend?
> >>
> >> Not if Debian makes changes to both the frontend and AGPL 
> >> Ghostscript?
> >>
> >> That seems like a loophole to me: If Google wants an advantage by 
> >> running better-than-ghostscript.google.com PDF convertor, they can 
> >> simply let another company/organisation/person be the "Debian" in 
> >> their chain and not need to reveal their patches to their users.
> >
> > You missed the hidden §18 (“No Loopholes Allowed”):
> > https://lists.debian.org/20130711174500.ga22...@redhat.com
> 
> I don't think that we can simply say "No Loopholes Allowed". Otherwise,
> we could say the same of practically *any* license.
> 
> As far as I can tell, nowhere in the AGPL (or the GPL for that matter),
> does it say that you only have to offer the code if you haven't modified
> it. You must offer the code if you distribute it (modified or
> unmodified) - that way, you're guaranteeing that all users are able to
> modify the program should they wish to.
> 

Section 15, paragraph1, sentence 1:

"Notwithstanding any other provision of this License, if you modify
the Program, your modified version must prominently offer all users
interacting with it remotely through a computer network (if your version
supports such interaction) an opportunity to receive the Corresponding
Source of your version by providing access to the Corresponding Source
from a network server at no charge, through some standard or customary
means of facilitating copying of software. This Corresponding Source
shall include the Corresponding Source for any work covered by version
3 of the GNU General Public License that is incorporated pursuant to
the following paragraph."

Nowhere does it say that the version you _use_ must prominently offer
all users interacting with it ... only your modified version must do that.

Not sure why they did that, but there it is.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1399584340-sup-5...@fewbar.com

Re: Ghostscript licensing changed to AGPL

[Riley Baird]

>> So if Debian provides, say, a web frontend to Ghostscript, then with 
>> AGPL Ghostscript running that web frontend as a service for others 
>> only require an interface serving its sources if the _webmaster_ 
>> changes the code for that frontend?
>>
>> Not if Debian makes changes to both the frontend and AGPL 
>> Ghostscript?
>>
>> That seems like a loophole to me: If Google wants an advantage by 
>> running better-than-ghostscript.google.com PDF convertor, they can 
>> simply let another company/organisation/person be the "Debian" in 
>> their chain and not need to reveal their patches to their users.
>
> You missed the hidden §18 (“No Loopholes Allowed”):
> https://lists.debian.org/20130711174500.ga22...@redhat.com

I don't think that we can simply say "No Loopholes Allowed". Otherwise,
we could say the same of practically *any* license.

As far as I can tell, nowhere in the AGPL (or the GPL for that matter),
does it say that you only have to offer the code if you haven't modified
it. You must offer the code if you distribute it (modified or
unmodified) - that way, you're guaranteeing that all users are able to
modify the program should they wish to.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/536bf0f9.7080...@bitmessage.ch

systemd-fsck?

[Svante Signell]

Hi,

I'm trying to install as little as possible of systemd stuff, and guess
what happens: When booting one of the laptops boot starts with:
systyemd-fsck 

Is systemd taking over everything?? How to reduce the number of
systemd-* features.

FYI: I'm no longer using gnome, only components of it.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1399582256.2096.6.camel@PackardBell-PC

Re: Automatically dumping test-suite.log on make check failure

[Bálint Réczey]

2014-05-08 20:49 GMT+02:00 Marcin Owsiany :
>
> 2014-05-08 19:33 GMT+02:00 Guillem Jover :
>
>> Hi!
>>
>> On Thu, 2014-05-08 at 19:10:48 +0200, Marcin Owsiany wrote:
>> > Does anyone know a way to make the automake-generated test suite scripts
>> > cat
>> > the test-suite.log to stderr on failure? It just reports which tests
>> > failed but
>> > hides the actual messages. This is most annoying on buildds which then
>> > promptly
>> > remove the whole build dir, and one has to then tediously find a porter
>> > box,
>> > set up schroot, fetch the package, install build-deps, run the build and
>> > then
>> > finally manually cat the log. Example:
>>
>> Yes, pass VERBOSE=1 to the «make check» call. This was brought up
>> recently in the following thread:
>>
>>   
>
>
> Awesome, thank you!
I'm with Joey on this.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680686#29

IMO Debian buildds should set DH_VERBOSE=1 and VERBOSE=1 instead of
making various parts of debhelper more verbose.
This would fix a range of problems, not just the missing test logs.

Cheers,
Balint


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpyzzf3yod4oo1awnc6ota_ywaja1kxarg-rm9qxfg7...@mail.gmail.com

Re: Ghostscript licensing changed to AGPL

[Clint Byrum]

Excerpts from Don Armstrong's message of 2014-05-08 12:06:08 -0700:
> On Thu, 08 May 2014, Thorsten Glaser wrote:
> > On Wed, 7 May 2014, Bálint Réczey wrote:
> > > In my interpretation in this case I would have some reasonable time
> > > to comply, i.e. I don't have to publish all 0days on my site if I
> > > run AGPL-covered software..
> 
> You only have to publish code to users who are interacting with that
> code. If you're deploying 0 day fixes to the internet, then you're going
> to have to provide access to the same code so that other people can take
> advantage of your fixes.
> 
> > On Wed, 7 May 2014, Clint Byrum wrote:
> > > The things that link to ghostscript as a library will now need to be
> > > evaluated. If they are contacted via network ports, they'll need to
> > > have source download capabilities added.
> 
> This is incorrect. They only need to have this in place if they modify
> the AGPLed work.
>  

Good point, and I forgot about the second paragraph of section 13:

"Notwithstanding any other provision of this License, you have permission
to link or combine any covered work with a work licensed under version
3 of the GNU General Public License into a single combined work, and to
convey the resulting work. The terms of this License will continue to
apply to the part which is the covered work, but the work with which
it is combined will remain governed by version 3 of the GNU General
Public License."

Which I think might mean that the programs linking to libghostscript can
stay under the GPL-3. It might mean that. I'm not entirely sure, and I
haven't asked a lawyer. If it didn't mean that, then I think AGPL may
infringe on DFSG point 3, since derived, combined works are effectively
under a different license that requires source code dissemination.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1399580754-sup-7...@fewbar.com

Re: Ghostscript licensing changed to AGPL

[Jonas Smedegaard]

Quoting Jakub Wilk (2014-05-08 21:55:45)
> * Jonas Smedegaard , 2014-05-08, 21:37:
>> So if Debian provides, say, a web frontend to Ghostscript, then with 
>> AGPL Ghostscript running that web frontend as a service for others 
>> only require an interface serving its sources if the _webmaster_ 
>> changes the code for that frontend?
>>
>> Not if Debian makes changes to both the frontend and AGPL 
>> Ghostscript?
>>
>> That seems like a loophole to me: If Google wants an advantage by 
>> running better-than-ghostscript.google.com PDF convertor, they can 
>> simply let another company/organisation/person be the "Debian" in 
>> their chain and not need to reveal their patches to their users.
>
> You missed the hidden §18 (“No Loopholes Allowed”):
> https://lists.debian.org/20130711174500.ga22...@redhat.com

Ah, right: The difference between programming logic and law reasoning.

Thanks for reminding - makes good sense.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Ghostscript licensing changed to AGPL

[Jakub Wilk]

* Jonas Smedegaard , 2014-05-08, 21:37:
So if Debian provides, say, a web frontend to Ghostscript, then with 
AGPL Ghostscript running that web frontend as a service for others only 
require an interface serving its sources if the _webmaster_ changes the 
code for that frontend?


Not if Debian makes changes to both the frontend and AGPL Ghostscript?

That seems like a loophole to me: If Google wants an advantage by 
running better-than-ghostscript.google.com PDF convertor, they can 
simply let another company/organisation/person be the "Debian" in their 
chain and not need to reveal their patches to their users.


You missed the hidden §18 (“No Loopholes Allowed”):
https://lists.debian.org/20130711174500.ga22...@redhat.com

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140508195518.ga3...@jwilk.net

Re: Ghostscript licensing changed to AGPL

[Russ Allbery]

Jonas Smedegaard  writes:

> So if Debian provides, say, a web frontend to Ghostscript, then with 
> AGPL Ghostscript running that web frontend as a service for others only 
> require an interface serving its sources if the _webmaster_ changes the 
> code for that frontend?

> Not if Debian makes changes to both the frontend and AGPL Ghostscript?

> That seems like a loophole to me: If Google wants an advantage by 
> running better-than-ghostscript.google.com PDF convertor, they can 
> simply let another company/organisation/person be the "Debian" in their 
> chain and not need to reveal their patches to their users.

> What did I miss?

Debian is providing the sources (via ftp.us.debian.org), and hence
satisfying the AGPL to the extent that those sources qualify.  The
webmaster may need to explicitly include that link somewhere to meet the
"prominently offer" requirement, but they don't need to host the source
themselves unless they have local modifications.

That said, I'm one of the people who feels like the "prominently offer"
requirement is the modern version of the BSD advertising clause, and is
problematic for all of the same reasons that the BSD advertising clause
is.  It's ironic that the FSF would choose to reintroduce exactly the
problem that they correctly identified many years ago.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r4442grp@windlord.stanford.edu

Re: Ghostscript licensing changed to AGPL

[Jonas Smedegaard]

Quoting Don Armstrong (2014-05-08 21:06:08)
> On Thu, 08 May 2014, Thorsten Glaser wrote:
> > On Wed, 7 May 2014, Bálint Réczey wrote:
> > > In my interpretation in this case I would have some reasonable time
> > > to comply, i.e. I don't have to publish all 0days on my site if I
> > > run AGPL-covered software..
> 
> You only have to publish code to users who are interacting with that
> code. If you're deploying 0 day fixes to the internet, then you're going
> to have to provide access to the same code so that other people can take
> advantage of your fixes.
> 
> > On Wed, 7 May 2014, Clint Byrum wrote:
> > > The things that link to ghostscript as a library will now need to be
> > > evaluated. If they are contacted via network ports, they'll need to
> > > have source download capabilities added.
> 
> This is incorrect. They only need to have this in place if they modify
> the AGPLed work.

So if Debian provides, say, a web frontend to Ghostscript, then with 
AGPL Ghostscript running that web frontend as a service for others only 
require an interface serving its sources if the _webmaster_ changes the 
code for that frontend?

Not if Debian makes changes to both the frontend and AGPL Ghostscript?

That seems like a loophole to me: If Google wants an advantage by 
running better-than-ghostscript.google.com PDF convertor, they can 
simply let another company/organisation/person be the "Debian" in their 
chain and not need to reveal their patches to their users.

What did I miss?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Ghostscript licensing changed to AGPL

[Don Armstrong]

On Thu, 08 May 2014, Thorsten Glaser wrote:
> On Wed, 7 May 2014, Bálint Réczey wrote:
> > In my interpretation in this case I would have some reasonable time
> > to comply, i.e. I don't have to publish all 0days on my site if I
> > run AGPL-covered software..

You only have to publish code to users who are interacting with that
code. If you're deploying 0 day fixes to the internet, then you're going
to have to provide access to the same code so that other people can take
advantage of your fixes.

> On Wed, 7 May 2014, Clint Byrum wrote:
> > The things that link to ghostscript as a library will now need to be
> > evaluated. If they are contacted via network ports, they'll need to
> > have source download capabilities added.

This is incorrect. They only need to have this in place if they modify
the AGPLed work.
 
> On Thu, 8 May 2014, Riley Baird wrote:
> > What if the network in question is not the internet?
> 
> Right, the AGPL is not technology-neutral.

The AGPL just specifies "computer network" and "network server". It says
nothing about the internet at all.

-- 
Don Armstrong  http://www.donarmstrong.com

"Because," Fee-5 explained patiently, "I was born in the fifth row.
Any fool would understand that, but against stupidity the very Gods
themselves contend in vain."
 -- Alfred Bester _The Computer Connection_ p19


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140508190608.gh13...@teltox.donarmstrong.com

Re: Ghostscript licensing changed to AGPL

[Philipp Kern]

On 2014-05-08 00:13, Clint Byrum wrote:

We don't ensure that users comply, we simply start them in a position
of compliance. If they change what we've given them, it is their
responsibility to remain in compliance. For the same reason, if they
modify the source of a program to link to an incompatibly licensed
library and build it, that is their prerogative.

The things that link to ghostscript as a library will now need to be
evaluated.  If they are contacted via network ports, they'll need to
have source download capabilities added.


Right. I was worried about that. This would make all programs that 
satisfy this instantly non-license compliant (RC-buggy with threat of 
being removed from the archive?) when AGPL'ed ghostscript is uploaded. 
(OTOH Ubuntu apparently did not care for 14.04, because Ghostscript 
there is already AGPL.) Unless we argue that we do not actually run the 
software and it's the users' responsibility to get into compliance. And 
that's the thing I'd heavily disagree with. And we'd suddenly need more 
infrastructure to actually allow those source downloads (and how much 
source? just Ghostscript? but the whole thing is transitively AGPL 
now!).


So I only checked very carelessly right now, but it does not seem like 
that software actually exists. I see gimp, gle-graphics and 
texlive-binaries linking against it. And those are not typically network 
services.


Kind regards
Philipp Kern


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/6fbfac0a09f5e78e6223c78dc96e1...@hub.kern.lc

Re: Automatically dumping test-suite.log on make check failure

[Marcin Owsiany]

2014-05-08 19:33 GMT+02:00 Guillem Jover :

> Hi!
>
> On Thu, 2014-05-08 at 19:10:48 +0200, Marcin Owsiany wrote:
> > Does anyone know a way to make the automake-generated test suite scripts
> cat
> > the test-suite.log to stderr on failure? It just reports which tests
> failed but
> > hides the actual messages. This is most annoying on buildds which then
> promptly
> > remove the whole build dir, and one has to then tediously find a porter
> box,
> > set up schroot, fetch the package, install build-deps, run the build and
> then
> > finally manually cat the log. Example:
>
> Yes, pass VERBOSE=1 to the «make check» call. This was brought up
> recently in the following thread:
>
>   
>

Awesome, thank you!

Marcin

Re: Nftables in jessie?

[Vincent Bernat]

 ❦  8 mai 2014 19:16 +0200, Frank Bauer  :

> Jessie currently contains linux 3.13, which includes the successor of
> iptables - nftables.  Unfortunately, the userspace tools (nftables)
> are still missing even in sid/experimental.
>
> Is there a general plan to support nftables in jessie? As the release
> managers reminded us recently, the freeze will be here in no time. I
> believe it is essential for users to be able to test this new
> technology in jessie before fully switching to it in jessie+1.

In the NEW queue:
 https://ftp-master.debian.org/new/nftables_0.099+git20140120-1.html
-- 
Make sure your code "does nothing" gracefully.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Automatically dumping test-suite.log on make check failure

[Guillem Jover]

Hi!

On Thu, 2014-05-08 at 19:10:48 +0200, Marcin Owsiany wrote:
> Does anyone know a way to make the automake-generated test suite scripts cat
> the test-suite.log to stderr on failure? It just reports which tests failed 
> but
> hides the actual messages. This is most annoying on buildds which then 
> promptly
> remove the whole build dir, and one has to then tediously find a porter box,
> set up schroot, fetch the package, install build-deps, run the build and then
> finally manually cat the log. Example:

Yes, pass VERBOSE=1 to the «make check» call. This was brought up
recently in the following thread:

  

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140508173306.ga5...@pulsar.hadrons.org

Re: Automatically dumping test-suite.log on make check failure

[Emilio Pozuelo Monfort]

On 08/05/14 19:19, Dimitri John Ledkov wrote:
> On 8 May 2014 18:10, Marcin Owsiany  wrote:
>> Does anyone know a way to make the automake-generated test suite scripts cat
>> the test-suite.log to stderr on failure? It just reports which tests failed 
>> but
>> hides the actual messages. This is most annoying on buildds which then 
>> promptly
>> remove the whole build dir, and one has to then tediously find a porter box,
>> set up schroot, fetch the package, install build-deps, run the build and then
>> finally manually cat the log. Example:
> 
> override_dh_auto_test:
> ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
> dh_auto_build -- -k check || { RET=$$?; find . -name
> "test-suite.log" -exec cat {} + ; exit $$RET;}
> endif
> 

Much easier:

make check V=1

Emilio


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/536bbe04.5080...@gmail.com

Re: Automatically dumping test-suite.log on make check failure

[Dimitri John Ledkov]

On 8 May 2014 18:25, Emilio Pozuelo Monfort  wrote:
> On 08/05/14 19:19, Dimitri John Ledkov wrote:
>> On 8 May 2014 18:10, Marcin Owsiany  wrote:
>>> Does anyone know a way to make the automake-generated test suite scripts cat
>>> the test-suite.log to stderr on failure? It just reports which tests failed 
>>> but
>>> hides the actual messages. This is most annoying on buildds which then 
>>> promptly
>>> remove the whole build dir, and one has to then tediously find a porter box,
>>> set up schroot, fetch the package, install build-deps, run the build and 
>>> then
>>> finally manually cat the log. Example:
>>
>> override_dh_auto_test:
>> ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
>> dh_auto_build -- -k check || { RET=$$?; find . -name
>> "test-suite.log" -exec cat {} + ; exit $$RET;}
>> endif
>>
>
> Much easier:
>
> make check V=1
>

that only prints the failed tests, not all of them on failure?! I
wanted, well needed in that package, the full logs, on failure.

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANBHLUgPLH03P4E5X7YjvmoWCbFjkhz+=afm2tskhrz65sg...@mail.gmail.com

Nftables in jessie?

[Frank Bauer]

Hi,

Jessie currently contains linux 3.13, which includes the successor of
iptables - nftables.
Unfortunately, the userspace tools (nftables) are still missing even in
sid/experimental.

Is there a general plan to support nftables in jessie? As the release
managers reminded
us recently, the freeze will be here in no time. I believe it is essential
for users to be able
to test this new technology in jessie before fully switching to it in
jessie+1.

Regards,
Frank

Re: Automatically dumping test-suite.log on make check failure

[Dimitri John Ledkov]

On 8 May 2014 18:10, Marcin Owsiany  wrote:
> Does anyone know a way to make the automake-generated test suite scripts cat
> the test-suite.log to stderr on failure? It just reports which tests failed 
> but
> hides the actual messages. This is most annoying on buildds which then 
> promptly
> remove the whole build dir, and one has to then tediously find a porter box,
> set up schroot, fetch the package, install build-deps, run the build and then
> finally manually cat the log. Example:

override_dh_auto_test:
ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
dh_auto_build -- -k check || { RET=$$?; find . -name
"test-suite.log" -exec cat {} + ; exit $$RET;}
endif

I believe debhelper already does something similar for
dh_auto_configure & ./configure style build-systems, i.e. at the end
of a failed configure it does cat "config.log"
Displaying all test-suite.log files, at the end of failed dh_auto_test
would be highly appreciated.

Anybody can convert above logic into dh_auto_test's make build-system?

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANBHLUin9SW8f1V=4zdcgnmhfcbx8s15wuv4jshqwtaycof...@mail.gmail.com

Automatically dumping test-suite.log on make check failure

[Marcin Owsiany]

Does anyone know a way to make the automake-generated test suite scripts cat
the test-suite.log to stderr on failure? It just reports which tests failed but
hides the actual messages. This is most annoying on buildds which then promptly
remove the whole build dir, and one has to then tediously find a porter box,
set up schroot, fetch the package, install build-deps, run the build and then
finally manually cat the log. Example:

make[7]: Entering directory `/«PKGBUILDDIR»/test/automatic'
PASS: endian1
PASS: convert
PASS: message1
PASS: message2
PASS: packet
PASS: hash
FAIL: connect
PASS: resolver
PASS: protocol
make[8]: Entering directory `/«PKGBUILDDIR»/test/automatic'
Making all in script
make[9]: Entering directory `/«PKGBUILDDIR»/test/automatic/script'
make[9]: Nothing to be done for `all'.
make[9]: Leaving directory `/«PKGBUILDDIR»/test/automatic/script'
make[9]: Entering directory `/«PKGBUILDDIR»/test/automatic'
make[9]: Nothing to be done for `all-am'.
make[9]: Leaving directory `/«PKGBUILDDIR»/test/automatic'
make[8]: Leaving directory `/«PKGBUILDDIR»/test/automatic'

Testsuite summary for libgadu 1.12.0-rc3

# TOTAL: 9
# PASS:  8
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See test/automatic/test-suite.log

make[7]: *** [test-suite.log] Error 1

more at 
https://buildd.debian.org/status/fetch.php?pkg=libgadu&arch=kfreebsd-amd64&ver=1%3A1.12.0~rc3-1&stamp=1399557832&file=log

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140508171048.GA20344@localhost

Re: howto handle jquery embedding by build-depends

[Russ Allbery]

Thorsten Glaser  writes:

> This is a bug in doxygen. Replacing the embedded jquery copy in the
> Debian package shipping it with a link to the jquery version in Debian
> should be the right thing to do.

This has previously been discussed on this list, and the Doxygen
maintainers said explicitly that this is *not* the right thing to do.
Apparently this isn't just a jQuery copy, but also contains other code or
other Doxygen-specific modifications.  (I've not investigated this myself;
just trying to act as institutional memory here.)

There was, at one point, some talk of a dh_doxygen helper that would do
the right thing, whatever that may be, but I don't think it's ever
materialized.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d2fo5moh@windlord.stanford.edu

RE: Bug #702005: Where can i get more attention on this?

[Luis Alejandro Martínez Faneyth]

Thanks, Ian.
I will be following the steps you pinted out so that this fix lands on stable.

I will email you privately in a couple of hours.
Greetings,
Luis.
> From: ijack...@chiark.greenend.org.uk
> Date: Thu, 8 May 2014 13:03:11 +0100
> To: l...@huntingbears.com.ve
> CC: debian-devel@lists.debian.org; 702...@bugs.debian.org
> Subject: Re: Bug #702005: Where can i get more attention on this?
> 
> Luis Alejandro Martínez Faneyth writes ("Bug #702005: Where can i get more 
> attention on this?"):
> > I'm a little worried about bug #702005 and the lack of attention
> > it's getting.  This bug is marked as resolved, and indeed it has
> > been resolved for jessie and sid, but not for wheezy. This bug
> > breaks Python 2.7. Every person that tries to upgrade python2.7 and
> > python2.7-minimal from version 2.7.3-6 to 2.7.3-6+deb7u2, is
> > affected by this bug.
> 
> It's not clear from your messages here on -devel exactly what you
> think the right next step is.  Reading the bug report, I think you are
> suggesting that a particular patch should be backported to
> debian-stable.
> 
> > Please, can someone upload the fix to wheezy also?  Or, how can i
> > help?  Thanks,
> 
> Uploads to stable following the process documented here:
>  
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
> 
> So the next step would be to file a bug against release.debian.org
> asking for approval for inclusion of this patch in stable.
> 
> That approval request should come with clear explanation (from first
> principles, aimed at someone who doesn't necessarily follow the
> intricacies of the python packaging), of both the bug and the fix.
> 
> If you like I would be happy to review a draft of such an explanation
> if you were to write one.  If you produce an explanation that
> satisfies me, and you get approval from the stable team, I would also
> be happy to review and sponsor your upload.
> 
> If you would like to try to take the lead in this way, it's probably
> best to email me privately, perhaps CC the bug, with your drafts etc.
> I don't think debian-devel need to see all of this.
> 
> >  This is affecting also every debian derivative based on stable, and
> > is worth mentioning:
> 
> Of course we should try to do a good job in stable, but of course one
> thing that a derivative can be expected to diverge on is questions of
> release management.
> 
> Usually most of the work in backporting a fix is not in the technical
> work of preparing the package - it is in analysing whether the fix is
> appropriate for users or stable (and indeed, in persuading the
> relevant release managemers).
> 
> Ian.
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: 
> https://lists.debian.org/21355.29311.737503.869...@chiark.greenend.org.uk
> 
  

Re: howto handle jquery embedding by build-depends

[Jonas Smedegaard]

Hi Vincent,

Quoting Vincent Bernat (2014-05-08 13:52:01)
> ❦  8 mai 2014 11:45 +0200, Thorsten Glaser  :
> 
>>> /usr/share/doc/doxygen/README.jquery
>>
>> This is a bug in doxygen. Replacing the embedded jquery copy in the 
>> Debian package shipping it with a link to the jquery version in 
>> Debian should be the right thing to do. Maybe this entire technology 
>> behind doxygen needs gentle kicking, like people such as Torsten 
>> Werner did to Java™ stuff, to get it to conform to our expectations.
>
> Yeah, let's ignore the others and say them they are wrong.
>
> In the JS world, they rely on "semantic versioning". In theory, this 
> says that version x.y+1.z is backward-compatible with x.y.w. In 
> practice, this is not always the case and automatic upgrade from one 
> minor version to another one should be done with care. jQuery is 
> mature enough to be more immune to this problem but many wide-used 
> libraries have this problem. For example, Twitter Bootstrap as in 
> Debian is 2.0.2 (quite old). The latest version for the 2.x serie is 
> 2.3. It is quite unlikely that a project using 2.0 can use 2.3 without 
> additional modifications.
>
> By forbidding embedded copies without providing a sensible alternative 
> (like a package with all minor versions of jQuery), we are just 
> introducing bugs in our packages making them of lesser quality.

You mention yourself that jQuery likely isn't as bad as e.g. Bootstrap, 
yet you describe only the extreme alternative of needing *all* versions 
of jQuery packaged.

I suggest that each package feeling the need for a specific version of 
jQuery (or any other JavaScript project) file a bugreport against 
corresponding package to get that version maintained properly.

Then we can revisit this issue in some months when we have a more 
realistic picture of a) how many versions of various code projects are 
really needed, and b) how maintainers of those code projects feel about 
maintaining code which is possibly abandoned and unmaintained upstream.

...and depending on b) we can then also discuss how maintainers of 
non-JavaScript packages expect to do a better job at maintaining such 
code - but let's first explore if possible for Debian to keep current 
separation of responsibility, before going down other paths.


> It is already difficult to make people understand how we work with our 
> release cycle. We don't need angry users and angry upstream because we 
> modify packages to introduce additional bugs.

Agreed.


> Like other languages, Javascript will mature and will handle those
> problems with their community. In the meantime, we need to be flexible
> and tolerant.

I think we can help JavaScript projects mature faster by tracking which 
projects comply with semantic versioning and which do not, instead of 
just assuming they don't comply.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: howto handle jquery embedding by build-depends

[Jose Luis Rivas]

On 08/05/14, 08:01am, Daniel Baumann wrote:
> src:lxc contains documentation (*.sgml only) and build-depends on
> docbook2x, no jquery is needed or installed as build-depends. the
> resulting bin:lxc-dev then contains a *compressed* jquery.js put there
> by docbook2x. lintian detects this and warns about it (W:
> embedded-javascript-library).
> 
> i think we have the following possibilities to handle such embedding of
> files by build-depends, where the embedded files were not part of the
> original source (starting with least favourable one):
> 
>   A: ignore it and overwrite the lintian warning
> 
>   B: overwrite the lintian warning, use a built-using: relation in
>  control (in lxc case, against docbook2x which imports the
>  jquery.js)
> 
>   C: post-process the binary package content at buildtime to replace
>  the embedded files through proper depends (e.g. for jquery,
>  replace the file with a symlink to /usr/share/javascript/jquery
>  /jquery.js and have a depends or recommends on libjs-jquery).
> 
>  this could potentially have side effects if the copy of the
>  to-be-embedded file (jquery.js) inside the tool that imports it
>  (docbook2x) is not in sync with the standalone packaged version
>  (libjs-jquery), so that we end up with a newer/incompatible
>  version.
> 
> for lxc, i'd go with C.
> 
> did i miss anything? (yes, i haven't fully read the last thread about
> jquery on debian-devel a couple of weeks ago, i think it only covered
> the 'what to do with embedded js in source packages'-cases, not this
> 'what to do with embedded js in binary packages not being part of the
> source package'-case).

I actually think there's a D option and is based on the solution that Daniel
Kahn Gillmor gave on a similar issue I had with powertop, which is using
native javascript instead of jquery. [0] Of course, this wouldn't be on
lxc but directly on docbook2x and that would fix it for more packages
than only lxc.

[0] https://bugs.debian.org/695890

Other people in this thread has already pointed out the issues with
several versions of jQuery and I honestly believe native javascript
should be enough for the transformations docbook2x seems to be using.

BTW, I failed to see on docbook2x website how is that javascript is used
at all. Would you give me a hint so I don't need to build the package
myself to check if this is actually a viable solution in this case as
well?

Kind regards.
-- 
Jose Luis Rivas | ghostbar
The Debian Project → 
GPG 3E7D 4267 AFD5 2407 2A37 20AC 38A0 AD5B CACA B118


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140508130217.gb1...@arya.ghostbar.co

Re: Bug #702005: Where can i get more attention on this?

[Jose Luis Rivas]

On 08/05/14, 01:05pm, Ian Jackson wrote:
> Ian Jackson writes ("Re: Bug #702005: Where can i get more attention on 
> this?"):
> > [some stuff to Luis Alejandro Martínez Faneyth ]
> 
> Unfortunately, Luis's mail domain is hosted at Hotmail which hates
> chiark:
> 
>   l...@huntingbears.com.ve
> SMTP error from remote mail server after MAIL 
> FROM: SIZE=4130:
> host 3fd47c7f131f4ca31143ff3af72008.pamx1.hotmail.com [65.54.188.78]:
> 550 SC-002 (BAY0-PAMC1-F10) Unfortunately, messages from 212.13.197.229 
> weren't sent. Please contact your Internet service provider since part of 
> their network is on our block list. You can also refer your provider to 
> http://mail.live.com/mail/troubleshooting.aspx#errors.
> 
> (I know of the causes of this; I disagree with Hotmail and resolving
> things is nontrivial.)
> 
> So hopefully Luis will see my reply here on -devel or in the bug.
> 
> Luis, if you want to email me, please use a different email address
> that doesn't go to Hotmail.
> 
I already pointed Luis's to your email on the list's archive on IRC and
on Twitter. I'll point it out in IM in a few hours anyway so I make sure
he does see it.

Thanks Ian.
-- 
Jose Luis Rivas | ghostbar
The Debian Project → 
GPG 3E7D 4267 AFD5 2407 2A37 20AC 38A0 AD5B CACA B118


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140508125003.ga1...@arya.ghostbar.co

Re: Bug #702005: Where can i get more attention on this?

[Ian Jackson]

Ian Jackson writes ("Re: Bug #702005: Where can i get more attention on this?"):
> [some stuff to Luis Alejandro Martínez Faneyth ]

Unfortunately, Luis's mail domain is hosted at Hotmail which hates
chiark:

  l...@huntingbears.com.ve
SMTP error from remote mail server after MAIL 
FROM: SIZE=4130:
host 3fd47c7f131f4ca31143ff3af72008.pamx1.hotmail.com [65.54.188.78]:
550 SC-002 (BAY0-PAMC1-F10) Unfortunately, messages from 212.13.197.229 
weren't sent. Please contact your Internet service provider since part of their 
network is on our block list. You can also refer your provider to 
http://mail.live.com/mail/troubleshooting.aspx#errors.

(I know of the causes of this; I disagree with Hotmail and resolving
things is nontrivial.)

So hopefully Luis will see my reply here on -devel or in the bug.

Luis, if you want to email me, please use a different email address
that doesn't go to Hotmail.

Thanks,
Ian.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21355.29472.967519.595...@chiark.greenend.org.uk

Re: Bug #702005: Where can i get more attention on this?

[Ian Jackson]

Luis Alejandro Martínez Faneyth writes ("Bug #702005: Where can i get more 
attention on this?"):
> I'm a little worried about bug #702005 and the lack of attention
> it's getting.  This bug is marked as resolved, and indeed it has
> been resolved for jessie and sid, but not for wheezy. This bug
> breaks Python 2.7. Every person that tries to upgrade python2.7 and
> python2.7-minimal from version 2.7.3-6 to 2.7.3-6+deb7u2, is
> affected by this bug.

It's not clear from your messages here on -devel exactly what you
think the right next step is.  Reading the bug report, I think you are
suggesting that a particular patch should be backported to
debian-stable.

> Please, can someone upload the fix to wheezy also?  Or, how can i
> help?  Thanks,

Uploads to stable following the process documented here:
 https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable

So the next step would be to file a bug against release.debian.org
asking for approval for inclusion of this patch in stable.

That approval request should come with clear explanation (from first
principles, aimed at someone who doesn't necessarily follow the
intricacies of the python packaging), of both the bug and the fix.

If you like I would be happy to review a draft of such an explanation
if you were to write one.  If you produce an explanation that
satisfies me, and you get approval from the stable team, I would also
be happy to review and sponsor your upload.

If you would like to try to take the lead in this way, it's probably
best to email me privately, perhaps CC the bug, with your drafts etc.
I don't think debian-devel need to see all of this.

>  This is affecting also every debian derivative based on stable, and
> is worth mentioning:

Of course we should try to do a good job in stable, but of course one
thing that a derivative can be expected to diverge on is questions of
release management.

Usually most of the work in backporting a fix is not in the technical
work of preparing the package - it is in analysing whether the fix is
appropriate for users or stable (and indeed, in persuading the
relevant release managemers).

Ian.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21355.29311.737503.869...@chiark.greenend.org.uk

Re: howto handle jquery embedding by build-depends

[Vincent Bernat]

 ❦  8 mai 2014 11:45 +0200, Thorsten Glaser  :

>> /usr/share/doc/doxygen/README.jquery
>
> This is a bug in doxygen. Replacing the embedded jquery copy
> in the Debian package shipping it with a link to the jquery
> version in Debian should be the right thing to do. Maybe this
> entire technology behind doxygen needs gentle kicking, like
> people such as Torsten Werner did to Java™ stuff, to get it to
> conform to our expectations.

Yeah, let's ignore the others and say them they are wrong.

In the JS world, they rely on "semantic versioning". In theory, this
says that version x.y+1.z is backward-compatible with x.y.w. In
practice, this is not always the case and automatic upgrade from one
minor version to another one should be done with care. jQuery is mature
enough to be more immune to this problem but many wide-used libraries
have this problem. For example, Twitter Bootstrap as in Debian is 2.0.2
(quite old). The latest version for the 2.x serie is 2.3. It is quite
unlikely that a project using 2.0 can use 2.3 without additional
modifications.

By forbidding embedded copies without providing a sensible alternative
(like a package with all minor versions of jQuery), we are just
introducing bugs in our packages making them of lesser quality.

It is already difficult to make people understand how we work with our
release cycle. We don't need angry users and angry upstream because we
modify packages to introduce additional bugs.

Like other languages, Javascript will mature and will handle those
problems with their community. In the meantime, we need to be flexible
and tolerant.
-- 
Parenthesise to avoid ambiguity.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

ITP: python-phonenumbers -- phonenumbers Python Library

[Dr. Torge Szczepanek]

Package: wnpp
Serverity: wishlist
Owner: Dr. Torge Szczepanek 

Package name: python-phonenumbers
Version : 6.0.0a
Upstream Author : David Drysdale
URL : https://github.com/daviddrysdale/python-phonenumbers
License : Apache-2.0
Programming Lang: Python
Description : phonenumbers Python Library

This is a Python port of libphonenumber, originally from 
http://code.google.com/p/libphonenumber/. 
It supports Python 2.5-2.7 and Python 3.x (in the same codebase, 
with no 2to3 conversion needed).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/f79f4c6f-1028-4d9e-bbd9-fd64872e7...@cygnusnetworks.de

Bug#747404: ITP: kxd -- Key exchange daemon

[Maximiliano Curia]

Package: wnpp
Severity: wishlist
Owner: Maximiliano Curia 

* Package name: kxd
  Version : 0.11
  Upstream Author : Alberto Bertogli 
* URL : http://blitiri.com.ar/p/kxd/
* License : MIT
  Programming Lang: Go
  Description : Key exchange daemon

kxd is a key exchange daemon, which serves blobs of data (keys) over https.

It can be used to get keys remotely instead of using local storage. The main
use case is to get keys to open dm-crypt devices automatically, without having
to store them on the local machine.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140508103117.12115.88431.report...@amadeus.maxy.com.ar

Alioth tracker

[Оlе Ѕtrеісhеr]

Hi,

is someone processing the items on the Alioth tracker?

There are currently 184 reuqests open, some trivial requests already
since two years (like [1]).

I filed a ticket there a month ago, and still did not get any
response yet.

What is the reason that the processing there is so slow? Is there a way
to change that?

Also, although alioth is an official Debian server (right? It has .org
suffix), it does not use the Debian bug system, but its own ticket
system. I asked that already some time ago, and got the recommendation
to ask that on alioth directly. However, since the response time there
is so long, I doubt that there will be a discussion about this.

Best regards

Ole

[1] https://alioth.debian.org/tracker/index.php?func=detail&aid=313806


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ytzr444sgzb@news.ole.ath.cx

Re: Ghostscript licensing changed to AGPL

[Riley Baird]

> So please excuse my ignorance here: But how does that work? How can we,
> as Debian, ensure that a user automatically complies with the license
> when a package is installed and spawns up a service on a port? (Or
> similarly, installs itself into a web server found on the system.)

I don't think that, technically, Debian has any requirement to do so.
However, I would definitely be less comfortable using Debian if I could
end up inadvertently violating a license just by starting a web server.

> Should it then communicate that it is Debian version X and that the
> source can be found on any Debian mirror near you?

What if the network in question is not the internet?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/536b4f7c.8080...@bitmessage.ch

Re: howto handle jquery embedding by build-depends

[Thorsten Glaser]

On Thu, 8 May 2014, Paul Wise wrote:

> /usr/share/doc/doxygen/README.jquery

This is a bug in doxygen. Replacing the embedded jquery copy
in the Debian package shipping it with a link to the jquery
version in Debian should be the right thing to do. Maybe this
entire technology behind doxygen needs gentle kicking, like
people such as Torsten Werner did to Java™ stuff, to get it to
conform to our expectations.

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.10.1405081143450.20...@tglase.lan.tarent.de

Re: Non-source Javascript files in upstream source

[Joachim Breitner]

Dear Ben,

Am Donnerstag, den 08.05.2014, 12:21 +1000 schrieb Ben Finney:
> > Well, I say "Let's do something else, I'll have another look later".
> 
> I am using https://wiki.debian.org/BenFinney/software/repack> for
> another package, to remove non-source JavaScript files from the Debian
> source package.

the same functionality is provided by uscan (via mk-origtargz) in the
next devscritps release, based on Files-Excluded fields in
debian/copyright.


Would you mind evaluating whether that does all that you need?
(debcheckout devscripts and build and install usually).


We need this integrated seemlessly in our tools to not waste more
developer time than necessary.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

SwiftMailer new upstream release

[Nicolas]

Hi all,

I'm looking for a sponsor for the package swiftmailer that is already in
debian. Upstream delivered a new release. There's no major changes in
debian packaging. I can build the package and lintian did not complain
about errors.

I know it's not the right list (preferred m.d.o) but I hope here a
developer can help me and upload it for me.

The package :
SwiftMailer
   - licence : MIT
   - version : 5.1.0
   - project url : http://swiftmailer.org/
   The package is maintain on alioth :
   - Vcs-Git: git://anonscm.debian.org/collab-maint/swift.git
   - Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/swift.git

Thanks in advance for takin attention to my message.

Regards,
Nicolas

Re: Non-source Javascript files in upstream source

[Ben Finney]

Vincent Bernat  writes:

>  ❦  8 mai 2014 12:21 +1000, Ben Finney  :
>
> > I am using https://wiki.debian.org/BenFinney/software/repack>
> > for another package, to remove non-source JavaScript files from the
> > Debian source package.
> >
> > I have now re-worked it for the ‘roundcube’ package and submitted it in
> > patches for bug#736782.
>
> Thanks for that.

You're welcome; I tried to make that program robust and easily-adapted
to most packages that need it. I hope it's useful to other package
maintainers.

> As pointed in the bug report, jQuery UI has been modified by roundcube
> authors (I don't know exactly how, just putting the same version from
> Debian introduced some bugs) and jstz.min.js has no source.

Okay. Those both sound like problems to be solved before the Debian
package source will meet the standard set by the ftpmaster team.

> Just to say that this takes time not just because I am too lazy.

Yes, for many packages, ensuring the source is distributed as entirely
free software does take time. I definitely sympathise with that.

-- 
 \   “The long-term solution to mountains of waste is not more |
  `\  landfill sites but fewer shopping centres.” —Clive Hamilton, |
_o__)_Affluenza_, 2005 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85lhucbsi2@benfinney.id.au

Re: Non-source Javascript files in upstream source

[Vincent Bernat]

 ❦  8 mai 2014 12:21 +1000, Ben Finney  :

>> When I get some time to work on my packages and I see this:
>>  
>> http://lintian.debian.org/maintainer/pkg-roundcube-maintain...@lists.alioth.debian.org.html#roundcube
>
> Yes, it's disheartening to see such files in a source distribution from
> upstream. Fortunately the solution isn't complex.

From the upstream point of view, people want to be able to install that
by just dropping the source files into the appropriate
directory. Upstream has already puts a lot of effort to accomodate us by
always providing a "GPL" version of the packages (without most of the
embedded copies).

>> Well, I say "Let's do something else, I'll have another look later".
>
> I am using https://wiki.debian.org/BenFinney/software/repack> for
> another package, to remove non-source JavaScript files from the Debian
> source package.
>
> I have now re-worked it for the ‘roundcube’ package and submitted it in
> patches for bug#736782.

Thanks for that. As pointed in the bug report, jQuery UI has been
modified by roundcube authors (I don't know exactly how, just putting
the same version from Debian introduced some bugs) and jstz.min.js has
no source. Just to say that this takes time not just because I am too
lazy.
-- 
/* Fuck me gently with a chainsaw... */
2.0.38 /usr/src/linux/arch/sparc/kernel/ptrace.c


signature.asc
Description: PGP signature