Re: Lintian based autorejects

[Joerg Jaspert]

>> Please do.  For now, and I think until squeeze or this tag no longer
>> visible on lintian.d.o (ie no package affected), whatever comes first,
>> this tag is in nonfatal.
> I think you shall find that most already have bugs filed.

Yes, and I really like that I do not have to do this myself, thanks.


-- 
bye, Joerg
"If you are using an Macintosh e-mail program that is not from Microsoft, we
recommend checking with that particular company. But most likely other e-mail
 programs like Eudora are not designed to enable virus replication" 
   -- http://www.microsoft.com/mac/products/office/2001/virus_alert.asp


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

Re: Lintian based autorejects

[Manoj Srivastava]

On Wed, Nov 04 2009, Steve Langasek wrote:

> On Tue, Nov 03, 2009 at 11:29:53PM -0600, Manoj Srivastava wrote:
>
>> > Do you understand why people are getting annoyed ?
>
>> They have a lot of bloody gall to be annoyed thatpeople file
>>  bugs about serious policy violations that they have signed up to
>>  follow, and neglected in their packages, and instead of thanking peple
>>  who find out and point to these policy violations, they feel angry at
>>  the bug reporter, instead of ashamed at how they neglect bugs in their
>>  packages.
>
> Yes, you have completely failed to understand the issue.
>
> I'm not complaining about you filing bugs on *my* packages.  I'm
> complaining about a mass bug filing on *any* packages, using standards
> that have not previously been approved by the project, because *doing
> so skews priorities for the project as a whole*.  Marking bugs as
> severity: serious means *the project* has to deal with the resulting

I think this is mostly false.  90% of the bugs filed were on
 target, and the remaining were only bumped up one level; and usertagged
 for easy changes.

Note that the vast majority of bugs I have filed as serious are
 violations of Must directives:

,[ http://www.debian.org/Bugs/Developer#severities ]
|  serious
| is a severe violation of Debian policy (roughly, it violates a
| "must" or "required" directive), or, in the package maintainer's or
| release manager's opinion, makes the package unsuitable for release.
`

25 out of 240 bugs were upgraded from important to serious, and
 these are the tags in these 25 bugs:
   arch-dependent-file-in-usr-share
   binary-with-bad-dynamic-table
   control-file-has-bad-permissions
   depends-on-build-essential-package-without-using-version
   dir-or-file-in-tmp
   invalid-standards-version
   missing-build-dependency
   missing-build-dependency-for-dh_-command
   no-standards-version-field
   package-installs-python-pyc

All of these are policy violations, and would normally result in
 at least important bugs.

> bugs.  The bugs get mixed into the RC bug list and take up resources
> of participants in bug squashing parties; the release team has to go
> back and mark bugs as release-ignore or downgrade them if they're not
> actually release-critical issues;

The amount of effort needed to fix these is about comparable to
 kvetching about it or downgrading them, And, anyway, given that the
 bugs are all usertagged, it is trivial to reset them.  These would be
 low hanging fruit in bug squash parties, and 

> the QA team winds up with these packages on their radar even if the
> package quality doesn't warrant it.

None of the packages belonging to the QA team are affected.

> All because you're jumping at the chance to slap serious bugs on
> people's packages without waiting for consensus to emerge on whether
> those issues, some of which are entirely cosmetic, should actually be
> serious.

There is already consensus on the severity of bugs that violate
 must directives in policy. That is 90% of the bugs filed.

The other bugs are still important. And  trivial for the
maintainer to download/

> That's not improving the quality of Debian, that's just being a jerk.

Bullshit. A researched, usertagged set of bugs that takes 5
 minutes to change the severity gets your panties in such a twist?
 Where rules lawyering about who is entitled to file what bugs is more
 important than  discovering long neglected bugs?

>>Finally, these violations of policy are added to the blacklist,
>> since these serious policy violations are adjudged too buggy for Debian
>
> The use of passive voice here masks the fact that the adjuge-er is not the
> Debian project as a whole.

The debian project as a whole  does not adjudicate a whole lot
 of things -- like which bugs ought to get a pass in a release.  There
 are a whole lot of decisions made by the DPL and delegates, and I for
 one think that the people in charge of the archive get the same leeway
 that the people in charge of the release do.

manoj
-- 
Professional wrestling: ballet for the common man.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Lintian based autorejects

[Manoj Srivastava]

On Wed, Nov 04 2009, Joerg Jaspert wrote:

>>> Please do.  For now, and I think until squeeze or this tag no longer
>>> visible on lintian.d.o (ie no package affected), whatever comes first,
>>> this tag is in nonfatal.
>> I think you shall find that most already have bugs filed.
>
> Yes, and I really like that I do not have to do this myself, thanks.

So. An overview of the policy related bug filing I have been
 doing recently can be found at:
   http://tinyurl.com/yk8p3rx

Coming up with that URL was ... interesting.

manoj

-- 
We promise according to our hopes, and perform according to our fears.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: dir-or-file-in-var-www on single-HTML file web "apps" or the like

[sean finney]

hiya,

On Wed, Nov 04, 2009 at 08:49:54AM +0100, Stefano Zacchiroli wrote:
> > with respect to those that don't, it's been previously discussed and
> > deemed okay for them not to work out of the box, which is a relatively
> > small cost for the benefit of FHS compliance and general safety/sanity.
> 
> OK on those without Alias, but how about whose that do have Alias-es? Do
> you have a list of them and which file ship? Do you have some kind of
> intermediate level where the maintainer can specify the Alias only once
> and have it "compiled" to all web server configurations?

nope, but i assume if there are folks who feel this itch it will get
scratched :)  this type of information would be really good to have
in footnotes or an appendix in the webapps policy or some other best
practices document.

> you have a list of them and which file ship? Do you have some kind of
> intermediate level where the maintainer can specify the Alias only once
> and have it "compiled" to all web server configurations?

i think that was the original intention of webapps-common, but once again i
should point out that this project hasn't gone anywhere in a year or two,
mostly due to lack of interest/time.


sean


signature.asc
Description: Digital signature

Re: dir-or-file-in-var-www on single-HTML file web "apps" or the like

[Tzafrir Cohen]

On Wed, Nov 04, 2009 at 08:49:54AM +0100, Stefano Zacchiroli wrote:
> On Wed, Nov 04, 2009 at 08:08:46AM +0100, sean finney wrote:
> > > We have webservers other than Apache.
> 
> When raising this kind of counter argument, is usually nice to also
> provide (pointers to) solutions :-)

"For apache2: 



Alternatively, just use the following command to make the package work
with any httpd:

  ln -s /var/www/FOO ../../usr/share/foo
"

Naturally those symlinks will now be created manually and will typically
be absolute as nobody bothers with proper relative symlinks where you
don't have tab completion for your aid. But I guess that's not a real
issue.

> 
> > and many of these other web servers provide a feature similar to Alias.
> > with respect to those that don't, it's been previously discussed and
> > deemed okay for them not to work out of the box, which is a relatively
> > small cost for the benefit of FHS compliance and general safety/sanity.
> 
> OK on those without Alias, but how about whose that do have Alias-es? Do
> you have a list of them and which file ship? Do you have some kind of
> intermediate level where the maintainer can specify the Alias only once
> and have it "compiled" to all web server configurations?

OK. Now in the role of a "package maintainer fairly familiar with apache
config and not with anything else". I have avoided installing the
specific packages of the httpds on my system because I'm lazy. Remember
that this is work you want many package maintainers to do.

I looked at nginx, lighttpd and cherokee. IIRC aolserver4 and caudium
are also configurable enough.


nginx
-
Based on e.g. http://wiki.nginx.org/NginxFullExample2

Would require something along the lines of:

location /foo {
  root /usr/share/foo;
}

I have no idea how this interacts with other parts of the config. Is it
safe to just include in a random config? Anything else that should
probably be there?

At first glance there does not seem to be a directory equivalent to
/etc/apache2/conf.d , and thus I can't simply tell the user to copy an
example file somewhere.


lighttpd


Configuration:

alias.url = ( "/foo/" => "/usr/share/foo/")


[Once again, I have no idea about interactions and such.]


Instructions:

1. Make sure mod_alias is enabled [Is it enabled by default? Any stanza
   instructions a-la a2enmod?]. 
2. Copy the example configuration file:

  cp /usr/share/doc/foo/examples/foo-lighttpd.conf \
/etc/lighttpd/conf-available/20-foo.conf

3. Refresh lighttpd and reload it [How, exactly?]


cherokee

Likewise here the package does not seem to have an include directory.
Thus I can't simply provide a sample configuration snippet for the user
to copy.

Furthermore, the rules used in the configuration seem to mee a bit too
different. It would require a bit testing to even understand them. So
for the hypothetical package foo I just don't bother.

See http://www.cherokee-project.com/doc/dev_cherokee.conf.html


I would tend to add sample apache configuration, test it, and have the
package Suggest apache in addition to Depend-ing on httpd or httpd-cgi.
This way I know I have something I tested to work. As close as possible
with the "Just Works" factor to the simple symlink.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend


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

Re: Lintian based autorejects

[Manoj Srivastava]

On Wed, Nov 04 2009, Steve Langasek wrote:


> I'm not complaining about you filing bugs on *my* packages.  I'm
> complaining about a mass bug filing on *any* packages, using standards
> that have not previously been approved by the project, because *doing
> so skews priorities for the project as a whole*.  Marking bugs as
> severity: serious means *the project* has to deal with the resulting
> bugs.  The bugs get mixed into the RC bug list and take up resources
> of participants in bug squashing parties; the release team has to go
> back and mark bugs as release-ignore or downgrade them if they're not
> actually release-critical issues; the QA team winds up with these
> packages on their radar even if the package quality doesn't warrant
> it.

Now that the ftp-masters have changed the blacklist, all the
 bugs that were reported at serious severity due to the blacklist have
 been downgraded to important, and it was fairly trivial to do the
 severity change.

All must violations of policy remain at severity serious; if you
 think policy needs to be changed, please  follow the policy change
 process. If you do not understand policy, please ask for help.

If you think your package is special, and should get an
 exemption from policy MUST directives, please explain why on the
 debian-policy list; it might be an indication that the debian policy
 needs changing.  Please do not just downgrade the bugs.

manoj
-- 
Prejudice: A vagrant opinion without visible means of support. Ambrose
Bierce
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Lintian based autorejects

[Steve Langasek]

On Wed, Nov 04, 2009 at 01:15:57AM +0100, Joerg Jaspert wrote:

> > E: ftp-master: wrong-file-owner-uid-or-gid
> > Policy 9.2 does /not/ prohibit shipping files with owners outside these
> > ranges; it prohibits relying on user or group IDs outside these ranges being
> > static, but there doesn't appear to be anything in Policy that prohibits
> > creating the user in the package preinst and then unpacking the package such
> > that ownership is applied by /name/.  (Unless I'm mistaken, this is
> > precisely what dpkg does.)

> > So false-positives are possible with this lintian check, and it should be
> > overrideable.

> We currently only have 1 package in the whole archive triggering
> this. Thats why it is listed.
> Fine, moved to nonfatal.

Yes, and that package is not a false-positive - it is genuinely broken and
should be fixed.  Still, the check itself is unreliable.

> > E: ftp-master: section-is-dh_make-template
> > Sections in source packages have minimal impact; the section that matters is
> > the one specified in the archive override.  There's no reason that the
> > invalid default value given by dh_make should result in a package being
> > rejected, when arbitrary other values for the field would not.  Please drop
> > this check.

> We tend to simply reject such packages from NEW. So the maintainer can
> see it instantly triggered this way or has to wait until NEW is
> processed. I tend to think this way is better.

I would agree with you except for two things:

- the check will also be applied to existing packages in the archive which
  already have overrides, where the source package's section doesn't really
  matter

- the check only worries about the default template value, and ignores the
  infinite variety of other possible invalid section values

Is there a way the check could be applied only to new packages?

> > E: ftp-master: library-in-debug-or-profile-should-not-be-stripped
> > This is obviously true for debug, and it makes sense to reject such packages
> > because they're shipping broken debug files; is it certain for profile as
> > well?

> Thats a question for the library overlords, I have far to less
> experience in that area. If not then maybe lintian needs adjustments/a
> new check and we take that.

$ zgrep lib/profile/ ~/ftp/dists/unstable/Contents-i386.gz 
usr/lib/profile/liblockdev.adebug/liblockdev1-dbg
usr/lib/profile/liblockdev.so.1 debug/liblockdev1-dbg
$

  apparently not really an issue in practice; yes, lintian can be
fixed if/when this proves necessary.

> > E: ftp-master: binary-file-compressed-with-upx
> > Where is this documented?  There's no mention of UPX in Debian Policy, and
> > the only mention in the lintian changelog is a 2001 bug about adding support
> > for /reading/ UPX executables.

> There is no such tag, nothing currently in the archive.

Absent a basis in Policy, "nothing uses it" is not really a reason to reject
new packages that might start using it.  AFAICS, this is basically an
unreviewed lintian error.

> > E: ftp-master: html-changelog-without-text-version
> > E: ftp-master: upstream-version-not-numeric
> > E: ftp-master: build-depends-on-essential-package-without-using-version
> > E: ftp-master: depends-on-build-essential-package-without-using-version
> > E: ftp-master: build-depends-on-build-essential
> > E: ftp-master: no-standards-version-field
> > E: ftp-master: invalid-standards-version

> I dont buy your reasoning *at all*, but until further notice I removed them.

Ok, thanks.

When should we expect this to be reflected on ftp-master and
http://ftp-master.debian.org/~joerg/lintian/lintian.tags?  Both still show
these tags in effect.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Lintian based autorejects

[Emilio Pozuelo Monfort]

Steve Langasek wrote:
> On Wed, Nov 04, 2009 at 01:15:57AM +0100, Joerg Jaspert wrote:
>>> E: ftp-master: section-is-dh_make-template
>>> Sections in source packages have minimal impact; the section that matters is
>>> the one specified in the archive override.  There's no reason that the
>>> invalid default value given by dh_make should result in a package being
>>> rejected, when arbitrary other values for the field would not.  Please drop
>>> this check.
> 
>> We tend to simply reject such packages from NEW. So the maintainer can
>> see it instantly triggered this way or has to wait until NEW is
>> processed. I tend to think this way is better.
> 
> I would agree with you except for two things:
> 
> - the check will also be applied to existing packages in the archive which
>   already have overrides, where the source package's section doesn't really
>   matter
> 
> - the check only worries about the default template value, and ignores the
>   infinite variety of other possible invalid section values
> 
> Is there a way the check could be applied only to new packages?

Is there any package in the archive that is triggering this tag? It seems to me
there isn't, so it would already be the case this tag would only be applied for
new packages:

http://lintian.debian.org/tags.html

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: Lintian based autorejects

[Emilio Pozuelo Monfort]

Joerg Jaspert wrote:
> On 11921 March 1977, Steve Langasek wrote:
>> E: ftp-master: debian-rules-is-symlink
>> Not a requirement that's derived from Policy at all.  If you think this is
>> important to require for all packages due to the side effect on lintian's
>> ability to do further checking, please discuss it on debian-policy; in the
>> meantime, please drop.
> 
> Dropped.

Doesn't Policy say debian/rules must be a make file? I'd say a make file is not
the same as a symlink to a make file and thus this is covered by Policy, but if
that's just me we could bring this to debian-policy@ and see if there's
consensus to explicitly forbid symlinks.

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: dir-or-file-in-var-www on single-HTML file web "apps" or the like

[Gunnar Wolf]

Tzafrir Cohen dijo [Wed, Nov 04, 2009 at 09:11:42AM +]:
> On Wed, Nov 04, 2009 at 08:49:54AM +0100, Stefano Zacchiroli wrote:
> > On Wed, Nov 04, 2009 at 08:08:46AM +0100, sean finney wrote:
> > > > We have webservers other than Apache.
> > 
> > When raising this kind of counter argument, is usually nice to also
> > provide (pointers to) solutions :-)
> 
> "For apache2: 
> 
> 
> 
> Alternatively, just use the following command to make the package work
> with any httpd:
> 
>   ln -s /var/www/FOO ../../usr/share/foo
> "

In fact, as the Cherokee package maintainer, I put the base webserver
root at /usr/share/cherokee/default-site/index.html, and include this
in my postinst:

case "$1" in
configure)
# If there is no index.html, link ours to /var/www
if [ ! -e /var/www/index.html  -a \
 ! -e /var/www/index.cgi   -a \
 ! -e /var/www/index.pl-a \
 ! -e /var/www/index.php   -a \
 ! -e /var/www/index.xhtml -a \
 ! -e /var/www/index.htm ] ; then
ln -s /usr/share/cherokee/default-site/index.html \
/var/www/index.html
if [ ! -e /var/www/cherokee-images ] ; then
# Of course, without the images, our page will be
# quite ugly. But it would be worse to clobber
# something!
ln -s /usr/share/cherokee/default-site/cherokee-images \
/var/www/cherokee-images
fi
fi

So, given the attention to this thread: Do you judge this as
policy-compliant? Of course, I could ship Cherokee defaulting its
document root to /usr/share/cherokee/default-site/, but it does feel
quite awkward. I have been silently following this thread, and of
course, intend on following policy as consensus is reached.

> (...)
> I looked at nginx, lighttpd and cherokee. IIRC aolserver4 and caudium
> are also configurable enough.
> (...)
> cherokee
> 
> Likewise here the package does not seem to have an include directory.
> Thus I can't simply provide a sample configuration snippet for the user
> to copy.
> 
> Furthermore, the rules used in the configuration seem to mee a bit too
> different. It would require a bit testing to even understand them. So
> for the hypothetical package foo I just don't bother.
> 
> See http://www.cherokee-project.com/doc/dev_cherokee.conf.html
> 
> I would tend to add sample apache configuration, test it, and have the
> package Suggest apache in addition to Depend-ing on httpd or httpd-cgi.
> This way I know I have something I tested to work. As close as possible
> with the "Just Works" factor to the simple symlink.

The Cherokee configuration file, although is hand-editable, is meant
to be managed by cherokee-admin. Anyway, a similar snippet would be:

vserver!1!rule!2!match = directory
vserver!1!rule!2!match!directory = /foo
vserver!1!rule!2!handler = file
vserver!1!rule!2!document_root = /usr/share/foo

But of course, this would require it to be the second rule on the
first vserver — This would be in any case ideally managed by a
command-line utility (which as of right now does not exist ;-) )

Of course... I highly value Debian's ability to have just-installed
package in a state that just-works. We do have /usr/lib/cgi-bin, which
achieves this goal - And I support the idea of having a
/var/lib/www-root or something along those lines to serve as a
canonical document root if the user does not specify otherwise.

Greetings,

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


signature.asc
Description: Digital signature

Re: Cross compiler ITP (armel)

[Goswin von Brederlow]

Neil Williams  writes:

> On Tue, 03 Nov 2009 20:22:14 +0100
> Goswin von Brederlow  wrote:
>
>> Hector Oron  writes:
>> 
>> > Hello,
>> >
>> > 2009/11/2 Goswin von Brederlow :
>> >> Why do you need --sysroot support? Or what prevents a --sysroot
>> >> of / when using the multiarch directories?
>> >>
>> >> It seems like wasted work with multiarch being a release goal for
>> >> squeeze. Hop on the wagon and make it work for you too.
>
> There is merit in having sysroot for toolchain building and multiarch
> for toolchain usage. sysroot would then be internal to the toolchain
> build.
>
>> > As you already know, multiarch does not have a plan (yet) for -dev
>> > packages. In terms of cross compiling, things are unclear which way
>> > is painless sysroot or multiarch (orthogonal solutions). The more I
>> > think, the more I believe sysroot is painless.
>
> As mentioned off-list, I disagree strongly. sysroot - as it
> appears at the moment - retains the hacks in dpkg-cross which means that
> cross-building anything more complex than a trivial rootfs becomes
> impossible. Cross-building needs to stop requiring package hacks,
> package renaming, version string hacks and the consequent complicated
> changes to the dependency chain.

To be fair that doesn't help NOW. While I agree cross-building should
use the multi-arch directories that will be in preparation of
multi-arch becoming a reality. Until such a time dpkg-cross/apt-cross
still need to do the renaming hacks. But all those hacks are well
understood and existing.

So what I'm suggesting is doing it with hcks now in such a way that
multiarch will remove the remaining hacks when it becomes reality.

>> Your cross-libfoo-dev package would have to solve this.
>
> Changing package names is not acceptable - that is what is causing the
> current logjam. The cross package needs to retain correlation with the
> file in the archive so that the foreign package can be upgraded
> alongside the native arch package and so that the foreign package can
> be installed whilst taking into account the existing Arch:all
> dependencies.
>
> In essence, 'apt-get upgrade' would need to be able to upgrade the
> native arch and the foreign arch at the same time - or at least tell
> the user that the native upgrade also needs a few foreign packages
> upgraded. Otherwise, what happens (now) is that as the foreign package
> (with a changed package name) cannot be correlated with the package from
> which it was built, the built package is therefore removed (with all
> it's foreign reverse dependencies) if there is any kind of transition.
> The removed foreign packages then need to be reinstalled all over again,
> once the native packages have upgraded. Even if the resulting process
> actually does this, it's better to do this in one operation. Merely
> allowing the frontend to realise that the foreign package has been
> updated in the archive, makes it possible.

Well, ia32-apt-get did it just fine and all automatic. There also was
no foreign package with changed name in the archive but the original
foreign package was used. But none the less the converted foreign
package had the right "Source:  (version)" information giving
a clear correlation between the converted package and the source it
was build from. Also in any kind of transition the source
transitions. That means both the native and foreign package change
their source and therefore binary version. They are always both
updated and transitioned together. As for forcing both the native and
foreign package to be upgraded by the user as pair that is a simple
Depends. So that really isn't a problem. It is just a matter of
getting the information at the proper place.

The usage is verry simple with ia32-apt-get:

ia32-apt-get update
ia32-apt-get [dist-]upgrade

Or with "ln -s /usr/share/ia32-apt-get/* /usr/local/bin" you can even
save the ia32- prefix. Get your apt-cross to be equaly user friendly.

> The problems are outlined in #502433. The dependency calculations need
> to take account of what is already installed as foreign without native
> versions being considered, yet still take account of Arch:all - AFAICT
> multiarch allows this mode. For it to work, the package actually
> installed has to retain a correlation to what is in the Packages file,
> so that the correct dependency chain can be constructed. Changing
> package names (or even version strings due to strict versioned
> dependencies) in such situations is only going to lead to
> non-installable combinations, as we have now.

ia32-apt-get does this by changing the Packages files post download
and only renaming packages that need to be foreign. There is
absolutely no reason the same renaming can not be applied to Sources
and control files for Build-Depends. That way anything (like apt,
dpkg, sbuild) looking at the Packages, Sources or debian/control files
sees the correct dependency chain and will install exactly the same
packages with the renaming or with multiarch. And a

Re: Cross compiler ITP (armel)

[Hector Oron]

Hello,

2009/11/4 Goswin von Brederlow :
> Neil Williams  writes:

While being highly interesting talk to me, this discussion is no
relevant to the ITP. I would suggest to either fork the thread or
discuss at debian-embed...@l.d.o

Thanks ! I appreciate your comments.

-- 
 Héctor Orón


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

Re: dir-or-file-in-var-www on single-HTML file web "apps" or the like

[Stefano Zacchiroli]

On Wed, Nov 04, 2009 at 10:19:13AM +0100, sean finney wrote:
> > OK on those without Alias, but how about whose that do have Alias-es? Do
> > you have a list of them and which file ship? Do you have some kind of
> > intermediate level where the maintainer can specify the Alias only once
> > and have it "compiled" to all web server configurations?
> 
> nope, but i assume if there are folks who feel this itch it will get
> scratched :)  this type of information would be really good to have
> in footnotes or an appendix in the webapps policy or some other best
> practices document.

OK (and thanks to Tzafrir for all detailed info on the various web
servers). Given the heterogeneity of them, and in particular the fact
that most of them do not have a .d/ directory where packages can drop
their snippet, I presume that the following procedure would be
appropriate for fixing the current dir-or-file-in-var-www issues.

- create a dir for the package static content
- in it create s index.html if needed
- ship Apache configuration as a conf.d/ snippet (with Alias)
- document in README.Debian where the static content is (so that admins
  of other web servers know what needs to be done by hand)
- document in NEWS.Debian that the (apache) base URL to access the
  package functionality has changed and that there is no backward
  compatibility

> > you have a list of them and which file ship? Do you have some kind of
> > intermediate level where the maintainer can specify the Alias only once
> > and have it "compiled" to all web server configurations?
> 
> i think that was the original intention of webapps-common, but once again i
> should point out that this project hasn't gone anywhere in a year or two,
> mostly due to lack of interest/time.

I fully understand that ... and you've my support :-) Not having extra
Debian time slots to offer on those lines, I was just trying to
understand what a random DD (i.e. me) could do to fix the current
outstanding dir-or-file-in-var-www issues according to the _present_
rules and available tools.

BTW, the documented Neil pointed us to is already a very good
achievement of webapps-common! thanks to everybody who has contributed.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: dir-or-file-in-var-www on single-HTML file web "apps" or the like

[Stefano Zacchiroli]

On Wed, Nov 04, 2009 at 07:51:44AM -0600, Gunnar Wolf wrote:
> Of course... I highly value Debian's ability to have just-installed
> package in a state that just-works. We do have /usr/lib/cgi-bin, which
> achieves this goal - And I support the idea of having a
> /var/lib/www-root or something along those lines to serve as a
> canonical document root if the user does not specify otherwise.

Oh yes, that would be awesome, but I doubt it would be anywhere near to
be obtainable in Squeeze time. Maybe you can store this somewhere in a
PostSqueeze discussion page?

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: dir-or-file-in-var-www on single-HTML file web "apps" or the like

[Holger Levsen]

Hi,

On Mittwoch, 4. November 2009, Stefano Zacchiroli wrote:
> Oh yes, that would be awesome, but I doubt it would be anywhere near to
> be obtainable in Squeeze time. Maybe you can store this somewhere in a
> PostSqueeze discussion page?

Uhm, why postpone this so long? I'd hope we could find a consensus quite soon. 
Then, we might not be able to fix _all_ web apps until squeeze, but at least 
tthose few with dir-or-file-in-var-www :-)


regards,
Holger


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

Re: /var/www is depracated, which directory to use?

[Holger Levsen]

Hi Tom,

On Montag, 2. November 2009, Tom Feiner wrote:
> Is /var/cache really such a bad option? I mean, the entire web content
> is re-generated from templates & graphs are re-generated from the rrd
> databases every 5 minutes. So even if someone did delete the directory,
> it'll just be recreated up to 5 minutes later.

It might be bad if the directory is gone and the webserver refuses to start 
because of a non-existing DocumentRoot... 


regards,
Holger


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

Re: /var/www is depracated, which directory to use?

[Stephen Gran]

This one time, at band camp, Holger Levsen said:
> Hi Tom,
> 
> On Montag, 2. November 2009, Tom Feiner wrote:
> > Is /var/cache really such a bad option? I mean, the entire web content
> > is re-generated from templates & graphs are re-generated from the rrd
> > databases every 5 minutes. So even if someone did delete the directory,
> > it'll just be recreated up to 5 minutes later.
> 
> It might be bad if the directory is gone and the webserver refuses to start 
> because of a non-existing DocumentRoot... 

Apache will explode if the log directory doesn't exist, but it usually
just returns internal server error if the docroot is missing.  Maybe
some of the other web servers we ship aren't quite as tolerant, but I
have less experience with them.  And frankly, that's a "don't do that,
then" moment, really.  It is perfectly safe (if foolish) to delete the
_contents_ of /var/cache/munin, and I don't recall the FHS saying that
it expected applications to cope gracefully with the directory structure
being yanked out from under them by addled admins.

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: /var/www is depracated, which directory to use?

[Holger Levsen]

Hi,

On Mittwoch, 4. November 2009, Stephen Gran wrote:
> _contents_ of /var/cache/munin, and I don't recall the FHS saying that
> it expected applications to cope gracefully with the directory structure
> being yanked out from under them by addled admins.

Right. (It only says apps have to cope gracefully with deleted files.)


regards,
Holger


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

Re: Cross compiler ITP (armel)

[Neil Williams]

On Wed, 04 Nov 2009 15:11:06 +0100
Goswin von Brederlow  wrote:

> > As mentioned off-list, I disagree strongly. sysroot - as it
> > appears at the moment - retains the hacks in dpkg-cross which means that
> > cross-building anything more complex than a trivial rootfs becomes
> > impossible. Cross-building needs to stop requiring package hacks,
> > package renaming, version string hacks and the consequent complicated
> > changes to the dependency chain.
> 
> To be fair that doesn't help NOW. 

Of course, but 'now' is stuck in a dead end. Please accept that the
dpkg-cross/apt-cross hacks are a complete dead end. Sometimes it is
best to abandon one direction and start afresh. I maintained the
existing hacks and wrote quite a few of my own to get the system to the
point where we could have Emdebian Crush 1.0 - I can honestly say that
I believe there is no "now" for dpkg-cross/apt-cross methods.

If the RFH for apt-cross does not result in any new work, I'm
considering turning it into an RM: before the Squeeze freeze - I'll
almost certainly be turning the RFH into an O: unless someone comes
forth.

> While I agree cross-building should
> use the multi-arch directories that will be in preparation of
> multi-arch becoming a reality. Until such a time dpkg-cross/apt-cross
> still need to do the renaming hacks. But all those hacks are well
> understood and existing.
> 
> So what I'm suggesting is doing it with hcks now in such a way that
> multiarch will remove the remaining hacks when it becomes reality.

I'm not sure what is gained by putting more work into a broken system.

apt-cross is dead, if I hadn't nailed it to ftpmaster it'd be pushing
up the daisies already. It's not so much gone to meet it's maker, it's
been given up for dead by it's author!

$ perl -e 'print "parrot\n" if ($apt-cross =~ "/Norwegian blue/");'
$ parrot

(apologies to Mr's Palin & Cleese.)

> Well, ia32-apt-get did it just fine and all automatic. There also was
> no foreign package with changed name in the archive but the original
> foreign package was used. But none the less the converted foreign
> package had the right "Source:  (version)" information giving
> a clear correlation between the converted package and the source it
> was build from. Also in any kind of transition the source
> transitions. That means both the native and foreign package change
> their source and therefore binary version. They are always both
> updated and transitioned together. As for forcing both the native and
> foreign package to be upgraded by the user as pair that is a simple
> Depends. So that really isn't a problem. It is just a matter of
> getting the information at the proper place.
> 
> The usage is verry simple with ia32-apt-get:
> 
> ia32-apt-get update
> ia32-apt-get [dist-]upgrade
> 
> Or with "ln -s /usr/share/ia32-apt-get/* /usr/local/bin" you can even
> save the ia32- prefix. Get your apt-cross to be equaly user friendly.

apt-cross cannot support this kind of action, it would need a complete
rewrite. I certainly do not have time to consider any such effort.

> > The problems are outlined in #502433. The dependency calculations need
> > to take account of what is already installed as foreign without native
> > versions being considered, yet still take account of Arch:all - AFAICT
> > multiarch allows this mode. For it to work, the package actually
> > installed has to retain a correlation to what is in the Packages file,
> > so that the correct dependency chain can be constructed. Changing
> > package names (or even version strings due to strict versioned
> > dependencies) in such situations is only going to lead to
> > non-installable combinations, as we have now.
> 
> ia32-apt-get does this by changing the Packages files post download
> and only renaming packages that need to be foreign. There is
> absolutely no reason the same renaming can not be applied to Sources
> and control files for Build-Depends. That way anything (like apt,
> dpkg, sbuild) looking at the Packages, Sources or debian/control files
> sees the correct dependency chain and will install exactly the same
> packages with the renaming or with multiarch. And a normal
> dpkg-checkbuilddeps would also detect missing or wrong packages just
> like in the non-cross case.
> 
> But what has that got to do with #502433?

502433 is about the inability to accurately use such hacks to get a
clean dependency path from a clean chroot to a full libgtk2.0-dev build
environment using foreign packages.

If you hack around the package names, the careful work of dozens of
maintainers is thrown at /dev/null. It's not surprising that things
break as soon as you try something remotely complicated.

> That looks to me to be 2 bugs:
> 
> 1) The libkrb5-dev explicitly mentioned in debian/xcontrol does not
> override the heimdal-dev in debian/control.
> 
> 2) The heimdal-dev-cross package contains a broken library or misses
> one. It seems to fall back to the native library, which has the wrong
> fil

cross-building, apt-cross and multiarch

[Neil Williams]

On Wed, 4 Nov 2009 15:20:31 +0100
Hector Oron  wrote:

> Hello,
> 
> 2009/11/4 Goswin von Brederlow :
> > Neil Williams  writes:
> 
> While being highly interesting talk to me, this discussion is no
> relevant to the ITP. I would suggest to either fork the thread or
> discuss at debian-embed...@l.d.o
> 
> Thanks ! I appreciate your comments.

It's been discussed at length on debian-embedded already. If there are
further discussions on -devel, I'll try and change the subject lines.

Didn't get a chance to do that with the longer post - sent before I
read this one.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpLdsBgXYICh.pgp
Description: PGP signature

Re: /var/www is depracated, which directory to use?

[Tom Feiner]

Hi,

> On Wed, Nov 4, 2009 at 5:12 PM, Holger Levsen  wrote:
>> Hi Tom,
>>
>> On Montag, 2. November 2009, Tom Feiner wrote:
>>> Is /var/cache really such a bad option? I mean, the entire web content
>>> is re-generated from templates & graphs are re-generated from the rrd
>>> databases every 5 minutes. So even if someone did delete the directory,
>>> it'll just be recreated up to 5 minutes later.
>> It might be bad if the directory is gone and the webserver refuses to start
>> because of a non-existing DocumentRoot...
>>

Well, all we're doing is defining an alias with a DocumentRoot and at
least in apache2, it handles it gracefully, returning a 404 Not Found
'The requested URL /munin/ was not found on this server'. Also, apache
restarts work fine.

We will have to test it with the rest of the major webservers to make
sure they're also ok with this, but I expect it'll work the same.

Tom



signature.asc
Description: OpenPGP digital signature

common, FHS-compliant, default document root for the various web servers

[Stefano Zacchiroli]

[ adding -policy to Cc: ]

On Wed, Nov 04, 2009 at 04:08:02PM +0100, Holger Levsen wrote:
> Uhm, why postpone this so long? I'd hope we could find a consensus quite 
> soon. 
> Then, we might not be able to fix _all_ web apps until squeeze, but at least 
> tthose few with dir-or-file-in-var-www :-)

I see it a tad more complicate than you, let's hope its me
overestimating the task :-)

- the agreement actually should not come among web app maintainers, but
  rather among web *server* maintainers: they should agree over a
  specific dir and change the default configuration of the web server so
  that that dir is the document root (for the default vhost, for web
  servers supporting vhosts)

  * possibly, migrating to that would require offering migration paths
to package users

- then you might start migrating web apps packages so that they install
  (static) stuff under that dir, preserving the per-package path as
  detailed in the webapps-common policy

- then, the rule should go into policy (possibly under §9.1.1, has an
  exception to FHS, not sure about the section though) and that can't
  happen before due to the usual practice-should-predate-policy

If it were me to try to achieve this, I would go for a DEP to keep track
of consensus, ... but no, I'm not willing to drive this, at least not
now :-)

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: dir-or-file-in-var-www on single-HTML file web "apps" or the like

[Cyril Brulebois]

Gunnar Wolf  (04/11/2009):
> So, given the attention to this thread: Do you judge this as
> policy-compliant?

What makes me wonder a bit is what would happen in case several
webservers were to implement this kind of behaviour. When installing
several of them at the same time, the resulting contents of /var/www
would depend on the order in which “configure” are called? That would
sound strange to me.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: common, FHS-compliant, default document root for the various web servers

[Gunnar Wolf]

Stefano Zacchiroli dijo [Wed, Nov 04, 2009 at 05:50:01PM +0100]:
> > Uhm, why postpone this so long? I'd hope we could find a consensus quite 
> > soon. 
> > Then, we might not be able to fix _all_ web apps until squeeze, but at 
> > least 
> > tthose few with dir-or-file-in-var-www :-)
> 
> I see it a tad more complicate than you, let's hope its me
> overestimating the task :-)
> 
> - the agreement actually should not come among web app maintainers, but
>   rather among web *server* maintainers: they should agree over a
>   specific dir and change the default configuration of the web server so
>   that that dir is the document root (for the default vhost, for web
>   servers supporting vhosts)
> 
>   * possibly, migrating to that would require offering migration paths
> to package users

That's easy, as there is fewer of us than web app maintainers. And it
is a first step. We might even have a transitional symlink making
/var/www point to /var/lib/www or whatnot?

> - then you might start migrating web apps packages so that they install
>   (static) stuff under that dir, preserving the per-package path as
>   detailed in the webapps-common policy
> 
> - then, the rule should go into policy (possibly under §9.1.1, has an
>   exception to FHS, not sure about the section though) and that can't
>   happen before due to the usual practice-should-predate-policy
> 
> If it were me to try to achieve this, I would go for a DEP to keep track
> of consensus, ... but no, I'm not willing to drive this, at least not
> now :-)

It is a bit ambitious to have it _completely_ done by Squeeze. But we
can start pushing the right way. And anyway, I do not feel it is
asking too much. Yes, we cannot just go from using /var/www to
having its existence violate policy and making insta-RC, but as soon
as the (major at least) webserves change their defaults, we can start
filing wishlist bugs, pointing maintainers to this being a work in
progress and expecting it to be strictly enforced by policy for
squeeze+1. 

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


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

Re: dir-or-file-in-var-www on single-HTML file web "apps" or the like

[Gunnar Wolf]

Cyril Brulebois dijo [Wed, Nov 04, 2009 at 05:54:17PM +0100]:
> Gunnar Wolf  (04/11/2009):
> > So, given the attention to this thread: Do you judge this as
> > policy-compliant?
> 
> What makes me wonder a bit is what would happen in case several
> webservers were to implement this kind of behaviour. When installing
> several of them at the same time, the resulting contents of /var/www
> would depend on the order in which “configure” are called? That would
> sound strange to me.

Yes, and it is strange... sometimes I start Apache and get confused
looking at a Cherokee welcome page. But still, as many users and
packages currently depend on just dropping off stuff at /var/www, I
think it is the lesser evil.

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


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

Bug#554431: ITP: yui3 -- Yahoo! User Interface Library Version 3

[Jaldhar H. Vyas]

Package: wnpp
Severity: wishlist
Owner: "Jaldhar H. Vyas" 

* Package name: yui3
  Version : 3.0.0
  Upstream Author : Yahoo! Developers!  
* URL : http://developer.yahoo.com/yui/3/
* License : BSD
  Programming Lang: JavaScript, CSS
  Description : Yahoo! User Interface Library Version 3

YUI 3 is Yahoo!'s next-generation JavaScript and CSS library for 
building richly interactive web applications using techniques such  as DOM 
scripting, DHTML and AJAX.

(Note: this is being packaged seperately because it is API incompatible 
with Version 2 which is already in the archive as the yui package.  It 
will be maintained by the pkg-javascript group.)



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

Bug#554430: ITP: libfilter-crypto-perl -- libfilter-crypto-perl is a library to create runnable Perl files encrypted with OpenSSL libcrypto

[C.J. Adams-Collier]

Package: wnpp
Severity: wishlist
Owner: "C.J. Adams-Collier" 


* Package name: libfilter-crypto-perl
  Version : 1.29
  Upstream Author : Steve Hay 
* URL : http://search.cpan.org/dist/Filter-Crypto/
* License : Perl
  Programming Lang: Perl
  Description : libfilter-crypto-perl is a library to create runnable Perl 
files encrypted with OpenSSL libcrypto

 Filter::Crypto provides a Perl source code decryption filter for running
 files that have been encrypted via the
 Filter::Crypto::CryptFile|Filter::Crypto::CryptFile module.
 .
 You should rarely, if ever, need to touch this module. The encrypted files
 produced by the Filter::Crypto::CryptFile|Filter::Crypto::CryptFile module
 will automatically have the "use Filter::Crypto::Decrypt;" statement added to
 the start of them, which is all that is required to bring this decryption
 filter into play. See perlfilter if you want to know more about how Perl
 source code filters work.

-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



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

Re: common, FHS-compliant, default document root for the various web servers

[Jan Hauke Rahm]

On Wed, Nov 04, 2009 at 11:03:20AM -0600, Gunnar Wolf wrote:
> Stefano Zacchiroli dijo [Wed, Nov 04, 2009 at 05:50:01PM +0100]:
> > > Uhm, why postpone this so long? I'd hope we could find a consensus quite 
> > > soon. 
> > > Then, we might not be able to fix _all_ web apps until squeeze, but at 
> > > least 
> > > tthose few with dir-or-file-in-var-www :-)
> > 
> > I see it a tad more complicate than you, let's hope its me
> > overestimating the task :-)
> > 
> > - the agreement actually should not come among web app maintainers, but
> >   rather among web *server* maintainers: they should agree over a
> >   specific dir and change the default configuration of the web server so
> >   that that dir is the document root (for the default vhost, for web
> >   servers supporting vhosts)
> > 
> >   * possibly, migrating to that would require offering migration paths
> > to package users
> 
> That's easy, as there is fewer of us than web app maintainers. And it
> is a first step. We might even have a transitional symlink making
> /var/www point to /var/lib/www or whatnot?

I don't get it. This would of course solve the problem of FHS compliance
but apart from that it doesn't gain anything, does it?

My understanding of the problem is that we (as in package maintainers)
cannot drop our files in the document root of the system admin; there's
a chance of conflicting files. So, we avoid /var/www as this is meant to
be the sysadmin's place.

Currently packages handle the problem by looking for a safe place, i.e.
/var/cache/$package/html or something and provide a configuration for
the webserver (at least for apache2 this is done by several packages).
/var/www can remain docroot and the webserver still knows about the
newly installed webapp.

If we now introduce a new docroot, /var/www isn't the standard docroot
anymore, so
a) the webserver doesn't know about it and ignores the files of the local
   admin,
b) the admin sees the new docroot and puts his/her files there (which is
   wrong but I'm pretty sure it'll happen).

Now, do I totally misunderstand the issue here, or are we just moving
the /var/www problem to /var/lib/www?

Hauke


signature.asc
Description: Digital signature

Re: Lintian based autorejects

[Russ Allbery]

Steve Langasek  writes:
> On Wed, Nov 04, 2009 at 01:15:57AM +0100, Joerg Jaspert wrote:

>>> E: ftp-master: wrong-file-owner-uid-or-gid
>>> Policy 9.2 does /not/ prohibit shipping files with owners outside these
>>> ranges; it prohibits relying on user or group IDs outside these ranges being
>>> static, but there doesn't appear to be anything in Policy that prohibits
>>> creating the user in the package preinst and then unpacking the package such
>>> that ownership is applied by /name/.  (Unless I'm mistaken, this is
>>> precisely what dpkg does.)

>>> So false-positives are possible with this lintian check, and it should be
>>> overrideable.

>> We currently only have 1 package in the whole archive triggering
>> this. Thats why it is listed.
>> Fine, moved to nonfatal.

> Yes, and that package is not a false-positive - it is genuinely broken and
> should be fixed.  Still, the check itself is unreliable.

I must say, that's a pretty high level of reliability, certainly enough to
keep using "certain" as the certainty in Lintian.  But yes, I suppose it
makes sense to let people override it in the rare case they want to do
this.

> Absent a basis in Policy, "nothing uses it" is not really a reason to
> reject new packages that might start using it.  AFAICS, this is
> basically an unreviewed lintian error.

Correct, I don't believe it's ever triggered.  I suspect it doesn't matter
one way or the other what we do with it for that reason.

-- 
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

Re: common, FHS-compliant, default document root for the various web servers

[Stefano Zacchiroli]

On Wed, Nov 04, 2009 at 07:15:55PM +0100, Jan Hauke Rahm wrote:
> I don't get it. This would of course solve the problem of FHS compliance
> but apart from that it doesn't gain anything, does it?
> Now, do I totally misunderstand the issue here, or are we just moving
> the /var/www problem to /var/lib/www?

No, actually we gain, but it was poorly explained (I've surely
contributed to that).

What I was aiming to is a kind of document root which is under full
control of the package manager; hence where the sysadm cannot touch
anything by hand. That's actually the only way to have a meaningful
package-based namespace.

The property I'd like is that if a package drops static files there
under a dir like package/, then those files automagically appear (in the
default vhost) as http://localhost/package/.

Now, written this way, it looks harder to implement, because it is a
kind of overlay over a default docroot (unless we assume the default
docroot is read-only for the sysadm, which doesn't look reasonable).

I see two solution to this:

- either the final URL is something like
  http://localhost/debian/package/ (replace "debian" with whatever
  prefix you like) and have some other per-web-server mechanism take
  care of adding an Alias/link/whatever from "debian" to that new static
  doc root

- or we add some kind of postinst-time registration mechanism (with all
  the usual drawbacks) that check that new static doc root and register
  every (new) dir there as Alias for the installed web servers. Assuming
  that web servers can register themselves to the mechanism, that would
  also solve the problem that webapp maintainers not necessarily have
  the knowledge of the syntax of all available web servers

Any other idea?

Many thanks for sharpening the analysis, Jan.

Cheers.

PS please keep the -webapps Cc:, I believe it is truly relevant to this
   thread
-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: common, FHS-compliant, default document root for the various web servers

[Jan Hauke Rahm]

I'm commenting a bit between the paragraphs to sharpen my mind :)

On Wed, Nov 04, 2009 at 08:09:18PM +0100, Stefano Zacchiroli wrote:
> What I was aiming to is a kind of document root which is under full
> control of the package manager; hence where the sysadm cannot touch
> anything by hand. That's actually the only way to have a meaningful
> package-based namespace.

I agree. The files installed by the package manager must be seperated
from user/admin files.

> The property I'd like is that if a package drops static files there
> under a dir like package/, then those files automagically appear (in the
> default vhost) as http://localhost/package/.

That would mean dropping all files in whatever dir is configured (in all
available web servers) as DocRoot.

> Now, written this way, it looks harder to implement, because it is a
> kind of overlay over a default docroot (unless we assume the default
> docroot is read-only for the sysadm, which doesn't look reasonable).

Right, either the admin can (and will) write to the DocRoot (which was
meant to be reserved for the package manager), or we need two DocRoots
configured which I don't think is possible with common web servers.

> I see two solution to this:
> 
> - either the final URL is something like
>   http://localhost/debian/package/ (replace "debian" with whatever
>   prefix you like) and have some other per-web-server mechanism take
>   care of adding an Alias/link/whatever from "debian" to that new static
>   doc root

Like all packages drop their files in /var/lib/www/package and some
default package (or the web server itself) drops a symlink
/var/www/debian -> /var/lib/www ?
This would again lead to at least one file name in the sysadmin's space
that he/she can't use which is what we try to avoid in the first place.

> - or we add some kind of postinst-time registration mechanism (with all
>   the usual drawbacks) that check that new static doc root and register
>   every (new) dir there as Alias for the installed web servers.

That is basically what happens today in many cases, except that the
files aren't dropped in one location but rather in /var/cache/$package
or similar. The package's postinst registers the new files/dirs with the
web servers (usually just apache2 and/or lighttpd).

>   Assuming that web servers can register themselves to the mechanism,
>   that would also solve the problem that webapp maintainers not
>   necessarily have the knowledge of the syntax of all available web
>   servers

You mean like a trigger that is dealt with by any web server installed?

> Any other idea?

Actually, I don't see a way to implement that (but then I'm probably not
the best code writer). It would be really nice if the web servers could
somehow register themselves for this but I think in the end this is
really what webapps-common was aimed at, isn't it? Except the
self-registering of web servers webapps-common could solve this all. A
package build-depends on it and gets provided with necessary
post{inst,rm} lines to register with known web servers. Considering that
there are that many web servers in the archive, it should be managable
for webapps-common maintainers to keep up2date with those.

So, after all I think we need some manpower in webapps-common and we
have a solution. Or not?

> Many thanks for sharpening the analysis, Jan.

You're welcome, although I prefer to be called Hauke. I'm a
middle-name-user ;)

> PS please keep the -webapps Cc:, I believe it is truly relevant to
> this thread

Ack, sorry for dropping it before.

Hauke


signature.asc
Description: Digital signature

DEP-5: binary package affected by license $foo

[Frank Lin PIAT]

Hello,

As I was updating the copyright file in a package, I wondered if it
would be useful to add an optional header (named "Binary-Package" or
whatever), to state which binary package is using that file and license.

The rational is that sooner or later, we will want to use the
machine-interpretable copyright file to validate packages freeness,
license compatibilities and so on.

Some sample scenario:

Exemple 1:
> File: doc/info/*
> License: GFDL-NON-FREE
> Binary-Package: none
The package contains a file covered by a not-so-free license, but
that file isn't used to build the binary file. And the file isn't
shipped in the binary files.


Exemple 2:
> File: foo.c
> License: GPL-2
> Binary-Package: foo 
> 
> File: bar.c
> License: GPL-3
> Binary-Package: bar 
The source package contains some files covered by two incompatible
license, but it isn't a problem because the binary aren't combined at
build nor at link time (or example).

Exemple 2:
> File: foo.c
> License: GPL-2
> Binary-Package: foo 
> 
> File: doc/info/*
> License: GFDL-NON-FREE
> Binary-Package: foo-doc-is-non-free
The source package produces both a free and non-free package.


This extra header would be completely optional, and only useful to
white-list some specific situation.

That's just an idea (a foolish idea?)

Franklin


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

Re: DEP-5: binary package affected by license $foo

[Neil Williams]

On Wed, 04 Nov 2009 23:47:52 +0100
Frank Lin PIAT  wrote:

> Hello,
> 
> As I was updating the copyright file in a package, I wondered if it
> would be useful to add an optional header (named "Binary-Package" or
> whatever), to state which binary package is using that file and license.

You'll need a feed from something based on licensecheck from devscripts
so that source packages with thousands of source files can actually be
handled within any remote possibility of reason - and then tie that to
the target listings in Makefile.am and correlate those targets with
lines in the debian/foo.install files? Package splits are going to be
true nightmares.

'licensecheck' itself doesn't always find a licence in files that don't
use particular patterns for the position / comment layout of the
licence text. (IIRC it only checks the first portion of the file.)

Many, many source code files have no licence declaration within the
file itself but come under some arbitrary "collective" assignment which
could be distributed through various other LICENCE or COPYING or other
text files. Directories cannot be taken as only containing files of one
licence either.

Now maintainers need to correlate that moving target with the
changes within individual source code files and within target listings
in Makefile.am and correlate those with the assignments in the
debian/foo.install files?

> The rational is that sooner or later, we will want to use the
> machine-interpretable copyright file to validate packages freeness,
> license compatibilities and so on.

 ... which would only be useful if all (or at least a majority) of
packages were able to create *and maintain* this complex map of licence
meta-data.

Sounds very far fetched to me - and I don't even have any particularly
large source code packages to maintain (just quite a few small to
medium ones).

I wouldn't do this for packages where I am both the Debian maintainer
and the sole upstream developer! (I'd hesitate to even do it for the
simplest native Debian packages that haven't needed large scale updates
since Etch.)

The problem is not obtaining the raw licence data - every maintainer has
to review this data when creating the first package - it is maintaining
that meta-data *and mapping it to individual executable targets and
further to the packages into which those executables are assigned*
through upstream releases across thousands of source code files. These
things are not tracked in the upstream ChangeLog, remember.

This sounds like just as much work as trying to collate a unique and
accurate list of Copyright holders that started the last flame war
about DEP5.
:-(

So upstream adds a single line to a C file, deep in the bowels of a
large package, adding a header file from elsewhere within the same
source package and now the Debian maintainer is meant to not only notice
but check the licence for the code referenced in that header file and
update debian/copyright

If I add a new file to an existing binary package because the new
upstream version builds something useful, I have to research where
*all* the code came from to create that file and might have to update
debian/copyright for that one file???

If upstream add a file that isn't ready for release and isn't going to
be packaged - maybe it's even deleted in the clean target of
debian/rules - I still have to update debian/copyright???

WHY?

Can you even imagine how complex this would be for something like gcc
which builds more binary packages than I care to count?

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpIr5JBEakFi.pgp
Description: PGP signature

Bug#554507: ITP: fjbtndrv -- Linux driver and tools for the tablet buttons of Fujitsu Tablet PCs

[Robert Gerlach]

Package: wnpp
Severity: wishlist
Owner: Robert Gerlach 


* Package name: fjbtndrv
* Version : 2.1.0
* Upstream Author : k...@gmx.de
* URL : http://sourceforge.net/projects/fjbtndrv/
* License : GPL2, GPL3
* Programming Lang: C, Shell
* Description : Linux driver and tools for the tablet buttons of Fujitsu 
Tablet PCs

Description:
Supported Fujitsu tablets:
Lifebook P1510, Lifebook P1610, Lifebook T-series, Lifebook U810 and Stylistic 
ST5-series.


Regards,
  Robert

PS: I'm now looking for a sponsor.



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

Re: Cross compiler ITP (armel)

[Goswin von Brederlow]

Neil Williams  writes:

> On Wed, 04 Nov 2009 15:11:06 +0100
> Goswin von Brederlow  wrote:
>
>> > As mentioned off-list, I disagree strongly. sysroot - as it
>> > appears at the moment - retains the hacks in dpkg-cross which means that
>> > cross-building anything more complex than a trivial rootfs becomes
>> > impossible. Cross-building needs to stop requiring package hacks,
>> > package renaming, version string hacks and the consequent complicated
>> > changes to the dependency chain.
>> 
>> To be fair that doesn't help NOW. 
>
> Of course, but 'now' is stuck in a dead end. Please accept that the
> dpkg-cross/apt-cross hacks are a complete dead end. Sometimes it is
> best to abandon one direction and start afresh. I maintained the
> existing hacks and wrote quite a few of my own to get the system to the
> point where we could have Emdebian Crush 1.0 - I can honestly say that
> I believe there is no "now" for dpkg-cross/apt-cross methods.
>
> If the RFH for apt-cross does not result in any new work, I'm
> considering turning it into an RM: before the Squeeze freeze - I'll
> almost certainly be turning the RFH into an O: unless someone comes
> forth.

I was at a point in ia32-apt-get where I was starting to obsolete
apt-cross, i.e. support for any arch and not just i386 on amd64. But
ftp-master removed ia32-apt-get.

So even if I (or someone else) step up and improve apt-cross that will
just end up in the same place as ia32-apt-get was and get the same
silent removal ia32-apt-get did. Doesn't really make me want to help.

>> While I agree cross-building should
>> use the multi-arch directories that will be in preparation of
>> multi-arch becoming a reality. Until such a time dpkg-cross/apt-cross
>> still need to do the renaming hacks. But all those hacks are well
>> understood and existing.
>> 
>> So what I'm suggesting is doing it with hcks now in such a way that
>> multiarch will remove the remaining hacks when it becomes reality.
>
> I'm not sure what is gained by putting more work into a broken system.
>
> apt-cross is dead, if I hadn't nailed it to ftpmaster it'd be pushing
> up the daisies already. It's not so much gone to meet it's maker, it's
> been given up for dead by it's author!
>
> $ perl -e 'print "parrot\n" if ($apt-cross =~ "/Norwegian blue/");'
> $ parrot
>
> (apologies to Mr's Palin & Cleese.)
>
>> Well, ia32-apt-get did it just fine and all automatic. There also was
>> no foreign package with changed name in the archive but the original
>> foreign package was used. But none the less the converted foreign
>> package had the right "Source:  (version)" information giving
>> a clear correlation between the converted package and the source it
>> was build from. Also in any kind of transition the source
>> transitions. That means both the native and foreign package change
>> their source and therefore binary version. They are always both
>> updated and transitioned together. As for forcing both the native and
>> foreign package to be upgraded by the user as pair that is a simple
>> Depends. So that really isn't a problem. It is just a matter of
>> getting the information at the proper place.
>> 
>> The usage is verry simple with ia32-apt-get:
>> 
>> ia32-apt-get update
>> ia32-apt-get [dist-]upgrade
>> 
>> Or with "ln -s /usr/share/ia32-apt-get/* /usr/local/bin" you can even
>> save the ia32- prefix. Get your apt-cross to be equaly user friendly.
>
> apt-cross cannot support this kind of action, it would need a complete
> rewrite. I certainly do not have time to consider any such effort.

And I would need ftp-masters assurance they won't just silently remove
it before considering working on it.

>> > The problems are outlined in #502433. The dependency calculations need
>> > to take account of what is already installed as foreign without native
>> > versions being considered, yet still take account of Arch:all - AFAICT
>> > multiarch allows this mode. For it to work, the package actually
>> > installed has to retain a correlation to what is in the Packages file,
>> > so that the correct dependency chain can be constructed. Changing
>> > package names (or even version strings due to strict versioned
>> > dependencies) in such situations is only going to lead to
>> > non-installable combinations, as we have now.
>> 
>> ia32-apt-get does this by changing the Packages files post download
>> and only renaming packages that need to be foreign. There is
>> absolutely no reason the same renaming can not be applied to Sources
>> and control files for Build-Depends. That way anything (like apt,
>> dpkg, sbuild) looking at the Packages, Sources or debian/control files
>> sees the correct dependency chain and will install exactly the same
>> packages with the renaming or with multiarch. And a normal
>> dpkg-checkbuilddeps would also detect missing or wrong packages just
>> like in the non-cross case.
>> 
>> But what has that got to do with #502433?
>
> 502433 is about the inability to accurately use such

Re: DEP-5: binary package affected by license $foo

[Ben Finney]

Frank Lin PIAT  writes:

> As I was updating the copyright file in a package, I wondered if it
> would be useful to add an optional header

There is only one header in a DEP-5 copyright file. I think you mean
“add an optional field to the Files section”.

> (named "Binary-Package" or whatever), to state which binary package is
> using that file and license.

> The rational is that sooner or later, we will want to use the
> machine-interpretable copyright file to validate packages freeness,
> license compatibilities and so on.

Interesting. So you think a single source package could produce binary
packages that are each judged differently for their DFSG status? I
wonder what the FTP masters would say to that.

(That could read sarcastically; it's not. I'm interested to know.)

-- 
 \  “Shepherds … look after their sheep so they can, first, fleece |
  `\   them and second, turn them into meat. That's much more like the |
_o__)  priesthood as I know it.” —Christopher Hitchens, 2008-10-29 |
Ben Finney


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

Re: DEP-5: binary package affected by license $foo

[Robert Collins]

On Thu, 2009-11-05 at 13:59 +1100, Ben Finney wrote:
> 
> > The rational is that sooner or later, we will want to use the
> > machine-interpretable copyright file to validate packages freeness,
> > license compatibilities and so on.
> 
> Interesting. So you think a single source package could produce binary
> packages that are each judged differently for their DFSG status? I
> wonder what the FTP masters would say to that.
> 
> (That could read sarcastically; it's not. I'm interested to know.) 

I don't know what the FTP masters will say, but it is, sadly, how
licences interact; given a single upstream that builds two binaries, one
which links to a GPL library, and one that doesn't (and which are
packaged into separate debs), then we've clearly got different
constraints placed on the two debs.

-Rob


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