Re: Bug#1033747: chromium: Build Chromium without the embedded libtiff

[Andres Salomon]

On 7/29/24 16:10, Soren Stoutner wrote:

On Monday, July 29, 2024 1:18:05 AM MST Andres Salomon wrote:

It's unfortunately going to have to wait. We're switching standard
libraries, and linking to external libs is a bit rocky right now.


Waiting until things settle is fine.  This has been an issue for so long that I
have become a patient man.
  

On the plus side, I reduced the time it takes to generate the
orig.tar.xz from ~40 minutes to ~5 minutes, which should help a lot with
testing the deletion of vendored libraries in the future!


That’s impressive.  How did you accomplish that?



Debian's mk-origtargz script (which is what uscan calls) doesn't work 
for us, because 'tar --delete' doesn't scale as d/copyright's 
Files-Excluded increases (see #995770).


Mike (prior chromium maintainer) instead patched mk-origtargz to (1) 
print out the files that would be deleted, (2) untar the _entire_ 
upstream chromium tarball (which at this point is huge at 6.2GB), then 
(3) loops over the list of files to delete, deleting them one-by-one and 
then (4) packing up the new tarball. It worked okay when chromium's 
upstream tarball was roughly 1GB, but it has really ballooned lately.


I replaced the first three steps with a single 'tar --exclude-from', so 
that we save time by not writing deleted files to disk only to manually 
delete them:

https://salsa.debian.org/chromium-team/chromium/-/commit/cd5bf2ed6c848ea054718d8f658aa2b38c681d2c

I would love to get this into mk-origtargz proper so that chromium could 
use uscan (and also everyone in debian maintaining larger packages would 
benefit), but I'm not even sure where to begin. Maybe as a separate 
python mk-origtar tool? Maybe as a patch to mk-origtargz with a 
command-line option to fall back to tar --delete? Perhaps d-d has an idea.



--
I'm available for contract & employment work, please contact me if 
interested.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Security updates for sarge?

[Andres Salomon]

On Sat, 23 Oct 2004 05:10:26 +0200, Sven Mueller wrote:

> Heck, If I were a DD, I would be glad to help whereever needed. The most 
> pressing bits seem to be (from my POV):
> 1) buildd network (especially because of sarge/security)
> 2) ftpmaster (seems to be overwhelmed in work for months now)
> 3) new-maintainer process (though it seems to have sped up considerably
> during the last year)

Hah..

> 4) security team (though I'm not sure how bad the situation is)
> 
> So, if my help is wanted with one of the first three of those, I will 
> gladly file a NM application immediately.
> 

Afaict, James processes NM apps alphabetically, by last name.  You can
probably get through the first few stages of NM in a few weeks (It took me
a little over a month, between submitting my app, to getting
Front Desk approval). So, if you applied now and hurried, I'm betting
you'd become a DD before me.  :/

Re: Ubuntu discussion at planet.debian.org

[Andres Salomon]

On Sun, 24 Oct 2004 09:28:20 +0200, Matthias Urlichs wrote:

> Hi, Henrique de Moraes Holschuh wrote:
> 
>> Is there really a developer out there that doesn't do even the most
>> rudimentary VC by keeping copies of all the source packages he has
>> uploaded/worked on ?
> 
> What for? You can always get your old versions from snapshots.debian.net.
> 

*smirk*.  I'm reminded of a quote...

"Only wimps use tape backup: _real_ men just upload their important stuff 
on ftp, and let the rest of the world mirror it"
-- Linus

Re: Updated SELinux Release

[Andres Salomon]

On Thu, 04 Nov 2004 13:15:44 +, Luke Kenneth Casson Leighton wrote:

> On Thu, Nov 04, 2004 at 01:02:35AM -0600, Manoj Srivastava wrote:
>> On Wed, 03 Nov 2004 21:15:38 -0500, Colin Walters <[EMAIL PROTECTED]> said: 
>> 
>> > On Wed, 2004-11-03 at 19:21 +, Dhruv Gami wrote:
>> >> Personally, i would prefer to have those two tarballs available. I
>> >> know most people using SELinux are familiar with patching the
>> >> kernel, and are generally familiar with how Linux works and know
>> >> their way around on a Linux system.
>> 
>> > But moving forward, we don't want people to have to patch their
>> > kernel or utilities.
>> 
>>  Moving waaay forward. I asked the Debian kernel team to
>>  consider  compiling in SELinux (perhaps disabled by default, for
>>  starters), and was told that that is not going to fly because of
>>  "significant performance hit" one takes by compiling SELinux in.  I
>>  did not have any data to refute the claim, so  that is where we sit.
>  

Manoj, if you're referring to our conversation earlier on IRC, I said that
I have no personal interest in selinux, but I had no problems with it
being included as long as it's not a significant performance hit.  I
requested that you take it up on the debian-kernel list, though.  That
request still stands; the kernel team is not a single person, nor is it
comprised an IRC channel. 


> i had a bun-fight with the people who have taken over from
herbert: at
>   the point where i told them that recompiling applications to be
>   optimised like yoper and gentoo distributions gives back performance
>   far in excess of that lost by selinux, i stopped hearing back from
>   them.
> 

I assume you're referring to #249510, in which Christoph mentioned it was
a 5% performance penalty.  That's significant, especially for people who
don't care about selinux.  Your argument of "well it's not 20%, is it?" is
bogus; throwing features into the kernel, each having a 5% performance
penalty hit, quickly add up.  

Furthermore, this isn't even going to be considered until post-sarge, so
there's little point arguing about it now.  Just like we've told the PAX
people (who, quite frankly, interest me more than the selinux people);
provide solid benchmarks showing exactly how little of a performance hit
the feature is, and we'll be more likely to include it.  Without hard
data, all you have are guesses (2%, 5%, hell, it could be 20% for all we
know.  List your sources).

And yes, different compilers may compile code that runs faster; that's
not news.  That does not mean we're going to slow other parts of the
system down to balance that out, if we obtain any speed benefits with
gcc-3.4.

Re: Updated SELinux Release

[Andres Salomon]

On Fri, 05 Nov 2004 15:57:52 +, Luke Kenneth Casson Leighton wrote:
[...]
>  response 3: _is_ it the job of debian developers to dictate the minimum
>  acceptable security level?

It is the job of the kernel team to maintain the kernel.  That includes
ensuring the kernel runs correctly and quickly in the most common cases,
tailoring the kernel to the needs of our users, and allowing users to
simply drop in a kernel package and have it Just Work.  The same applies
to every other package in debian, really.  The minimum acceptable security
level falls under that, as well.  Most users are happy w/ the standard
unix permission system.  Demands for selinux are relatively new.


> 
>  basically what i mean is, in gentoo, it's a no-brainer: you set options
>  at the beginning of your build, come back [2 weeks? :) ] later and you
>  have a system with PAX stack smashing, lovely kernel, everything
>  hunky-dory.
> 
>  debian doesn't GIVE users that choice [remember the adamantix
>  bun-fight, anyone?] and instead settles for about the lowest possible
>  common denominator - no consideration to modern security AT ALL!
> 

Users always have the choice; that's what kernel-package is for.  Gentoo
requires you compile the kernel; you can do the same in debian to get
your pax/selinux/3rd party patches in your kernel.  Debian also provides
the option to simply download a kernel image, without having to bother
compiling anything.  The trade-off for doing that is that you won't get
your third party patches and unusual features.

I should probably mention that I find your claim about debian not taking
security into consideration quite insulting.  Don't expect people to bend
over backwards to accommodate your requests when you make such
inflammatory remarks.

Re: Always run dpkg --dry-run -i before running dpkg -i!

[Andres Salomon]

On Thu, 06 Jan 2005 23:15:53 +0100, Christoph Hellwig wrote:

> On Thu, Jan 06, 2005 at 04:58:56PM -0500, William Ballard wrote:
>> Apparently the dickhead maintainer of ndiswrapper-source has just gone 
>> into his shell and refuses to discuss this problem.
> 
> Btw, could anyone explain why ndiswrapper is in main?  It's only use
> is to run propritary windows drivers inside the linux kernel, so it's
> a clear fit for contrib.

I believe we had this discussion on IRC; basically, there *are* free
(as in speech) ndis drivers out there.  Whether they're able to be built
and packaged on a debian system; I don't know.

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andres Salomon]

On Sun, 13 Mar 2005 20:45:09 -0800, Steve Langasek wrote:
[...]
> 
> Architectures that are no longer being considered for stable releases
> are not going to be left out in the cold.  The SCC infrastructure is
> intended as a long-term option for these other architectures, and the
> ftpmasters also intend to provide porter teams with the option of
> releasing periodic (or not-so-periodic) per-architecture snapshots of
> unstable.
> 

Releasing a snapshot of unstable definitely seems like a step backwards.
Of course, I understand the reason for suggesting it (and not wanting to
support a testing distribution for SCC).  Instead, I would suggest to
porters that they base releases off Debian stable releases.  When a stable
release comes out, the distribution can be (re)built for all SCC archs;
porters can then add their own packages and fixes on top of stable, as
necessary. This has the added benefit of simplifying security maintenance;
when a DSA is announced, porters can simply rebuild (or incorporate
patches, if necessary) based on the security update.  Developers can still
track unstable from scc.d.o, so as to minimize the work necessary after a
stable release (architecture-specific problems can be found and fixed as
they occur in unstable, instead of suddenly popping up in a stable
release). Porters are also in charge of their own d-i images, so there's
no need to bother the RMs with it.

I assume we'll hear more about what SCC infrastructure will be available
to allow this to work..




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andres Salomon]

On Mon, 14 Mar 2005 14:32:42 +0100, Florian Weimer wrote:
[...]
> 
> I'm a bit disappointed how the decision has been made.  I would have

*Is* it a decision, or is it a proposal?  The wording is unclear.


> hoped that Debian as an organization would be able to reach a workable,
> rough consensus through open discussion.  On the other hand, we might
> have ended up with unprecedented levels of hostility. 8-(

Looks like we're going to have that anyways.  Many people are seeing this
as a decision, handed down by a small group of people.  If that's the
case, then some people are going to be upset.

I personally think the idea is a good one; maintainers can concentrate on
common architectures, and we can potentially have a sane release cycle. 
Meanwhile, porters can have full control of when and what they release,
without being constricted by others' deadlines and such.  Unfortunately,
the naming (second class citizen?), and the feeling that their
architectures are no longer "officially supported", means that people will
view this as a negative thing.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andres Salomon]

On Mon, 14 Mar 2005 15:15:16 +0100, Marc Haber wrote:

> On Mon, 14 Mar 2005 08:54:09 -0500, Andres Salomon
> <[EMAIL PROTECTED]> wrote:
>>On Mon, 14 Mar 2005 14:32:42 +0100, Florian Weimer wrote:
>>> I'm a bit disappointed how the decision has been made.  I would have
>>
>>*Is* it a decision, or is it a proposal?  The wording is unclear.
> 
> I don't think it is unclear at all. The powers that decide have
> shifted a little bit, but they still decide without consulting the
> developer body, which is _very_ disappointing.
> 
> 

There is talk on IRC about this being a proposal (coming from people that
were present at the meeting).  *shrug*.


>>I personally think the idea is a good one; maintainers can concentrate on
>>common architectures, and we can potentially have a sane release cycle. 
>>Meanwhile, porters can have full control of when and what they release,
>>without being constricted by others' deadlines and such.  Unfortunately,
>>the naming (second class citizen?), and the feeling that their
>>architectures are no longer "officially supported", means that people will
>>view this as a negative thing.
> 
> Additionally, they are being excluded from having access to important
> resources, and the possibility of filing RC bugs which is the only way
> to get lazy maintainers moving is being taken away.
> 

That's an awfully pessimistic view.  All porters need is some sort of
leverage that allows them to force maintainers to accept or deal w/
their patches; perhaps some QA team members who will NMU
poorly-maintained packages on behalf of porters?  The amd64 crew seems to
be getting along ok w/out having their FTBFS bugs considered RC..




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andres Salomon]

On Mon, 14 Mar 2005 19:59:43 +, Alastair McKinstry wrote:

> On Luan, 2005-03-14 at 16:16 +0100, David Schmitt wrote:
>> On Monday 14 March 2005 12:05, Robert Lemmen wrote:
>> > - there must be a way for a scc arch to get a stable release. why don't
>> >   we either keep testing for scc archs but not do releases, so the
>> >   porters can do their own stable releases of their arch or have
>> >   per-arch testing? (the latter might lead to a source package explosion
>> >   i think)
>> 
>> AFAI can tell, anybody can host an archive of packages built from stable 
>> sources for a scc or unofficial port. And - if I read the conditions on 
>> becoming a fully supported Debian arch right - then having security support 
>> for an external pool of this arch is a good indicator that it should be a 
>> fully supported stable release (amongst other things).
> 
> The plan as proposed is that the Debian scc ports are purely builds of
> unstable. Hence this build out of the last release (e.g. etch) becomes a
> subproject of a second-class project of Debian. It effectively has
> little credibility.
> 
> 

I agree 100%; if this were to be made to work, there would need to be a
way for a release done based on etch to be officially blessed by Debian.
That does not mean security updates by Debian; but an announcement and
documentation stating that the official Debian $ARCH team has released
$ARCH for etch, and it can be grabbed from $URL, and security fixes can
be grabbed from $URL.  Ditto for future updates.  Otherwise, you run into
the situation where (due to the internal conflicts we all know will
happen sooner or later) there are two $ARCH releases for Debian, done by
different people, but both called "Debian".


>> If on the other hand nobody can be found to
recompile packages after
>> DSAs are released for this arch, I believe the arch shouldn't be
>> released for Debian as stable.
> 
> This is the important part. The point of a release is that (1) it works
> (2) A promise that it _will be maintained_ ; that there will be security
> fixes, and eventually an upgrade path.
> 

One of the major points of this proposal is that Debian does not want to
*promise* security updates for an architecture which is not widely used.
Instead, it is up to the porters to promise such a thing.  This relies on
having the proper manpower on the architecture's team (shouldn't be a
problem for any architecture which people actually use), as well as having
an organizational structure that allows for consistent, quality security
updates (ie, by having one or two people do the security updates), while
at the same time allowing for other people to step in if the main security
people become MIA (for reasons of work, real life, etc).




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andres Salomon]

On Mon, 14 Mar 2005 16:45:10 +0100, Sven Luther wrote:

> On Mon, Mar 14, 2005 at 10:16:19AM -0500, David Nusinow wrote:
[...]
>> 
>> What about the *massive* issues with releasing d-i due to syncing on all
>> arch's? What about the various arch-specific kernel issues that have popped 
>> up
> 
> This will be solved in etch, or even as soon as sarge is out of the way, when
> we will have a single kernel-source package that will generate all binary
> kernel packages. This kernel-package could also build the binary .udeb
> modules, and all the d-i related kernel problems will vanish in one go.
> 
> I believe the kernel team to be commited and well working (and full of loving
> relationships or whatever :), to handle this well.
>

Heh, I don't know if I'd used the word "solved".  :)

It will certainly be made easier, but we'll still have to deal w/
non-mainstream archs that haven't synched w/ upstream (and the build
failures related to those probably keeping kernels out of testing unless
we forcibly downgrade FTBFS bugs). But yes, it will be quite a relief when
we don't have to track kernels (and bugs on those kernels) generated from
20 different source packages...


>> and the problems in getting people to make all the necessary
fixes?
>> What about the huge problems in getting a decently new release of X in
>> to Debian because of constant porting problems?
> 
> And we are proud of the quality of our X packages, are we not, and would
> we reach this quality without the input of the many porters we are going
> to let out in the cold ?


Also, let's remember that a large part of the problem w/ X was that
upstream did not bother to think about architectures other than x86.  I
believe this is no longer a problem w/ xorg.





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andres Salomon]

On Mon, 14 Mar 2005 09:42:20 -0800, Matt Zimmerman wrote:
[...]
> 
> - Both in public[0] and in private, Martin Pitt (acting in an Ubuntu role)
>   and others from the Ubuntu community have been collaborating with the
>   Debian security team on patches for a wide range of vulnerabilities
> 

Yes, I would like to reiterate that coordination between Martin Pitt, the
Ubuntu kernel team, and the Debian kernel team has been an invaluable
resource for Debian; there are a lot of security fixes in Debian
kernels that were brought to my attention by either Fabio or Martin.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andres Salomon]

On Mon, 14 Mar 2005 19:19:32 +0100, Julien BLACHE wrote:

[...]
> 
> You'll figure out that the timing for this new policy is absolutely
> perfect; we're a week away from the voting period for the new DPL
> term. The current DPL can't (and won't, obviously) do anything about
> it, and the candidates signed the proposal. I should add that the
> Vancouver meeting was announced at the very last minute, too. And I'm
> wondering, who paid for the travel expenses ? Did the people involved
> pay out of their own pocket ? Did the Project pay ? Did somebody else
> pay the bill ?
>   

Who cares?  How is that even remotely relevant to the actual proposal? 
How is an answer going to be even remotely beneficial to this discussion?

>>> I joined the Project because there was no core team to decide what was
>>> to be done in an authoritative manner. Today, we have such a core
>>> team, and I'm not sure I agree with that anymore (some would rather
>>> say it's a cabal, well, their call).
>>
>> And yet no chance to replace the cabal nor elect other people instead
>> of them, which is more like a problem for the project than just a few
>> archs, imho.
> 
> We can.
> 
> I hereby ask the people involved in this proposal to step down
> immediately from their positions in the Project. You've violated a
> couple of rules already, and you've violated the spirit of this Project.
> 

*blink*.  Are you high?  One of the RMs makes an announcement stating that
we're *almost* ready to freeze sarge, and you're asking RMs and FTPMasters
to resign?  What will that solve, at this point?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andres Salomon]

On Mon, 14 Mar 2005 17:03:46 -0600, John Goerzen wrote:
[...]
> There is no longer going to be any such thing as a standard Debian
> installation.  Each box, and each snapshot, could have different
> versions of important packages -- everything from glibc to KDE or Gnome.
> The user experience will be different, the security updates -- if they
> exist -- will be different, effect different packages, and bear
> different versions.  Not to mention that all of these are different than
> the real stable release.
> 
> In short, an administration nightmare worse than Gentoo.

..And this is why I recommend basing releases on stable, rather than
arbitrary snapshots of unstable.  Doing a snapshot of unstable just seems
silly; you might as well stop calling it Debian.





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andres Salomon]

On Tue, 15 Mar 2005 01:14:30 +0100, Sven Luther wrote:

> On Mon, Mar 14, 2005 at 06:10:30PM -0500, Andres Salomon wrote:
>> On Mon, 14 Mar 2005 09:42:20 -0800, Matt Zimmerman wrote:
>> [...]
>> > 
>> > - Both in public[0] and in private, Martin Pitt (acting in an Ubuntu role)
>> >   and others from the Ubuntu community have been collaborating with the
>> >   Debian security team on patches for a wide range of vulnerabilities
>> > 
>> 
>> Yes, I would like to reiterate that coordination between Martin Pitt, the
>> Ubuntu kernel team, and the Debian kernel team has been an invaluable
>> resource for Debian; there are a lot of security fixes in Debian
>> kernels that were brought to my attention by either Fabio or Martin.
> 
> Because they are in the security-announce-loop and we are not though, right ? 
> 

Somewhat.  Occasionally I'll be kept in the loop by Joey, but that's more
the exception than the rule.  I can't blame him, though; he's quite busy
(he's going to have to summarize all this crap for DWN soon, for example
:). Instead, I blame vendor-sec for their rather lame non-disclosure
policies (but that's besides the point).



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Andres Salomon]

On Tue, 15 Mar 2005 18:02:07 +0100, Marc 'HE' Brockschmidt wrote:
[...]
> This would be a lot like the current amd64 effort, but with more
> formalized procedures. If the porters can't do it, their arch won't
> block the release process, but if they work hard enough, they can
> release together with the main architectures - and on the same code
> base, which would easen security support.
> 

I certainly like the idea of updating the main distribution w/ porter
fixes at some point; whether it's before the release (which could put a
strain on RMs, introduce potentially destabilizing changes during a
freeze, etc), or after a release (debian 3.2 is released, followed by
3.2r1, which includes security fixes as well as a bunch of changes needed
by porters for various architectures; well tested fixes, as well, for
people using stable w/ stable-proposed-updates in their sources.list doing
the testing).



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Andres Salomon]

On Tue, 15 Mar 2005 08:51:30 -0800, Matt Zimmerman wrote:

> On Tue, Mar 15, 2005 at 09:50:22AM +0100, Sven Luther wrote:
[...]
> 
>> To have proper security-in-testing-or-unstable for the kernel, the
>> debian-kernel security team, or at least a few members of it, need to be made
>> aware of the embargoed security holes, and get a chance to fix them in
>> advance, maybe with a private or security non-public copy of our svn tree
>> (using svk maybe).
> 
> Herbert Xu used to fill this role.  After he resigned, William Lee Irwin (I
> believe) volunteered to be the point of contact for security issues.  If
> William is not active in this role, the kernel team should nominate someone
> else who can be trusted by the security team to work on sensitive issues,
> and have them contact the security team.

I have contacted Joey about this.  He said he would try and keep me in the
loop when he remembers, which is not quite what I was hoping for.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Andres Salomon]

On Tue, 15 Mar 2005 10:35:19 +0100, Sven Luther wrote:

> On Tue, Mar 15, 2005 at 04:21:21AM -0500, Joey Hess wrote:
>> Sven Luther wrote:
[...]
>> > 
>> > This is not a ubuntu related problem though, and the help the ubuntu
>> > kernel/security team has provided us was invaluable, but it should maybe 
>> > not
>> > be necessary if the information was not unrightfully hold from us in the 
>> > first
>> > time.
>> 
>> You seem to be implying that ubuntu is providing you with confidential
>> prior warning about kernel security holes, but I really doubt this,
> 

Actually, that was the case for a while (before ubuntu's kernel team went
on vacation, and I went on vacation).  However, w/ all the vacations
that have been happening, it hasn't been the case for a few months.


> Nope, but i was at one time
hinted that i should wait a couple of days
> before starting a 12 hours build.
> 
>> since many of the ubuntu secutity advisories that I've backchecked
>> against the debian kernels have turned out to still be unfixed in the
>> kernel teams's svn weeks later.
> 
> There is nobody actively doing debian security for unstable kernels
> right now, well, not consistently, and not with the kind of advance
> warning that is needed. This is rather a disapointement, i believe. But
> i understand that our security team doesn't want or can care about
> unstable/testing security updates.

Unfortunately, we don't have any real database of vulnerabilties to ensure
that they're fixed.  I've been using
http://people.ubuntu.com/~pitti/ubuntu-cve.html, but that's about it.  The
official CAN database is close to useless, as the CAN descriptions are
generally not publically available for weeks after the vulnerability is
publically known.  As well, each kernel release is quite a pain due to the
time involved in building and coordination across architectures (I've had
my releases tagged and then backed out, for example); so, that combined w/
the rate of kernel vulnerability generally means we stick to a
release schedule of once or twice a month for each kernel (which ranges
from 2 or 3, since we have to track 2.6.8 specifically for sarge, as well
as the latest 2.6.x kernel, plus 2.6.x-1 if 2.6.x is rotting in NEW).  We
end up having anywhere from 5-10 security-related patches in each release.

For example, I just released kernel-source 2.6.8-14, but have not bothered
to build a kernel-image for i386 yet, as horms committed another security
fix to SVN for -15 about a day after I released.  Instead, I guess I'll
make sure he doesn't have any further commits, check ubuntu's latest
kernel advisories, talk to pitti to make sure he doesn't have anything
pending, release -15, and try for an i386 image at that point.  This i386
image will, of course, have to sit around in NEW for a bit, as the ABINAME
needs to be bumped by at least 2 different security related patches in -14.
After that, I'll try some sparc kernel-images for 2.6.8 and 2.6.10.  And
after that, I may even get the chance to look at 2.6.11, but I doubt it;
I'll probably leave that to svenl or something.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Andres Salomon]

On Wed, 16 Mar 2005 01:38:48 -0500, Andres Salomon wrote:

> On Tue, 15 Mar 2005 10:35:19 +0100, Sven Luther wrote:
> 
>> On Tue, Mar 15, 2005 at 04:21:21AM -0500, Joey Hess wrote:
>>> Sven Luther wrote:
> [...]
>>> > 
>>> > This is not a ubuntu related problem though, and the help the ubuntu
>>> > kernel/security team has provided us was invaluable, but it should maybe 
>>> > not
>>> > be necessary if the information was not unrightfully hold from us in the 
>>> > first
>>> > time.
>>> 
>>> You seem to be implying that ubuntu is providing you with confidential
>>> prior warning about kernel security holes, but I really doubt this,
>> 
> 
> Actually, that was the case for a while (before ubuntu's kernel team went
> on vacation, and I went on vacation).  However, w/ all the vacations
> that have been happening, it hasn't been the case for a few months.
> 
> 

Rather, I was mistaken; they were things that had already been made
public.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian/kernel security issues (Was: Re: Bits (Nybbles?) from the Vancouver release team meeting)

[Andres Salomon]

On Wed, 16 Mar 2005 02:14:07 -0500, Andres Salomon wrote:

> On Wed, 16 Mar 2005 01:38:48 -0500, Andres Salomon wrote:
> 
>> On Tue, 15 Mar 2005 10:35:19 +0100, Sven Luther wrote:
>> 
>>> On Tue, Mar 15, 2005 at 04:21:21AM -0500, Joey Hess wrote:
>>>> Sven Luther wrote:
>> [...]
>>>> > 
>>>> > This is not a ubuntu related problem though, and the help the ubuntu
>>>> > kernel/security team has provided us was invaluable, but it should maybe 
>>>> > not
>>>> > be necessary if the information was not unrightfully hold from us in the 
>>>> > first
>>>> > time.
>>>> 
>>>> You seem to be implying that ubuntu is providing you with confidential
>>>> prior warning about kernel security holes, but I really doubt this,
>>> 
>> 
>> Actually, that was the case for a while (before ubuntu's kernel team went
>> on vacation, and I went on vacation).  However, w/ all the vacations
>> that have been happening, it hasn't been the case for a few months.
>> 
>> 
> 
> Rather, I was mistaken; they were things that had already been made
> public.

And, as a perfect example;
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0210

This has already been made public, and has been fixed in Ubuntu kernels
for 2 days.  Sure would be nice the cve folks to let the rest of us in on
it, eh?




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Andres Salomon]

On Fri, 2006-02-17 at 18:00 +0100, Robert Millan wrote:
[...]
> 
> First, I couldn't find any reference to a "GPLed NDIS driver" in ndiswrapper's
> website, like Michael Poole asserts:
> 
>   http://lists.debian.org/debian-devel/2005/01/msg00381.html
> 

I assume he was talking about the CIPE driver; it's linked right from
the main ndiswrapper page.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Andres Salomon]

On Fri, 2006-02-17 at 23:48 +0100, Robert Millan wrote:
> On Fri, Feb 17, 2006 at 12:40:10PM -0500, Andres Salomon wrote:
> > On Fri, 2006-02-17 at 18:00 +0100, Robert Millan wrote:
> > [...]
> > > 
> > > First, I couldn't find any reference to a "GPLed NDIS driver" in 
> > > ndiswrapper's
> > > website, like Michael Poole asserts:
> > > 
> > >   http://lists.debian.org/debian-devel/2005/01/msg00381.html
> > > 
> > 
> > I assume he was talking about the CIPE driver; it's linked right from
> > the main ndiswrapper page.
> 
> I see.  From http://cipe-win32.sourceforge.net/ :
> 
>   "CIPE-Win32 is a port of Olaf Titz's CIPE package from Linux to Windows NT."
> 
> I think this is the cipe-source package in debian.  If this driver is already
> available, there's no much point in using it via ndiswrapper.
> 
> Is there any other free ndis driver?
> 

I have no idea; I don't particularly care.  I don't see the point of
this whole discussion.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Andres Salomon]

On Sun, 2006-02-19 at 11:34 +0100, Marco d'Itri wrote:
> On Feb 19, Robert Millan <[EMAIL PROTECTED]> wrote:
> 
> > Nevertheless, if you think abiword and openoffice.org should be moved then 
> > go
> > for it.  Just don't use them as excuse to turn warez wrappers into "generic"
> > driver interfaces.
> No excuses are needed, the definition of contrib is enough and
> ndiswrapper has been uploaded to main using the same criteria which have
> been used in the past for emulators. Stop rewriting history.
> Please also stop insulting ndiswrapper users and developers by calling
> it a "warez wrapper".
> 

And for fuck's sake, stop filling up my inbox w/ this crap.  I'm not
doing a thing unless either a) you people come to a consensus on the
issue (which you have not in the past threads, and probably never will),
or b) a governing body like the ctte tells me that it should be in
contrib.  Otherwise, it's staying right where it is.  Honestly, I could
care less whether it's in contrib or main, but it was a decision that
was made long ago, and I see no reason to make the change.

Robert, don't you have better things to do w/ your time?  Go fix cdbs
bugs or something.  David Nusinow requested help w/ xorg 7.0 packaging;
maybe you should help him out.  I'm sick and tired of these pointless
discussions.



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

removal of svenl from the project

[Andres Salomon]

Hi,

I am going through the expulsion process to have Sven Luther removed
from the project.  The process is outlined here:
,
and I have already completed step 1.

Step #2 requires the support of some 15 developers.  I am attempting to
find people that are interested in publically seconding my explusion
request.  If you are interested, please email me.  Remember that your
request will be public, and you will have to provide reasons why you
feel that his removal will benefit the project.  I'm looking both for
people who have had conflicts w/ him (logs are always good, too), as
well as people who have just seen the effects of his actions (ie,
unbiased opinions).

Sven has always been a nuisance to deal w/, but up until now I have not
considered this action.  In the past two weeks, the following comments
made by him have changed my mind:

2006-03-07:
 jonas: i hope we never again meet in public, because i promise i
will hit you if i do.

2006-03-14:
svenl> vorlon: so, you think it is correct of jonas to mention
traveller and thanking him for investigating the issue, while fully
ignoring my own contribution ?
<-- vorlon ([EMAIL PROTECTED]) has left
#debian-kernel
 yeah, coward.

Sven's behavior has always been combative (and some might argue
hostile), but this is beyond what is acceptable.  He threatens bodily
harm upon another developer in a public forum, and then a week later
publically insults/taunts a developer (one of the Release Managers,
even), behind his back.  This is incredibly childish, aggressive
behavior, and should not be tolerated within the project (IMO).

Some might argue that we should just kick him from the channel and
remove his commit access to the debian-kernel project, but that does not
solve the problem of him abusing other teams, as well as his abusive
mailing list posts.  He also {co-,}maintains some 47 packages, which
means users for those packages will have to deal w/ him as well.  I
believe it is better if he is removed from the project altogether, as he
damages it more than he helps.

So, if you are interested in seconding the expulsion request, please let
me know.  Please do not turn this into a flamewar; I don't care about
your reasons why people should not be forcefully removed from the
project.  Those who feel this way probably have not had to work w/ Sven
on a team for the past 2 years.



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

Re: removal of svenl from the project

[Andres Salomon]

On Tue, 2006-03-14 at 21:01 -0500, Andres Salomon wrote:
[...]
> Sven has always been a nuisance to deal w/, but up until now I have not
> considered this action.  In the past two weeks, the following comments
> made by him have changed my mind:
> 
> 2006-03-07:
>  jonas: i hope we never again meet in public, because i promise i
> will hit you if i do.
> 
> 2006-03-14:
> svenl> vorlon: so, you think it is correct of jonas to mention
> traveller and thanking him for investigating the issue, while fully
> ignoring my own contribution ?
> <-- vorlon ([EMAIL PROTECTED]) has left
> #debian-kernel
>  yeah, coward.
> 

A few clarifications/comments based upon what people have said:

1) These quotes are examples of his destructive behavior.  One can find
plenty more in the mailing lists.  The ones I supplied here are the ones
that made *me* decide to take action.

2) Yes, I have tried talking to him.  After a number of blowups on the
debian-kernel list, myself and a number of kernel team members have
talked to him to calm him down (and in some cases getting him to
apologize).  The behavior he displays happens repeatedly, despite
warnings and requests that he behave himself.  The rest of the IRC log
from when he threatened Jonas is basically me attempting to show Sven
how destructive his behavior is.  The fact that, a week later, he
continues w/ this behavior (after years of doing the same thing) is why
you're seeing this request.

3) If he was in the NM queue, and you were his AM, would you accept him
after seeing how he behaves?  If not, why is that so different from
kicking him out of the project (other than asking that he be banned from
the lists, but this is a request of the list masters, not the DAM)?  In
that regards, I have a wonderful quote from Sven: "I am not in the AM
queue, so i can be as rude as i want." [0]

I presume he meant the NM queue.

[0] http://lists.debian.org/debian-legal/2004/07/msg00967.html


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

Re: removal of svenl from the project

[Andres Salomon]

On Wed, 2006-03-15 at 11:25 +0100, Pierre Habouzit wrote:
> Le Mer 15 Mars 2006 03:01, Andres Salomon a écrit :
> > Hi,
> >
> > I am going through the expulsion process to have Sven Luther removed
> > from the project.  The process is outlined here:
> > <http://lists.debian.org/debian-devel-announce/2005/08/msg5.html>
> >, and I have already completed step 1.
> 
> I strongly oppose to such an expulsion.

It amazes me that people oppose expulsion, but are perfectly happy to
allow the DAMs to decide whether or not a NM is to be let into the
project.  Why do we trust the DAM's judgement in one scenario but not
the other?


> 
> what is wrong with you ? are you gone completely insane or what ?

I'm tired of discussions immediately degrading into personal insults.  

> 
> I know Sven may sometimes be a bit overpresent in some trolls, he also 
> may answer too quick, without having read the mail he answers to 
> correctly enough. But AFAICT, I've always seen him apologies when he 
> did so (I can provide links if you can't believe me…).
> 

That is not the case.  Furthermore, apologizing repeatedly does not make
his behavior right.


> If you want to expulse any DD that taunts a release manager, a 
> ftp-master or a debian sys-admin, hey, please begin with the recent 
> thread about the NEW queue beeing stuck again. There is a lot of DDs 
> that need you to rule about them.


This is not about taunting a release manager, an ftp master, or a DAM.
This is about repeated aggressive, childish behavior, against a number
of people.  Sven seems to anger almost everyone he works closely with.
The examples I provided are just the tip of the iceberg.  I thought I
explained this in my followup email[0].

[0] http://lists.debian.org/debian-devel/2006/03/msg00621.html


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

Re: removal of svenl from the project

[Andres Salomon]

The DAM has accepted the request; please send seconds directly to
[EMAIL PROTECTED], cc'ing me as well.

For the people who seem to think that there are more constructive ways
of dealing w/ this issue rather than the expulsion process:

http://squishy.cc/svenl.txt

This is a lot from two weeks ago, right after Sven threatened Jonas.  If
he had actually changed his behavior sometime in the past two years,
rather than just viewing every discussion as a battle that must be won
at all costs, I would not be making this request.



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

Re: removal of svenl from the project

[Andres Salomon]

On Wed, Mar 15, 2006 at 05:47:14PM +0100, Pierre Habouzit wrote:
[...]
> 
> 
> oh and btw, as you noted it, I attacked you personnaly, maybe you should 
> begin a procedure to expulse me.
> 
> 

There's a vast amount of difference between (your) intentional trolling and
unintentional, repeated abusive behavior.

Welcome to my killfile, though.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: removal of svenl from the project

[Andres Salomon]

On Wed, Mar 15, 2006 at 07:20:20PM +0100, martin f krafft wrote:
> also sprach Gustavo Franco <[EMAIL PROTECTED]> [2006.03.15.1512 +0100]:
[...]
> > 
> > I'm asking myself what's behind all that ? Ubuntu ? Probably no.
> > Subconcious fear to delivery in time ? Probably yes. Stop thinking
> > about who you're going to ask to be expelled next and spend some
> > time considering not my words, but just Etch.
> 
> Thank you!
> 

If I didn't care about etch, I could just as easily sit back and let Sven
do his thing (as I have been doing for the past few months); however, I
would like to see the release happen.  Given the time and resources that
Sven's arguments consume, I am convinced that expelling him will make things
run a lot smoother.

For starters, I/we need to figure out a sane way to deal w/ 3rd party kernel
modules.  I'm not sure the status of this, since Sven was adamant about this
happening his way; I'm not even willing to even touch the issue while he's
active in the kernel team.  I don't need the extra stress.  If Sven remains
active, I intend to just ignore the issue and let someone else deal w/ it;
perhaps someone who thinks that expulsion is too harsh.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: removal of svenl from the project

[Andres Salomon]

On Thu, 2006-03-16 at 00:59 +0100, Sven Luther wrote:
> On Wed, Mar 15, 2006 at 02:45:42PM -0500, Andres Salomon wrote:
> > On Wed, Mar 15, 2006 at 07:20:20PM +0100, martin f krafft wrote:
> > > also sprach Gustavo Franco <[EMAIL PROTECTED]> [2006.03.15.1512 +0100]:
> > [...]
> > > > 
> > > > I'm asking myself what's behind all that ? Ubuntu ? Probably no.
> > > > Subconcious fear to delivery in time ? Probably yes. Stop thinking
> > > > about who you're going to ask to be expelled next and spend some
> > > > time considering not my words, but just Etch.
> > > 
> > > Thank you!
> > > 
> > 
> > If I didn't care about etch, I could just as easily sit back and let Sven
> > do his thing (as I have been doing for the past few months); however, I
> 
> Are you implying that it was because of me that you have taken a backseat
> recently ? I remember somethign else, about you being frustrated with DAM and

No, I am implying that I have no desire to resume working with the team
with you on it, now that the security details are being worked out.

> the security team, and deciding to work more with the ubuntu guys at that
> time. I was really sad to see this happen, as your input was very valuable to
> the debian kernel team, and i told you so back then.


I fail to see how ubuntu factors into this conversation at all.  Check
the changelogs; I haven't contributed anything to an ubuntu kernel since
last May or so.  I was evaluating my options wrt to what distribution to
run on servers (since at the time I did not feel comfortable running a
sarge kernel on them), and ubuntu is one of them.


> 
> > would like to see the release happen.  Given the time and resources that
> > Sven's arguments consume, I am convinced that expelling him will make things
> > run a lot smoother.
> 
> maybe, but then you forget all the work i did to get 2.6.14 out, and i do
> currently not believe that we would have achieved that much if i had not
> strongly worked for it. I had to endure flames and insults from maks, manoj
> and jonas over the ramdisk-generator issue, an issue all where talking about
> since weeks and months, but nobody decided to act. Notice that already then
> there was a rather odious flamewar, and it is instead disgusting to have to go
> through such to get people to not dismiss you out of the hand because it is
> not like they have been doing since since forever.

I still think the whole ramdisk generator thing is silly, but that's not
really on-topic, and we've had this discussion before.  I wasn't
involved in the flamewar, and I don't care to be; I suspect your posts
made up a large portion of the thread, however (just like in this
thread).


> 
> As a result, we solved the ramdisk generator dilemna to everybody's
> satisfaction, we managed to do same-day releases, which nobody thought
> possible, and was never heard off in debian (who was known for largely
> out-dated kernels, and needing a whole month to upgrade the d-i kernel).
> 
> > For starters, I/we need to figure out a sane way to deal w/ 3rd party kernel
> > modules.  I'm not sure the status of this, since Sven was adamant about this
> > happening his way; I'm not even willing to even touch the issue while he's
> 
> I notice though that back then my way, was also the way you advocated against
> manoj. Strange no, the way memory work.
> 

I recall initially discussing options w/ you and dannf about how to do
it.  I don't remember Manoj factoring into the discussion at all. 

[...]
> 
> I leave this all to you, i hope you are up to the responsability, and will not
> participate again in the kernel team until i am asked to.
> 

Why would this be all on me?  It's a team effort; I would hope that I
would be able to work on those issues w/ fellow kernel team members that
are interested in actually getting them solved (and not wasting time
arguing back and forth, refusing to compromise).



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: removal of svenl from the project

[Andres Salomon]

On Thu, Mar 16, 2006 at 12:39:42PM +0100, Julien BLACHE wrote:
[...]
> 
> In the meantime, we are wasting precious DD and DAM time to satisfy
> Andres' need for a revenge on Sven.
> 

*Sigh*.  This has absolutely *nothing* to do w/ "revenge on Sven".  Sven
himself has stated that he doesn't understand why I'm doing this, as he
and I have never had any real problems.

Your perception of this whole thing is certainly.. interesting.  Unfortunately,
it doesn't seem grounded in reality.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Ubuntu Patches

[Andres Salomon]

On Mon, 21 Mar 2005 19:32:54 -0800, Thomas Bushnell BSG wrote:

> Matt Zimmerman <[EMAIL PROTECTED]> writes:
> 
>> The only distinction here is between merely publishing the patches on our
>> website, and pushing the patch to the Debian maintainer immediately.  We
>> publish all of our patches relative to Debian on a regular basis, and make
>> an honest effort to sort and separate them to the extent that this can be
>> automated.
> 
> Help me out here so that I understand.
> 
> Suppose an Ubuntu developer sees a spelling error in a Debian package,
> or perhaps a mistake in widget placement on the screen.  The developer
> fixes the bug, and then publishes the patch on your website.  (I'm not
> bothered at all by the time lag in the patch getting published, btw.)
> 
> At what point does the Ubuntu developer file a bug report against the
> Debian package with the patch?
> 

These seem like excellent fodder for a FAQ/wiki, if there isn't one
already (a quick scan around Ubuntu's official and wiki FAQs didn't turn
up anything). Perhaps "How Ubuntu relates to Debian", or "How Ubuntu
changes find their way into Debian, and vice-versa".



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Why do we still have this on the distribution?

[Andres Salomon]

On Tue, 05 Apr 2005 19:09:21 -0400, sean finney wrote:

> On Tue, Apr 05, 2005 at 03:56:25PM -0700, Don Armstrong wrote:
>> The fact that Adam Conrad just made an upload yesterday to fix bugs in
>> the package seems to indicate that he at least feels that it is
>> useful. [Or at least, I *hope* that's why an upload was made instead
>> of requesting removal.]
> 
> obviously adam's going to be the best judge of what's going on wrt php3,
> but afaict there's no need of php3 that can't be satisfied by
> php4 (which is completely backwards compatible with v3 in every case
> i know of), so i don't see why we can't just remove it and have v4 fill
> in the void.
> 

There are license issues involved, as well.  php4 changed the license in
ways that some people disagree with.  I believe that was a large part of
people wanting php3 to stick around.





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Release update: debian-installer, kernels, infrastructure, freeze, etch, arm

[Andres Salomon]

On Wed, 06 Apr 2005 01:50:53 +0200, Adrian Bunk wrote:

> On Wed, Apr 06, 2005 at 01:17:54AM +0200, Wouter Verhelst wrote:
>> On Tue, Apr 05, 2005 at 04:52:29PM +0200, Adrian Bunk wrote:
>> > Why do you need to know about all transitions this month if Debian 3.2 
>> > is scheduled for the end of 2006 or 2007?
>> 
>> ... so that the release team can plan ahead a bit?
> 
> It's funny that the release team needs to know about transitions for 
> etch that might occur in 2006 now, while even the freeze date for sarge 
> isn't yet announced.
> 

It's also funny that people want debian to release so bad, and yet fight
the release team at every announcement.  I don't see a problem with
wanting to know as much about transitions and migrations in advance as
possible.  I'm sure there will be additional transitions/migrations that
come up during etch development, but the more the release team knows
about, the better prepared they can be to propose deadlines and release
estimates.






-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: acenic firmware rewrite

[Andres Salomon]

On Thu, 07 Apr 2005 01:11:38 +0200, Peter 'p2' De Schrijver wrote:

> Hi,
> 
> Reading http://lists.debian.org/debian-legal/2004/12/msg00078.html I
> wondered if people would be willing to work on a free firmware for the
> Tigon II chip.  I didn't look at the existing code yet, but looking at the
> datasheet
> (http://alteon.shareable.org/firmware-source/12.4.13/tigonbk.pdf.bz2) it
> doesn't seem to be a very complicated chip to code for. I'm not sure
> however, how to handle the development in such a way the resulting
> firmware can be released under a free license without any legal risks. I
> have 2 PCI boards with the Tigon II chip and a 1000BaseSX PHY. I also have
> an Ace Director III loadbalancer which consist of 10 Tigon II chips. 8 of
> those are used for 100BaseT interfaces, 1 has a 1000BaseSX PHY and the
> 10th is used as a system controller.
> 

I can't imagine there would be any issues if you released both the source
and binary, and licensed them under the GPL.  The firmware source and
binary can both be distributed in the kernel (with the binary actually in
the driver source code).





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: acenic firmware rewrite

[Andres Salomon]

On Sat, 09 Apr 2005 19:26:09 +0200, Peter 'p2' De Schrijver wrote:

[...]
> Sure. That's ok. I was more thinking of someone reading the existing
> firmware sources, writing a spec and a second person/group implementing
> the new free firmware based on the spec. AFAICS the implementors and the
> spec writers should be different people/groups. Or do you think it would
> be ok if the same people read the existing non-free sources and
> reimplement its functionality in a new free firmware ?
> 

Ah, yes, a cleanroom implementation would work for that.  The spec writer
and code writers should definitely be different people.

Before you get started on this, however, let's see if we can't get some
clarification on the license of the firmware source
(http://wiki.debian.net/?KernelFirmwareLicensing).



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Status of PHP5?

[Andres Salomon]

On Tue, 26 Apr 2005 10:56:52 +0200, Martin Geisler wrote:

> Romain Francoise <[EMAIL PROTECTED]> writes:
> 
>> Debian has more than 900 developers, a minimum amount of cooperation
>> is necessary...
> 
> May I then ask why the maintainers of PHP4 hasn't joined the
> discussion?  I think it would be important that they explain their
> reasons for not having packaged PHP5 yet.

Probably because they were busy at conferences, or managing the sarge
release.


> 
> Adam Conrad wrote[1] in August 2004 that the PHP5 packages would be
> uploaded soon, but that they had taken a backseat to PHP4 packages and
> the Sarge release.
> 

Yes, as Adam has repeatedly stated, he will work on php5 post-sarge. 
Considering the constant headaches that php4 provides, I can't blame him. 


> These are honest questions:
> 
> * Do the PHP4 maintainers find PHP5 too buggy for inclusion in Debian?
> 

Yes.  Hell, I consider php4 too buggy for Debian.  php5 is even worse. 
Have you seen the changelog[0]?  These are not minor little bugs that are
being fixed...



> * Do they lack the time to maintain PHP5?
> 

I seriously doubt it, but why expend the extra effort when a) it's not
going to make it into sarge, b) the version of php that *will* be in sarge
could still use more attention, and c) early versions of php5 are expected
to be unstable.

> I can understand that they want things "done right", but please, six
> months is a long time.  An update on the situation would be very much
> appreciated.
> 

The proper place for php5 right now (imo) is in experimental.  I don't
speak for any of the other php maintainers, of course; but personally if
feel it's a waste of time to deal w/ it right now, time that could be
better spent fixing other bugs in Debian.

[0] http://www.php.net/ChangeLog-5.php#5.0.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: updated cogito package - now with docs!

[Andres Salomon]

On Wed, 11 May 2005 14:05:28 -0600, Sebastian Kuzminsky wrote:

> The upstream now includes docs for the GIT core, though still not for
> Cogito.  The docs are available in .txt and .html, and they _would_
> be available as manpages except for a bug in asciidoc.  The asciidoc
> maintainer has been offered a patch.
> 
> 
> You can grab the new cogito package here:
> 
> http://highlab.com/~seb/debian
> 

FYI, you can make the packages and source apt-get'able w/ a script like
http://www.acm.rpi.edu/~dilinger/libmusicbrainz-ruby/mkarchive.sh





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: new cogito package, OpenSSL license issue resolved

[Andres Salomon]

On Fri, 13 May 2005 23:44:05 -0600, Sebastian Kuzminsky wrote:

> I've updated the Cogito package to compile against the upstream-included
> GPL SHA1 implementation lifted from Mozilla, instead of the (possibly)
> GPL-incompatible OpenSSL code.  Thanks to Florian Weimer and Anibal
> Monsalve Salazar for bringing this issue to my attention.  I have a
> terrible head for this kind of legal stuff, "can't we all just get
> the code?"
> 
> 
> This is the last issue I know of keeping this package out of the Debian
> archives.  Yay!  There's still the manpage issue, but I expect it will
> be resolved upstream in the next few days.
> 

For people trying this out, Zach Brown wrote some excellent
documentation [1].  It would be nice to see this end up in the debian
packages.

If you need a sponsor for this, let me know; I'd like to see it in
debian sooner rather than later.

[1] http://thread.gmane.org/gmane.comp.version-control.git/3338


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

wiki.debian.net brokenness?

[Andres Salomon]

Hi,

I've discovered that I can no longer log into wiki.debian.net.  When
visiting pages, it informs me that I'm AnonymousUser; when I try to edit a
page, it tells me that the web page doesn't not allow anonymous editing. 
However, it doesn't provide a link to log in (or maybe I'm just missing
the link?).  This makes it rather difficult to actually update wikis.

While on the topic, the wiki's revision comparison behavior is rather
suboptimal; I can't arbitrarily diff between edits/commits (which means
when people can do several large edits, it's hard to tell if information
might've gotten lost).  Had I know about this earlier, I wouldn't have
used the debian.net wiki for KernelFirmwareLicensing.  I emailed
[EMAIL PROTECTED] a few weeks ago about helping w/ the wiki, and possibly
upgrading to one that supports such functionalty, but I have not yet
received a response.

So is it time for me to just move the page to a wiki that I host, and tell
people to use that, or are the wiki.debian.net folks awake?




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits from the dpkg maintainer

[Andres Salomon]

On Sun, 12 Jun 2005 21:05:56 +0100, Scott James Remnant wrote:
[...]
> 
> * The "Debian Diff" may be replaced by the "Debian Tar":
>   Instead of placing your changes and Debian directory as a patch against
>   the upstream tarball in a diff.gz, you may instead ship the Debian
>   directory as a debian.tar.gz.  This is unpacked into the debian
>   sub-directory of the source.
> 

This is beautiful.  I can't count the number of times I've looked at a
random package that has multiple fixes and enhancement all in the diff.gz,
with no way of knowing what bugs in the BTS they fix, which hunks are are
logically separate, etc.  Even worse are the packages which include broken
out patches in the debian directory which are out of date or incomplete,
and no longer match what's in the diff.gz.  It's analogous to programs
which have no documentation, incomplete documentation, or worse yet,
completely incorrect documentation.

I'm sure people will still find ways to make other DDs lives difficult in
this manner (everything being in one big patch, including fixes in the
orig tarball, or something equally as stupid), but this seems like
this will go a long way to encourages people to separate out
upstream enhancement/fixes.

As an added bonus, this is how I typically do development (which
is similar to how HCT does stuff under the hood, from what I've seen), so
that debian-directory-specific baz/git/$RCS branch will now map
directly to a tarball, and individual patches in debian/patches will map
to their respective branches.

/me wipes a tear of joy from his eye


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: arch-dir of ruby1.8/1.9 was changed to i486-linux from i386-linux

[Andres Salomon]

On Thu, 30 Jun 2005 00:52:32 +0900, akira yamada wrote:
[...]
> And if you are maintaining packages which have extension libraries,
> please rebuild and upload it to Debian.
> 
> 

Please file bugs against extensions; lots of people don't read d-d.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ndiswrapper update

[Andres Salomon]

Hi,

I've redone the packaging for ndiswrapper, starting with 1.8-2.  My goal
is to allow utils packages to be installed in parallel, and to allow a
smooth upgrade from both 1.1-4 (the version that's in sarge) and 1.8-1
(the version that's in sid).

If you are running ndiswrapper 1.8-1, please upgrade ASAP if you want
any sort of smooth transition.  I will be uploading 1.14-1 soon, and
going from 1.8-1 to 1.14-1 will *not* be a smooth transition.  Make sure
you install 1.8-2 before going to 1.14-1.

If you are running ndiswrapper 1.1-4, do nothing; upgrades to 1.14-1
should work, and that is the version that will migrate into etch.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

orphaning gitweb

[Andres Salomon]

Hi,

I'm going to orphan gitweb; I haven't used it in a long time, and I've
been doing a poor job of keeping it up-to-date.  It doesn't have any
bugs open on it; it just needs the occasional update (and the one patch
I've done for it should be fed upstream if they're willing to take it).

Who wants it?

(Please CC me; I'm not subscribed to -devel.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: If *-module depends on *-utils, should *-source recommend it?

[Andres Salomon]

On Wed, 12 Jan 2005 10:05:00 -0600, Matthew Dempsky wrote:
[...]
> If a new version of ndiswrapper-utils is not backwards-compatible with
> an old version of ndiswrapper-modules, shouldn't it declare a
> versioned Conflicts with those older versions or else when you try to
> upgrade you'll have problems regardless if ndiswrapper-source declared
> a Recommends on ndiswrapper-utils?

Of course.  No one has provided proof that this is the case, though.  I
asked if a versioned depends was necessary, but instead got accusations
and vitriol.  I have not had time to test it myself yet.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Help me test new pcmcia-cs

[Andres Salomon]

On Mon, 10 Jan 2005 16:00:00 +0100, Per Olofsson wrote:
[...]
> 
> It would be very nice if you could help me test it before I upload it
> to sid. Since I've done a lot of changes, I suspect that there might
> be some bugs in it. And don't forget to read NEWS.Debian and
> README.Debian.
> 

Works well for me.  I upgraded, switched REFRAIN_FROM_IFUP to yes, and
rebooted; everything came up just fine.  I look forward to seeing it in
sid.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LVM packages up for adoption

[Andres Salomon]

On Mon, 17 Jan 2005 09:28:56 +, Patrick Caulfield wrote:

> What with a change of circumstances and lack of time recently I don't honestly
> think I'm doing a good enough job on the LVM packages, so I'm offering them up
> for adoption to anyone who thinks they can do a better job.
> 
> The packages are:
> 
> lvm2  - in active development, upstream helpful but often busy.
> device-mapper   - largely stable. occasional releases.
> lvm10 - stable. no more upstream development at all.
> lvm-common  - native package. small number of bugs need sorting out
> multipath-tools - in active development, upstream very helpful.
> 
> If nobody wants them I'll continue to do the best I can with the time 
> available.

Now that I can upload, I could take or co-maintain the lvm2 related stuff;
however, I don't have much interest in lvm10.





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LVM packages up for adoption

[Andres Salomon]

On Tue, 18 Jan 2005 17:11:50 +, Tim Cutts wrote:

> 
> On 18 Jan 2005, at 4:06 pm, Patrick Caulfield wrote:
> 
>> On Tue, Jan 18, 2005 at 03:46:18PM +, Tim Cutts wrote:
>>>
>>> On 17 Jan 2005, at 5:42 pm, Bastian Blank wrote:
>>>
 On Mon, Jan 17, 2005 at 09:28:56AM +, Patrick Caulfield wrote:
> lvm2  - in active development, upstream helpful but often 
> busy.
> device-mapper   - largely stable. occasional releases.
> lvm10 - stable. no more upstream development at all.
> lvm-common  - native package. small number of bugs need sorting
> out
> multipath-tools - in active development, upstream very helpful.

 I'm interrested onm co-maintaining lvm2 and device-mapper.
>>>
>>> As am I - we use these heavily on some fairly serious kit at work, so 
>>> I
>>> can justify the time... co-maintaining sounds like a sensible thing to
>>> do.
>>>
>>
>> So how about you three co-maintain lvm2 & devmapper (and maybe 
>> lvm-common ? it's
>> as much part of LVM as the lvm2 package really), and I'll hang onto 
>> lvm10 &
>> multipath.
> 
> Sounds good to me.  I'll be able to help you with testing 
> multipath-tools too; that and lvm2 are the principal bits we use (we 
> don't use Debian device-mapper stuff because we build our own kernels 
> from scratch)
> 
> We use this stuff on both IA64 (HP rx4640) and i386 (HP DL360/380, 
> mostly) architectures to talk to our dual-fabric SAN (HP StorageWorks 
> HSV110 controllers on the back)
> 
> How should we coordinate this?
> 

My recommendation would be an LVM alioth project, w/ a svn or arch
(preferred) repository.  I've kept track of lvm2 stuff in arch for a
number of years, it has worked well.

Patrick, it might even be worth all 4 of us maintaining all the LVM
related packages (throwing lvm10 in with the rest), since Tim uses
multipath-tools, and none of us care much for lvm10.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Avifile package - help needed

[Andres Salomon]

Just out of curiousity.. Does it work w/ 2.4.0-test11 and above? 
Something in avifile checks /proc/cpuinfo for the "flags" entry,
which was renamed in test11 (I don't remember the new name for
it, I reverted to test10.  Anyone running 2.4.0 could tell you).
Thus, it would die immediately for me.


On Thu, Jan 04, 2001 at 09:58:39PM +0100, Zdenek Kabelac wrote:
> 
> Hi everyone
> 
> After a while there is finaly version which looks stable enough for me, 
> so there are new packages of this program available here
> 
> http://master.debian.org/~kabi/libaviplay_20010103-1_i386.deb
> http://master.debian.org/~kabi/avifile-player_20010103-1_i386.deb
> http://master.debian.org/~kabi/codecs-win32_20001025-1_i386.deb
> http://master.debian.org/~kabi/avifile-samples_20010103-1_i386.deb
> 
> However there are still some errors which prevents this package to be
> released - namely this one:
> 
> E: libaviplay: shlib-with-non-pic-code usr/lib/libaviplay.so.0.0.0
> 
> I'm unable for now to recompile this library with -fPIC flag because
> the author of avifile seems to be joining two libraries into one and
> this is probably the cause why the linking stage is producing these
> warnings:
> 
> ../lib/.libs/libaviplay.so: undefined reference to
> `Mpegtoraw::generate(void)'
> ../lib/.libs/libaviplay.so: undefined reference to
> `Mpegtoraw::wgetbits(int)'
> ../lib/.libs/libaviplay.so: undefined reference to
> `Mpegtoraw::generate_2(void)'
> 
> 
> 
> However without -fPIC code the library seems to be fully operational and
> I would
> say that now at least the aviplay reached the stage of very good
> usability
> (it least it's finally able to play subtitles in non-isolatin1 encoding)
> 
> Anyway all the sources are also available here
> http://master.debian.org/~kabi/
> (basically tar.gz is CVS snapshot & there is small diff file with debian
> rules,
> so the package could be build directly from CVS, if its compilable in
> that time)
> 
> Those how need this program right now could download these .deb files
> manually
> If there is anyone who knows how to solve this situation please let me
> know.
> 
> 
> PS: Should I upload the package with lintian's error ?
> 
> -- 
>  There are three types of people in the world:
>those who can count, and those who can't.
>   Zdenek Kabelac  http://i.am/kabi/ [EMAIL PROTECTED] {debian.org; fi.muni.cz}
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
"... being a Linux user is sort of like living in a house inhabited
by a large family of carpenters and architects. Every morning when
you wake up, the house is a little different. Maybe there is a new
turret, or some walls have moved. Or perhaps someone has temporarily
removed the floor under your bed." - Unix for Dummies, 2nd Edition
-- found in the .sig of Rob Riggs, [EMAIL PROTECTED]

Re: BIND 9.X package status

[Andres Salomon]

...and bind9 is going to be run as non-root by default, right? :)

On Thu, Jan 04, 2001 at 03:58:51PM -0700, Bdale Garbee wrote:

> 
>   BIND 9 source package in non-US because it's DFSG-free but has crypto
>   code, including only BIND, producing binary packages
> 
>   bind9   - replaces 'bind' package
> 
>   dnsutils- the portion of dnsutils provided
> from the BIND sources, plus depends
> on host and rblcheck packages
> 
>   bind9-lib (?)   - shared libraries ?  these may just
> end up in package bind9, I'm still
> working on the details
> 
>   bind9-dev   - static libraries and include files
> 
>   bind9-doc   - full HTML documentation tree
> 
>   task-dns-server - meta package - task selection system
> 
>   host source package producing binary package
> 
>   host
> 
>   rblcheck source package producing binary package
> 
>   rblcheck
> 
> If there are any questions or discussion, please direct them to the mailing
> list debian-devel only... not to the CC list on this message.
> 
> Bdale
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
"... being a Linux user is sort of like living in a house inhabited
by a large family of carpenters and architects. Every morning when
you wake up, the house is a little different. Maybe there is a new
turret, or some walls have moved. Or perhaps someone has temporarily
removed the floor under your bed." - Unix for Dummies, 2nd Edition
-- found in the .sig of Rob Riggs, [EMAIL PROTECTED]

Re: lvm2 maintainer needed

[Andres Salomon]

Despite claims otherwise, I'm actually alive, w/ experimental packages
at http://sloth.voxel.net/~dilinger/lvm2/.  Various things (bugs, loss
of an internet connection, upstream developers going on vacation) have
kept me from uploading; however, after talking w/ upstream, I'm going to
do an upload to simply get rid of the grave bugs before I attempt to
collaborate w/ [EMAIL PROTECTED] (who is one of the upstreams on vacation)
to get lvm10 compatibilty working.

Also, I'm not in db.debian.org since I've been sponsored (and on that
note, anyone in the upstate New York/Albany area willing to sign my key
so I can get the NM process started?)


On Mon, 2003-07-28 at 14:58, Wichert Akkerman wrote:
> Is anyone willing to maintain lvm2? Its last upload was over a year ago
> and its listed maintainer does not seem to be a Debian developer
> according to db.debian.org .
> 
> Wichert.

Re: lvm2 maintainer needed

[Andres Salomon]

Oh, also, the last upload was 5 months ago; I typo'd in the changelog,
putting 2002 instead of 2003. :)


On Mon, 2003-07-28 at 14:58, Wichert Akkerman wrote:
> Is anyone willing to maintain lvm2? Its last upload was over a year ago
> and its listed maintainer does not seem to be a Debian developer
> according to db.debian.org .
> 
> Wichert.

Re: What is going on with udev?

[Andres Salomon]

On Wed, 03 Aug 2005 14:18:01 -0300, Ben Armstrong wrote:

> On Wed, 2005-08-03 at 14:02 -0300, Gustavo Franco wrote:
>> Closing, it isn't a bash against the kernel team. It isn't my point,
>> my problem is with this "didn't you know, read X stupid!" approach.
> 
> I don't think pointing at the mailing list was an unreasonable reaction
> to the "genius" comment, which implied that the namechange was entirely
> arbitrary.  And I didn't hear anyone call anyone else "stupid".  I think
> you're being a bit oversensitive.
> 
> But I was mystified, myself, until I searched for the renamed package.
> I agree a d-d-a post would've helped clear up the confusion, and wonder
> why this wasn't announced.
> 
> Ben

An explanation to d-d-a will be coming in due time; however, right now the
package is in flux, so announcing it is premature.  udev issues aside
(which should *not* depend on >= 2.6.12), nothing else depends on the
new kernel packages, so the only people using it are those that actually
are aware of what's going on.  I'd like to keep it that way until the
package is stabilized, at which point the various dummy packages
(kernel-image-2.6-686, etc) will start depending upon
things like linux-image-2.6-686.

I'd also point out that 2.6.12-1 was built w/ a broken version of
kernel-package (see #319657).  This is fixed in our SVN repo (w/ a
versioned build-dep), but not yet in sid.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

last change to save (adopt) some packages

[Andres Salomon]

Hi,

I have more than a few packages that I've been looking to get rid of for
some time.  No one's taken them, so I'm going to request the ftp masters
drop some of them if no one takes them within the few weeks.  These
packages are:

* messagewall - An SMTP proxy daemon, designed to help keep out unwanted
email

This package no longer has an upstream maintainer.  If you want it,
you'll probably need to become upstream as well.  Otherwise, I'll have
it dropped from the archive.

* firedns - an asynch. dns resolver library

This library is by the same author as messagewall, and is still
maintained; however, there haven't been any new releases in a while.
Messagewall depends upon it, as well as a few other things not in debian
(such as dsbl.org's tester program(s)).  It's actually a neat little
library, but with nothing else in Debian using it, there's not much
point in keep it in the archive.

* firestring - a string handling library

Again, this library is by the same author as messagewall, and is still
maintained.  Messagewall depends upon it, but nothing else in Debian
uses it.  I'm going to have it removed from the archive if no one wants
it.

* libxml-ruby - Ruby interface to libxml
* libxslt-ruby - Ruby interface to libxslt

These are fairly useful; however, afaict they are no longer maintained
upstream.  There is a fairly sordid history here; basically, the
original author (Sean Chittenden) stopped maintaining them around 2002
or 2003.  He licensed them under a BSD license (iirc).  In 2003,
Gregoire Lejeune started maintaining libxslt; however, he relicensed the
program under the GPL, and stripped off Sean's copyright information
(violating Sean's license); this is according to Sean, anyways.  At some
point in 2004/2005, someone named Trans Onoma imported them into the
xml-tools [1] repository, but he hasn't worked on them since 2004 or so.
I have no idea whether or not he intends to actively maintain them.

Sid still contains Sean's last releases, from 2002/2003.  I don't know
whether Gregoire's latest version even contains any of Sean's original
code; I no longer have a use for either of these packages, so I haven't
bothered to figure it out.  Whoever takes over these packages should
probably talk to the upstream (or ask on one of the ruby lists) to find
out which will actively be maintained.  Both licenses are problematic
for libraries as well, so maybe simply rewriting them from scratch under
the LGPL or 3-clause BSD would be the best way to go here.

Given the licensing pains and upstream squabbling, I'm going to remove
these from the archive if no one takes them.

* libhtml-tokenizer-ruby - simple HTML tokenizer/parser for Ruby

This is a really easy package, and still actively maintained [2]
upstream.  It's great for quickly parsing html; I used it in scripts to
interface the bitkeeper web interface, back when Linus used bitkeeper
(so that I didn't have to install the non-free bk client).  However, now
that Linus uses git, I don't have a use for this package.

I'll simply orphan this one, if no one takes it.

* par2 - Parity Archive Volume Set, for checking and repair of files

If you've ever downloaded those funny .par2 files off newgroups, this is
the tool you need to actually make use of them.  It's maintained
upstream (afaict), but hasn't had a new release in a while.  I'll orphan
this one as well, if no one takes it.


[1] http://rubyforge.org/projects/xml-tools/
[2] http://rubyforge.org/projects/htmltokenizer/

-- 
Andres Salomon <[EMAIL PROTECTED]>


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

renaming mysql++

[Andres Salomon]

Hi,

I intend to rename the binary packages for mysql++ with the upload of 2.0.5.
They've been called libsqlplus* for a while now, which isn't overly
intuitive (I've had multiple people not realize mysql++ was packaged for
debian, due to the name).  My choices are either libmysqlpp* (to match
the library name) or libmysql++*.  Does anyone have any preferences, or 
any reasons why I shouldn't use ++ in the package name?  Given that g++
does it, and policy explicitly allows '+', I can't think of any reasons
not to name it libmysql++*.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Best practices for kernel modules

[Andres Salomon]

On Thu, Oct 06, 2005 at 05:24:12PM -0700, Russ Allbery wrote:
> Hello all,
>   
[...]
> 
> There are two bugs against the OpenAFS package, one requesting prebuilt
> modules (Bug#224527) and one requesting that modules be automatically
> rebuilt when the kernel is upgraded (Bug#168852).  I'm not sure how to
> deal with these issues.  I'd love to get some feedback on what the current
> best practices are for packaging kernel modules.
> 
[...]

The kernel team has discussed having a package that builds -source packages
for modules when a new kernel is uploaded; I think that's the best solution,
although the infrastructure to do that still has to be written.

I'm not sure if anyone's working on it atm.

 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

orphaning kazehakase

[Andres Salomon]

Hi,

Is anyone interested in taking over kazehakase?

kazehakase -- GTK+-base web browser that allows pluggable rendering
engines

It needs some serious love; upstream still appears to be somewhat
active, but shifting gecko APIs and a lack of release in almost a year
makes this more challenging than simple packaging.  Oh, and knowing
japanese would probably help, as that's what upstream speaks.  It
currently fails to build (debian's 0.5.4, upstream's 0.5.6 release, and
the current svn trunk all FTBFS).

I no longer use the package, and I haven't heard a peep from Hidetaka
Iwai since...well, ever.  It's time for someone who actually uses it to
take it, or I'll request its removal from the archives.


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

Bug#542123: O: mock -- Build rpm packages inside a chroot

[Andres Salomon]

Package: wnpp
Severity: normal
X-Debbugs-CC: debian-devel@lists.debian.org

Hi,

I packaged mock for OLPC, but I'm no longer with OLPC.  Someone else
who uses the package (or wants to use it) should give it the love that
it deserves.

Package info:
 
 Mock creates chroots and builds rpms in them. Its only task is to
 reliably populate a chroot and attempt to build a package in that
 chroot. It is used by the Fedora Extras project to build their
 packages cleanly.



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

Re: trac maintenance activity?

[Andres Salomon]

On Thu, 10 Sep 2009 11:01:45 -0400
Andres Salomon  wrote:

> On Mon, 17 Aug 2009 18:57:38 -0400
> Andres Salomon  wrote:
> 
> > Hi,
> > 
> > Is trac being actively maintained?  I no longer use it, so I'd like
> > to be removed from the uploaders list when someone does the next
> > upload. If no one is maintaining it, it should really be orphaned..
> > 
> > Note that 0.11.5 has been released, and debian's still on 0.11.1
> > (from a year ago).
> 
> I never got a response to this.  Anyone out there interested in
> joining the trac team?
> 

Ah, just noticed debacle's emails[0] regarding this.  You'll certainly
find no objections from me.  Feel free to take over.

[0] 
http://lists.alioth.debian.org/pipermail/pkg-trac-devel/2009-August/000523.html


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

Re: trac maintenance activity?

[Andres Salomon]

On Mon, 17 Aug 2009 18:57:38 -0400
Andres Salomon  wrote:

> Hi,
> 
> Is trac being actively maintained?  I no longer use it, so I'd like to
> be removed from the uploaders list when someone does the next upload.
> If no one is maintaining it, it should really be orphaned..
> 
> Note that 0.11.5 has been released, and debian's still on 0.11.1 (from
> a year ago).

I never got a response to this.  Anyone out there interested in joining
the trac team?


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

ITP: ofono-phonesim -- Modem emulator used by the oFono mobile telephony stack

[Andres Salomon]

Package: wnpp
Owner: Andres Salomon 
Severity: wishlist

* Package name: ofono-phonesim
  Version : 1.0
  Upstream Author : various
* URL : http://www.ofono.org/
* License : GPL 2
  Programming Lang: C, C++
  Description : Modem emulator used by the oFono mobile telephony stack

oFono is a stack for mobile telephony devices on Linux.  oFono supports
speaking to telephony devices through specific drivers, or with generic
AT commands.
.
Phonesim is a modem emulator that oFono uses for development and testing.
This allows oFono to be used by any host without requiring special GSM
(or other) hardware.


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

Re: Minimal kernel version raised to 2.6.27

[Andres Salomon]

On Tue, 10 Nov 2009 18:08:08 +0100
m...@linux.it (Marco d'Itri) wrote:

> Due to changes in udev 147, squeeze will not support kernels earlier
> than 2.6.27.
> 
> If your packages have code needed to support old kernels, this is the
> right time to clean it up.
> 
> This means that lenny->squeeze upgrades will use the same lockstep
> kernel/udev upgrade method used for etch->lenny upgrades.
> 

Since it's seeming more and more common for udev to be tied to specific
kernel versions, have you considered allowing major versions of udev
to be installed in parallel?


signature.asc
Description: PGP signature

Re: The status of libapache2-mod-perl2

[Andres Salomon]

On Thu, 16 Aug 2007 06:58:02 +0200
"Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote:

> On Wed, Aug 15, 2007 at 09:32:30PM -0500, Gunnar Wolf wrote:
> > Of course, before any action, I'd like to hear Thom's or Andres' points
> > of view.
> 
> You probably want to hear my input too. :-)
> 
> At Debconf5, I was more or less persuaded into taking the package (up to
> the level where I actually had the first maintainer upload ready). I did,
> however, set a condition that was sort of silly -- that Thom would sign my
> GPG key. Naturally, we all forgot about it, the key was never signed, I
> didn't go to DC6 and Thom didn't go to DC7. So, it all sort of faded away,
> and the package was kept in a sort of limbo where I sort of had the
> responsibility and sort of not. Not taking clearer action at the time,
> despite nagging from Thom, is something I'll have to take the blame for.

Um, yeah, what he said.  I have no interest in maintaining it any more;
someone should probably take up the slack.


> 
> However, at the time of writing I'm in the process of starting to work, so I
> really cannot take on any new responsibilities until I know how life is going
> to look like. Thus, I'm afraid I can't take over the package -- perhaps as
> co-maintainer if you need me (although I'm skeptical of co-maintenance in
> general), and of course as a user, but nothing else.
> 
> /* Steinar */
> -- 
> Homepage: http://www.sesse.net/


-- 
Andres Salomon <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

anyone in nyc tomorrow for a keysigning?

[Andres Salomon]

I have the chance to tag along on a (company) trip to one of our colo
centers tomorrow (located at 25 Broadway, New York NY 10004-1010).  Are
any developers available tomorrow to sign keys in that general area? 
There don't appear to be any developers close to where I live (upstate
ny/albany area). 


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

Re: anyone in nyc tomorrow for a keysigning?

[Andres Salomon]

Ok, I got no takers, so I'm not bothering to go down today.  However,
there will be some more trips down to Manhatten in the next few weeks, so
if any developers will be around to sign keys, please let me know.


 On Thu, 16 Oct 2003 16:40:53 -0400, Andres Salomon
wrote:

> I have the chance to tag along on a (company) trip to one of our colo
> centers tomorrow (located at 25 Broadway, New York NY 10004-1010).  Are
> any developers available tomorrow to sign keys in that general area? 
> There don't appear to be any developers close to where I live (upstate
> ny/albany area).

Debian Enterprise?

[Andres Salomon]

Over the past week, my boss and I have had discussions about the niche
left by RedHat, and the possibility of working on a
distribution/sub-project aimed at enterprise folks.  The plan is to target
those RedHat users and companies who are unwilling (or unable) to pay for
RedHat Enterprise Linux, but need HA features.  Our company falls into
this category, but made the RedHat->Debian switch earlier on.

Currently, we're forced to maintain our own kernels, compile apache/php
from source, and use a few backports to woody.  What we really need is:

* a kernel that supports things like IPVS (Linux Virtual Server), UML (the
skas host patch), 64-bit smbfs support, and various other things. 
RedHat's kernel had a slew of 2.6 backports, as well as HA stuff thrown in
there. We need something like that (only less extreme; RH liked their
experimental kernel features a bit too much).
* Updated server-related packages; for example, we definitely need a php4
package newer than 4.1.2, and preferably built against apache2.

I can think of a few ways to offer the above.  The first is a standalone
distribution, based on debian but with various enhancements (not a novel
idea, by any means).  We could either base this on testing, doing snapshot
releases every 3-6 months, and offering security fixes, or
on stable w/ various backports.  We would probably
have a stripped-down installer based on d-i, w/ the stock kernel being
similar to redhat's kernel.  

Another way would be to have a debian sub-project; this would have a
kernel that includes extra (enterprise) features
(kernel-image-2.4.22-enterprise-1-686smp), amongst other things.  I'd also
like to see enhancements to d-i, work done to ease things like php into
testing, and (if based around testing) security updates for testing.

If folks are at all interested in this sort of thing, please let me know. 
Our long-term goals for this are to hire a developer or two (part or
full time) to help maintain this project, as long as it's something we
(and our clients) can use and support.

Suggestions are most welcome.

Re: Debian Enterprise?

[Andres Salomon]

On Mon, 17 Nov 2003 11:51:43 -0500, Matt Zimmerman wrote:

> On Mon, Nov 17, 2003 at 01:45:05AM -0500, Andres Salomon wrote:
> 
>> I can think of a few ways to offer the above.  The first is a standalone
>> distribution, based on debian but with various enhancements (not a novel
>> idea, by any means).  We could either base this on testing, doing snapshot
>> releases every 3-6 months, and offering security fixes, or
>> on stable w/ various backports.  We would probably
>> have a stripped-down installer based on d-i, w/ the stock kernel being
>> similar to redhat's kernel.  
>> 
>> Another way would be to have a debian sub-project; this would have a
>> kernel that includes extra (enterprise) features
>> (kernel-image-2.4.22-enterprise-1-686smp), amongst other things.  I'd also
>> like to see enhancements to d-i, work done to ease things like php into
>> testing, and (if based around testing) security updates for testing.
> 
> If the sub-project approach would mean that the new packages and
> enhancements would be folded into Debian, then I think that is definitely
> preferable.  I do not think that basing it on testing is the best approach;
> in my experience, enterprises prefer a longer (stable) release cycle than
> testing's daily churn.

Normally I'd agree; however, one of the issues I'm trying to resolve is
the need for numerous backports.  However, I do believe the
subproject/kernel is a good start.  I would prefer to see it based around
testing snapshots, not necessarily testing itself.

Re: Debian Enterprise?

[Andres Salomon]

On Mon, 17 Nov 2003 19:55:36 +, Andrew M.A. Cater wrote:

> On Mon, Nov 17, 2003 at 01:45:05AM -0500, Andres Salomon wrote:
>> Over the past week, my boss and I have had discussions about the niche
>> left by RedHat, and the possibility of working on a
>> distribution/sub-project aimed at enterprise folks.  The plan is to target
>> those RedHat users and companies who are unwilling (or unable) to pay for
>> RedHat Enterprise Linux, but need HA features.  Our company falls into
>> this category, but made the RedHat->Debian switch earlier on.
>> 
> Check out the Beowulf list archives @ www.beowulf.org for 
> October/November where just these sorts of discussions have
> been happening. I've been trying to advocate a switch to Debian
> from RH for a lot of the high powered folk who run major clusters.
> 
> I'm not sure that a separate distribution would fly - Progeny would
> have carried on otherwise.  Bruce Perens' proposed ??UserLinux??
> would possibly be a candidate here.  Nor am I sure that a "sub-project"
> is ideal.  A customised kernel or two and potentially a meta-package
> might be enough.
> 

After reading Andreas Tille's link on sub-projects, I'm leaning more
towards that.  I have little doubt that a separate distribution (done
correctly) would fly; look at the success of Knoppix, for example. 
However, my goals are more in line w/ the goals of a sub-project.



> It doesn't make sense to fork unless you _really_ need to fork.  A 
> distribution based on woody + backports would be OK now, with a 
> distribution based on the new stable once we release :)  Pace Knoppix
> and Lindows, basing a distribution on testing may be more than a little
> difficult.  Talking to Libranet and merging your Enterprise stuff 
> there might be another option.  In the longer term, I'm slightly 
> sceptical about how many Debian-based distributions can survive outside 
> Debian - but then I've had 9 1/2 years of 20/20 hindsight :)
> 

Most Debian-based distributions are aimed at desktop users; this market is
fairly crowded, especially when you take into account the distributions
outside of Debian that focus on the same thing.  On the enterprise level,
however, there are few distributions that focus on just that segment. 
There are even fewer that offer their distribution for free (as in beer).
RedHat was one of the few, and with their exit from that market, a large
opportunity opens up.

I do agree that there's little need to fork, so long as the sub-project
structure is flexible enough.  I need to do more research on that.


> Just my 0.02 Euro / 0.03 US$
> 
> Andy

Re: New kernel headers break LVM build

[Andres Salomon]

You might be able to get away w/ simply including the lvm-specific kernel
headers in your package, as long as the lower level asm stuff that it uses
haven't changed their interface in 2.6.  OTOH, it also might introduce
subtle bugs.  Maybe you're better off build-dep'ing.

Sigh.  I should probably rebuild lvm2 to see if the new kernel-headers
package breaks it; I currently include 2.4 kernel headers in the package.



On Wed, 19 Nov 2003 15:53:58 +, Patrick Caulfield wrote:

> On Wed, Nov 19, 2003 at 03:33:53PM +0100, Christoph Hellwig wrote:
>> On Wed, Nov 19, 2003 at 02:18:34PM +, Patrick Caulfield wrote:
>> > The only solution I can think of is for the lvm10 package to build-depend 
>> > on
>> > (eg) kernel-source-2.4.19, then in the build script untar the header
>> > files, make the arch symlink (ugh) and compile against that.
>> > 
>> > Does anyone else have any nicer ideas? apart from getting everyone to 
>> > migrate to
>> > LVM2 :-)
>> 
>> Fix LVM1 to keep copies of the headers it needs in it's source tree.
> 
> including asm directories for all 18 architectures. Ah well; if it's already
> gross, making it hugely gross is not much of a descent.

[debian enterprise] sub-project planning

[Andres Salomon]

I have discussed the idea of a Debian Enterprise sub-project with
various people, and have concluded that it's a worthy goal.  I have
listed the technical reasons/goals for this sub-project below.

Initial preparation for Debian Enterprise will take place within Debian
itself, with the following short-term goals being:

1. Discussion and work on an "enterprise" kernel.  This will be one of
the first things I tackle, hopefully w/ input on the requested
debian-enterprise mailing list (#222359).  The goals for this kernel
will be inclusion of non-experimental features needed by
enterprise-level users utilizing Debian in a server environment.  Others
have suggested simply using a Red Hat kernel; however, Red Hat tends to
include experimental features, which are a bit too bleeding edge.  I
would like to see things like:

A. Clustering (eg, LVS)
B. Resizable filesystems (device-mapper, ext3online, etc)
C. Security (pax or exec-shield; pax is preferable, but will
require modifications)
D. UML's skas host patch, and so on.  

Obviously, suggestions are encouraged, but please hold off until the
debian-enterprise list is created.  If the list cannot be created in a
timely manner (w/ developer accounts currently locked, this may be an
issue), I'll host it on a Voxel machine.

2. Given last week's security issues, attention needs to be paid to
package signatures, as well as authentication methods.  For packages, we
may want to focus on apt-secure (http://monk.debian.net/apt-secure/);
I'm not sure the status of it, but it will be something that can be
discussed.  Of course, this has much interest outside of this
sub-project; the sub-project will merely help it (and its integration)
along.  As far as authentication methods, we may want to focus on
ways to allow out-of-the-box OPIE, SRP, or other ways of PAM
authentication.  This might be handled w/ a meta-package, for example.
Again, this needs more discussion.

3. Debian Installer enhancements, and work on getting packages moved
into testing.  Obviously, these things are useful for all Debian users,
so development on these may or may not be focused on debian-enterprise.
d-i enhancements might include installation types (similar to redhat's
installer; select server, workstation, etc, and have packages selected
for you), support for enterprise features directly in the installer
(choosing certain features may automatically pull in the
debian-enterprise kernel), and so on.  The previous debian-enterprise
thread brought up things like debix and fai, which would be very
interesting for this sub-project as well.

These are shorter term goals.  Longer term goals include possible
creation of another branch, security updates on this branch, etc.  I'm
leaning towards testing snapshots, utilitizing snapshot.debian.net for
package storage (along w/ security updates for these packages).  The
goal of this branch will be shorter release cycles (a new release every
2-3 months), longer security updates (end-of-life after 2 years, for
example; 6-8 releases), and focus on only server architectures (m68k
bugs won't, for example, keep a package out of the distribution;
enterprise users don't really care about m68k).  

I have discussed this sub-project extensively at Voxel, and we are
willing to commit to seeing this idea through - in a manner that allows
the Debian community to benefit from resources that we put into it. We
are willing to provide developmental resources (Voxel is more than
willing to pay me to head up this sub-project), hardware, legal
resources, bandwidth, and hosting, with development happening under the
Debian moniker.  We are also researching the possibility of 24/7
commercial support for enterprise clients, as that is a large part of
what companies want (both for technical support, as well as someone to
blame when something goes wrong).

I would like to stress that while Voxel does have commercial motivations
for getting involved, the entire sub-project will comply fully with the
Debian Social Contract, and will not stray far from the Debian's
official distribution; switching to normal Debian should be a simple
process of using $APT_FRONTEND to download a group of different
packages. I believe this is the cleanest way to accomplish this (as
opposed to forking).

Comments and suggestions are welcome, but I'm not really interested in
another "Debian already is a server distro" flamewar.



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

Re: [custom] The term "flavor" and encouraging work on Debian

[Andres Salomon]

On Tue, 02 Dec 2003 22:58:28 +0200, Fabian Fagerholm wrote:

> Hi,
> 
> Recently, when thinking about the terminology surrounding Debian
> Subprojects, I thought about the term "flavor". I always liked that
> term, because I find it very descriptive.
> 
[...]
> So I suggest the following terms:
> 
> Debian is the super-project.
> XYZ is a Debian Subproject,
> which provides the flavors A, B and C.
> 
> Opinions?

I'm always a fan of clearly defined terminology.  I also like the idea of
not limiting a sub-project too much; otherwise we'd probably see a large
number of sub-projects formed, w/ discussion on their respective lists
being splintered (but applicable to more than one).  Flavors sound a lot
like a subset of tasks.  There are task groupings like "gnome", with
another task group like "web-cluster" (that pulls in
apache/ipvs/keepalived/heartbeat/etc).  The difference being that one is
simply a collection of packages, while the other is an
installation or server category.

Re: [custom] Debian Enterprise - policies

[Andres Salomon]

On Wed, 03 Dec 2003 15:01:09 +1100, Zenaan Harkness wrote:

> (Really should read ahead further ... here are more, and all laid out
> together)
> 
> * DFSG Free Software only (I know this one will get debated, but this is
> the whole point of Debian Enterprise - if you want proprietary software,
> go buy Red Hat or SUSE/Novell).
> 

This goes without saying.  If it's under the Debian name, it should comply
w/ the various Debian policies.


> * Specifically targetting For-Profit entities (vs Debian-NP)
> 

Is this really a goal?  While we're not specifically targeting non-profit
entities, we're not going to exclude them, either; especially if they have
infrastructure similar to a standard for-profit company.  Non-profits need
their oracle, too.  ;)


> * 100% Debian (Social Contract, DFSG, policies + procedures)
> 
> * LSB compliance


I think LSB compliance is one of the most important things listed (aside
from standard stuff like policy compliance).  We want commercial
software vendors to supply binaries that adhere to the LSB; whether
distributed in deb, rpm, or tarball format.  Furthermore, we want to
convince commercial software vendors that working within the LSB is more
important than working within Debian.  A company may certify their
software to work w/ DE (or a DE flavor); we should convince them to
certify software to work w/ all LSB-compliant distributions.  This allows
companies to not limit themselves to DE, or a subset of DE flavors, but
all of Debian (and other LSB-compliant distributions).




> 
> * "Official" statement as to support of Freedesktop.org standards
> 
> * Common Criteria ("not until we're big enough")
> 
> * OpenCOE ("the COE folks had to wedge _apt_ into Red Hat to get it to
> work to their satisfaction")
> 
> * "we have a FIPS 140 certification for OpenSSL"
> 
> * Other standards ??

Re: [custom] Debian Enterprise - packages

[Andres Salomon]

On Wed, 03 Dec 2003 14:45:51 +1100, Zenaan Harkness wrote:

> As per the recommendations from Bruce Perens' User Linux paper
> http://userlinux.com/white_paper.html, this thread is to discuss the
> applications within the bounded set of Debian Enterprise/ User Linux.


I think discussing the favorite applications, at this point, is a bit
premature.  Debian Enterprise (DE) should be concentrating on the
framework that will make flavors possible.  There is much that remains to be
done on the technical level (kernels, a distribution that is up-to-date
enough that companies will _want_ to use it, an installer, etc).  Deciding
what applications to supply isn't of much use right now (especially given
the rate of development of some; mozilla-firebird may be a good choice
now, but what about when epiphany or another alternative becomes the
better browser?).

Remember the original goals that DE is attempting to solve. 
Current Debian-using companies must maintain their own package backports,
kernels, and so on.  Deciding what browser we will default to, while
possibly helping in standardization, is a long ways off.  In order for DE
to become useful, we must cater to companies (not the other way around). 
Thus, we should build out the infrastructure enough so that DE, by itself,
is installable and useable.  At that point, we can start worrying about
what flavors will contain what software.


> 
> The bounded set will depend on the flavour. So first comes proposed
> flavours (and sub-flavours/ tasks/ yadda) - see previous email/ thread.
> 
> Here are some initial (obviously debatable and incomplete) selections to
> start out the bounded-apps conversation:
> 
> * Web Browser
>   - Mozilla-Firebird
> I've used Mozilla, Galeon in its day, more recently Epiphany, and the
> last few months Moz-Firebird. It is simply the simplest (and in my
> opinion best) of the crop.
> 
> * Web Server - Apache 2.0 (let's get with the times)
> 
> * Open SSH Implementation - OpenSSH (much more active that gnu version)
> 
> * Office Suite - OpenOffice (there's no other near as feature complete)
> 
> * Scripting Language - Python (no one will debate this one :)
>  - I have never used, only read (plenty) about Python, and I'm not
> personally too sure about this white space thing, but from what I hear
> about it (quite consistently) eventually feeling more "natural" than
> anything else, I am inclined to believe this really is the case. My
> experience with Java (after C/C++) was sort of like that, and if Python
> is more so, then I think it could be closest to the next VB replacement

Re: Lustre File System Support?

[Andres Salomon]

Packaging Lustre has been on my mind for some time (I packaged
intermezzo, but since that never really stabilized, I didn't upload it).
I plan to play w/ it in a bit; if it hasn't been packaged at that
point, I may do it.  At this point, it has a lot more resources being put
into its development than intermezzo ever did, so hopefully when I get
around to playing w/ it it'll be solid..


On
Wed, 17 Dec 2003 16:28:57 -0800, Nick Pavlica wrote:

> All,
>   I'm trying to find a distribution that would be
> willing to add Lustre file system support (it requires
> a kernel patch).  If this group is interested, then I
> may be able to gather some resources to help add the
> support.  It has recently reached production
> status(1.0), and would be a valuable tool to many in
> the linux community.
> 
> http://www.lustre.org
> 
> Please let me know if there is any interest.
> 
> Thanks!
> Nick Pavlica
> 
> __
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree

Re: transition plan to gtk 2.0

[Andres Salomon]

Definitely not; sinek and gde both required some pretty extensive
changes to function normally w/ gtk2..

On Sun, Aug 11, 2002 at 03:37:36AM +0200, Erich Schubert wrote:
> 
> > Some random packages use gtk 2.0 now.  What is the transition
> > plan to gtk 2.0?  I think every library which depends on gtk
> > should be recompiled first.
> 
> Uhm, gtk1 and gtk2 are not API compatible i think.
> Recompiling only solves ABI problems, not API.
> So it's not about recompiling, but it requires some major changes to the
> code i think. That's why they increased the major version number.
> It's not gtk 1.0 -> 1.0.2 or 1.0 -> 1.2 migration...
> Think of gtk2 as a new gtk design.
> 
> So the transition plan is: wait for upstream to finish their gtk2 port.
> wait for them to fix all the major bugs. then build a package based upon
> gtk2.
> 
> See for example gnumeric in bugtracking. Or see galeon2, which is a
> complete rewrite of galeon1.
> 
> (well, i havn't done much with gtk yet, just a few experiments with
> gtk2, but i'm pretty sure that you can't just recompile a gtk1 app with
> gtk2... not even after some minor changes...)
> 
> Greetings,
> Erich
> 
> -- 
> erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C
>  A man doesn't know what he knows until he knows what he doesn't know.
> Liebe ist eine schwere Geisteskrankheit (Platon)
> "Wissen ist Macht" - wenn man das richtige daraus macht.
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
Broad surveillance is a mark of bad security.
-- Bruce Schneier

Re: Apache2

[Andres Salomon]

Are there any plans for php support for apache2?  I've played around w/
2.0.40 and a php cvs snapshot from sometime last week, w/ good results;
I'm looking forward to a php4-snapshot/php4-apache2 packages, or
something along those lines.


On Mon, Aug 19, 2002 at 04:35:13PM +0100, Thom May wrote:
> 
> * Matt Kern ([EMAIL PROTECTED]) wrote :
> > I have just installed apache2 (out of sid onto a woody based system)
> > and am having a little trouble understanding the new methodology.
> > 
> > I can see the advantages of all the separate configuration
> > directories, but cannot see quite how everything fits together.  I
> > understand the include mechanism and most of the files under
> > /etc/apache2, but where are the referred to binaries addhost,
> > ap2addhost and a2enhost (or whatever they are called in the files and
> > postings I have read)?  I can't find anything on my system that makes
> > use of the *.d directories in /etc/vhost.
> > 
> > Have I caught the apache2 package in a state of extreme development?
> 
> No, you've caught the vhost system in a state of extreme unworkingness -
> there was a very rough version that maybe worked a while back, but it
> seriously needs a rewrite and some love.
> 
> It is however entirely workable without vhost-base; add sites and modules to
> /etc/apache2/{sites,mods}-available, and enable them with a symlink into
> /etc/apache2/{sites,mods}-enabled 
> 
> 
> A more suitable list for further discussion is debian-apache, and the
> reply-to is set accordingly.
> -Thom
> 
> -- 
> Thom May -> [EMAIL PROTECTED]
> 
>  Hello!
>  What is the voting period? From Mar 24th until?
>  until the candidate manoj wants to win is in the lead
> * asuffield ducks into the icbm shelter
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
Broad surveillance is a mark of bad security.
-- Bruce Schneier

Re: MAKEDEV Replacement status

[Andres Salomon]

I'm still waiting for bdale to find time to look at the code I've
released so far.  I would like to know whether he likes the direction
it's headed, before continuing..

On Sat, Aug 24, 2002 at 04:36:07PM -0400, Don Armstrong wrote:
> 
> I was just about to file a wishlist against makedev to get support for
> dpti0 .. dptiX (adaptec i2o raid cards) added to MAKEDEV, but remembered that
> there had been some talk in July about it's replacement.[1]
> 
> Could Andreas Salmon, Bdale Garbee, and Sean Perry comment on the
> status of a replacement MAKEDEV if one is in the works? [Or point me
> to relevant documentation?]
> 
> If not, I'll just file a bug w/ patch.
> 
> 
> Don Armstrong
> 
> 1: 
> http://lists.debian.org/debian-devel/2002/debian-devel-200207/threads.html#00270
> 
> -- 
> Always try to do things in chronological order.
> It's less confusing that way.
> 
> http://www.donarmstrong.com
> http://www.anylevel.com
> http://rzlab.ucr.edu



-- 
Broad surveillance is a mark of bad security.
-- Bruce Schneier

gconf breakage

[Andres Salomon]

Can someone please apply the patch from #157937 to gconf, and upload?
Galeon is uninstallable, atm.  I have a NMU package prepared for gconf,
if no one fixes this soon.


-- 
Buying a Unix machine guarantees you a descent into Hell. It starts when
you plug the computer in and it won't boot. Yes, they really did sell you
a $10,000 computer with an unformatted disk drive.
-- Philip Greenspun

Re: No mod_perl for Apache 2.0.x in Debian ?

[Andres Salomon]

I assume you mean mod_perl2.  This is in experimental:
http://packages.debian.org/cgi-bin/search_packages.pl?keywords=libapache2-mod-perl2

I shall upload 1.99.08 in a bit.


On Tue, 15 Apr 2003 11:08:13 +0200, Vincent Renardias wrote:

> 
> Hello,
> 
> See subject: is this package missing from our archive or did I simply
> overlooked it ?
> 
> Cordialement,

Re: Many ports open by default

[Andres Salomon]

Why would you keep something around if you don't want to run it?  Debian
makes the (correct) assumption that if you've installed something, you
want to run it.  If i install bind, it will assume i want it to run.  If
i install exim, it will first configure it for me (prompting me), and
then assume i want to run it.  Why should portmap be any different?
The question you should be asking is, why is portmap installed by default?
Similiarly, is there something that can be done during installation that
asks the user if certain things (nfs) that require portmap should be
installed.  If there's nothing that depends on portmap, then default
to not installing portmap.  Having daemons shut off by default is
not the way to go, however.


On Sun, Apr 29, 2001 at 10:29:58PM -0600, Dwayne C. Litzenberger wrote:
> 
> Why does a server automatically get run just because it's installed?  For
> instance, portmap is installed by default whether you're using NFS or not, and
> bnetd runs even if I just installed the package for bnchat.  Shouldn't the
> default be to not run daemons unless they are explicitly enabled, like an
> "exit" at the beginning of all daemon-starting init scripts that must be
> commented out?
> 
> -- 
> Dwayne C. Litzenberger - [EMAIL PROTECTED]



-- 
"... being a Linux user is sort of like living in a house inhabited
by a large family of carpenters and architects. Every morning when
you wake up, the house is a little different. Maybe there is a new
turret, or some walls have moved. Or perhaps someone has temporarily
removed the floor under your bed." - Unix for Dummies, 2nd Edition
-- found in the .sig of Rob Riggs, [EMAIL PROTECTED]

Re: Many ports open by default

[Andres Salomon]

On Sun, Apr 29, 2001 at 11:43:43PM -0700, Aaron Lehmann wrote:
> 
> On Mon, Apr 30, 2001 at 02:25:34AM -0400, Andres Salomon wrote:
> > Why would you keep something around if you don't want to run it?  Debian
> > makes the (correct) assumption that if you've installed something, you
> > want to run it.
> 
> That's not true. inetd is depended on by the lame metapackage netbase,
> but I do not want to run inetd.
> 

I completely agree; however, this is a bug in netbase.  AJ obviously
disagrees (bug #92465) w/ me. :P


-- 
"... being a Linux user is sort of like living in a house inhabited
by a large family of carpenters and architects. Every morning when
you wake up, the house is a little different. Maybe there is a new
turret, or some walls have moved. Or perhaps someone has temporarily
removed the floor under your bed." - Unix for Dummies, 2nd Edition
-- found in the .sig of Rob Riggs, [EMAIL PROTECTED]

Re: About the current state of the Yum package in Lenny

[Andres Salomon]

On Sat, 14 Feb 2009 10:08:49 +0100
Luk Claes  wrote:

> Thomas Goirand wrote:
> > Hi,
> > 
> > Even though Debian is not RPM based, it's very important to have a
> > working Yum package in Debian, just to be able to setup all sorts
> > of yum based distribution in a chroot for setting-up VMs.
> 
> Indeed.
> 
> > Unfortunately, it seems that the current maintainer of Yum in Debian
> > haven't been active for a long time, and the current package in
> > Lenny is simply not working. I consider that having a non-working
> > yum package in Debian Lenny is a grave regression.
> 
> I've put the co-maintainer in Cc so he can comment on whether he wants
> to take over full maintainership or wants extra co-maintainers or
> wants to orphan the package...
> 
> > With a little bit of communication, I've been able to make a
> > working yum package, and I could setup a CentOS on a Xen dom0 Lenny
> > server. Please read this:
> > 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496137
> > 
> > Having yum working means that we need the python-iniparse and
> > python-gpgme packages (which will both reach SID after Lenny is
> > out, as said the new package maintainers), as SHOULD depend on it.
> > The Lenny version doesn't unfortunately.
> 
> Why is the python-iniparse also needed? That's not clear from the bug
> report.
> 
> > My proposal, as it's of course too late for the first release of
> > Lenny, is that python-iniparse and python-gpgme, plus a patched
> > version of Yum, would be prepared and send in "lenny proposed
> > updates". The thing is that:
> > 
> > - I don't know what is the way to send it to proposed updates
> 
> http://www.debian.org/releases/proposed-updates
> 
> > - I'm not comfortable with python packages, and I don't think it's a
> > good idea that I take over the maintainership of yum in Debian, even
> > though I really need this package. Any volunteer out there?
> 
> Waiting for an answer of the co-maintainer...
> 
> Cheers
> 
> Luk

I was only working on it on behalf of OLPC.  Since I'm no longer with
them, I don't really have any interest in working on it.  I would suggest
giving it to someone who has a use for it.


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

Re: interested in (co-)maintaining midori

[Andres Salomon]

On Sun, 28 Jun 2015 05:17:01 -0700
Andres Salomon  wrote:

> Hi,
> 
> I'm interested in helping out with Midori packaging.  I'm not sure
> who's still interested in the package at this point (I know Corsac
> isn't, so I didn't Cc him).  I've created a git branch for the 0.5.10
> release here:
> 
> git://lunge.queued.net/git/midori
> http://lunge.queued.net/gitweb/?p=midori;a=shortlog;h=refs/heads/0.5.10
> 
> It builds (on sid and jessie) and runs (on jessie) for me, though it
> definitely needs more work tightening up deps, cleaning up lintian
> errors, etc.
> 
> I'm happy to co-maintain the package, or take it over; whatever folks
> prefer.  Please let me know what I should do, since it was never
> formally orphaned.


I haven't heard anything regarding this, and it's been over a month.
Should I just clean up my midori packages and upload?  If I don't hear
anything back and there's no activity with the package, that's my
plan.

[d-d, please Cc me on responses; I'm not subscribed to the list]


-- 
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/20150801135002.2f310...@e7240.queued.net

Re: interested in (co-)maintaining midori

[Andres Salomon]

On Fri, 07 Aug 2015 15:39:54 -0400
Sergio Durigan Junior  wrote:

> On Saturday, August 01 2015, Andres Salomon wrote:
> 
> >> I'm interested in helping out with Midori packaging.  I'm not sure
> >> who's still interested in the package at this point (I know Corsac
> >> isn't, so I didn't Cc him).  I've created a git branch for the
> >> 0.5.10 release here:
> >> 
> >> git://lunge.queued.net/git/midori
> >> http://lunge.queued.net/gitweb/?p=midori;a=shortlog;h=refs/heads/0.5.10
> >> 
> >> It builds (on sid and jessie) and runs (on jessie) for me, though
> >> it definitely needs more work tightening up deps, cleaning up
> >> lintian errors, etc.
> >> 
> >> I'm happy to co-maintain the package, or take it over; whatever
> >> folks prefer.  Please let me know what I should do, since it was
> >> never formally orphaned.
> >
> >
> > I haven't heard anything regarding this, and it's been over a month.
> > Should I just clean up my midori packages and upload?  If I don't
> > hear anything back and there's no activity with the package, that's
> > my plan.
> 
> Hi Andres,
> 
> I saw your message only yesterday, sorry about that.  As it turns
> out, I have also been working on getting Midori fixed.  My intention
> is to maintain it; Thadeu Cascardo is going to help me take over the
> package. However, as you are also willing to co-maintain the package,
> maybe we could create a group on Alioth to work together?

There's already a midori packaging group/git repo:

http://anonscm.debian.org/cgit/collab-maint/midori.git/

My repo is based on this, and my plan was to get access permission
from Corsac after uploading the package to sid.  Then I could push
my changes, maintaining history.  That would be my preference.

> 
> I also looked at your branch.  What I am doing is basically a
> "repackaging", from scratch, trying to figure out what's important and
> what's not.  I'll publish my branch later today.

Why from scratch?

I'll take a look at your branch once it's published.

> 
> So, any opinions on how to proceed?
> 
> Thanks,
> 


-- 
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/20150807225117.4a586...@e7240.queued.net

Re: interested in (co-)maintaining midori

[Andres Salomon]

On Fri, 14 Aug 2015 02:39:08 -0400
Sergio Durigan Junior  wrote:

> On Saturday, August 08 2015, I wrote:
> 
> >> I'll take a look at your branch once it's published.
> >
> > Thanks.  I have just published it:
> >
> >   
> >
> > This is *not* based on the official repository, but that's just
> > because I found it more convenient.  As I said above, I intend to
> > merge it to the original repository very soon.
> 
> Hello,
> 
> Did you guys have time to look at my repository?  I have just pushed a
> few more changes.  In fact, I might as well incorporate my changes
> into the official repository, and make it ready to be used if needed.
> Unfortunately I have been working on this during my spare time, which
> has been very little lately, so I'm not progressing as fast as I
> wished.  Nevertheless, things are almost ready; I would just like to
> make a few adjustments.

Yes, I took a look.  I still don't understand why you're starting from
scratch.  I also don't understand why you didn't look at my work, which
was done back in June (yours appears to be committed in August?), and
calls debhelper with things like:

"dh_auto_install -O--buildsystem=cmake"

http://lunge.queued.net/gitweb/?p=midori;a=commitdiff;h=f47a9488f9a26b8e751a25368def76bca7f33c0b


> 
> Andres, have you thought about my proposal of creating a group for
> packaging Midori?  Can I go ahead and request this group on Alioth?
> 
> Comments about the current state of the repository are welcome, of
> course.
> 
> Cheers,
> 

Re: interested in (co-)maintaining midori

[Andres Salomon]

On Fri, 14 Aug 2015 14:09:46 -0400
Sergio Durigan Junior  wrote:

> On Friday, August 14 2015, Andres Salomon wrote:
> 
> > On Fri, 14 Aug 2015 02:39:08 -0400
> > Sergio Durigan Junior  wrote:
> >
> >> On Saturday, August 08 2015, I wrote:
> >> 
> >> >> I'll take a look at your branch once it's published.
> >> >
> >> > Thanks.  I have just published it:
> >> >
> >> >   <http://git.sergiodj.net/?p=debian/midori.git;a=summary>
> >> >
> >> > This is *not* based on the official repository, but that's just
> >> > because I found it more convenient.  As I said above, I intend to
> >> > merge it to the original repository very soon.
> >> 
> >> Hello,
> >> 
> >> Did you guys have time to look at my repository?  I have just
> >> pushed a few more changes.  In fact, I might as well incorporate
> >> my changes into the official repository, and make it ready to be
> >> used if needed. Unfortunately I have been working on this during
> >> my spare time, which has been very little lately, so I'm not
> >> progressing as fast as I wished.  Nevertheless, things are almost
> >> ready; I would just like to make a few adjustments.
> >
> > Yes, I took a look.  I still don't understand why you're starting
> > from scratch.
> 
> Hi Andres,
> 
> As I explained in my previous message, "starting from scratch" is not
> really true in this case; I shouldn't have used this expression,
> sorry. What I am doing is cleaning things up and try to come up with
> a nicer package than what we have now.  But as you can see, I have
> also used many pieces of the "old" package.

Yes, I understand, but doing it this way makes it much harder for me to
review your work (which is why I waited a week to give it more
than a cursory glance, since it's currently one huge patch).

> 
> >  I also don't understand why you didn't look at my work, which
> > was done back in June (yours appears to be committed in August?),
> > and calls debhelper with things like:
> >
> > "dh_auto_install -O--buildsystem=cmake"
> >
> > http://lunge.queued.net/gitweb/?p=midori;a=commitdiff;h=f47a9488f9a26b8e751a25368def76bca7f33c0b
> 
> I looked at your work.  I thought I had mentioned that.
> 
> First, I don't see the need to override some rules just to pass
> "-O--buildsystem=cmake"; debhelper is smart enough to figure that out,
> it seems.  I am not using this extra flag and things are working
> totally fine for me.

Cool, I'll try that out.

> 
> A second thing is that your work still contains old stuff that could
> be removed/tweaked.  For example, I noticed that the original shlibs
> file contains wrong entries when you build the new package; that's
> why I had to override it with a hand-made one (as well as provide a
> lintian-override file to silence warnings because of the "unused
> shlibs", which are actually Midori plugins).
> 

Right.  I'm not claiming my work was complete; just that it works and
is based on the old git repo.


> Your work was done back in June, so if you prefer I can provide
> patches against your branch to implement/fix the issues I have been
> working on. It won't really matter much, I think: in the end, we'll
> have to use the "official" repository anyway and patch it.
> 

That would be highly preferred, simply for reviewing purposes.  I'm
also happy to rewrite parts of my history to, for example, not include
the -O--buildsystem stuff.  But the existing git history is useful, and
I'd rather work from that.

Thanks!

armhf NEON exception for chromium

[Andres Salomon]

Hi,

The latest chromium is failing to build on armhf because upstream broke 
non-NEON builds. While that is technically an upstream bug, I'm not 
sure upstream is going to care enough to even accept a patch to fix it. 
I understand that the baseline for the armhf architecture is to not 
support NEON, but folks in #debian-arm suggested that I specifically 
ask for an exception for chromium.


At this point I'm pretty confident in assuming that folks running 13 
year old arm  boards or newer rpi zero boards with 512MB of ram will 
not be using that hardware to browse the web with debian's chromium 
package. That leaves those using chromium for scripts or ci tests (eg, 
jquery-timepicker) on older armhf boards. The ci.debian.net 
infrastructure is newer than buildds, so I hopeful that they're mostly 
(or entirely?) machines that support NEON. And of course, chromium 
built with NEON support should be at least a small speed improvement 
for users running the browser on newer arm v7 hardware, although I lack 
the hardware to quantify that.


So my proposal for chromium is this:
a) Enable NEON for chromium's armhf build.
b) Add a check in debian/rules for 'neon' in /proc/cpuinfo's Features: 
line, and fail to build if NEON is not present. This should ensure that 
any buildds or downstream builders don't waste resources 
configuring/building chromium on a non-NEON board only to have it fail 
somewhere in the middle.
c) Using the current shell script wrapper for chromium (which already 
checks for things like SSE3 cpu instructions on x86), check for NEON 
support at startup by also looking for the string 'neon' in 
/proc/cpuinfo; if NEON is not supported, print an error message and 
exit before launching the chromium binary.
d) Ask the buildd admins to restrict building of chromium from any 
Armada XP buildds, which appear to be the only armhf buildds left in 
rotation that lack NEON support. If they are unwilling/unable to do 
this, then I'll have to play the giveback game for armhf (step right 
up! everyone's a winner!), which I often end up having to do currently 
because the 2-3 day armhf builds will sometimes hang/crash halfway 
through.


Any thoughts on this? Please explicitly Cc me on replies, as I'm not 
subscribed to any of the lists.


Thanks,
Andres

Re: armhf NEON exception for chromium

[Andres Salomon]

On Fri, Sep 15 2023 at 08:30:20 PM +02:00:00, Paul Gevers 
 wrote:

Hi,

On 15-09-2023 17:52, Andres Salomon wrote:

Any thoughts on this?
Please be aware of bug #1036818 [1]. Currently /proc/cpuinfo is empty 
on

armel ci.debian.net workers. (I'm failing to spot neon in the list of
features of that machine.)

Paul

[1] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036818>


Thanks for the heads-up!

Ugh, even with that fix (which was merged upstream today), it looks 
like when you have arm64 bare metal with a qemu armhf VM, neon doesn't 
get included in /proc/cpuinfo despite arm64 supporting it as part of 
the core architecture. So my plan to deal with autopkgtest won't work..

Re: armhf NEON exception for chromium

[Andres Salomon]

On Fri, Sep 15 2023 at 03:00:05 PM -04:00:00, Andres Salomon 
 wrote:



On Fri, Sep 15 2023 at 08:30:20 PM +02:00:00, Paul Gevers 
 wrote:

Hi,

On 15-09-2023 17:52, Andres Salomon wrote:

Any thoughts on this?
Please be aware of bug #1036818 [1]. Currently /proc/cpuinfo is 
empty on

armel ci.debian.net workers. (I'm failing to spot neon in the list of
features of that machine.)

Paul

[1] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036818>


Thanks for the heads-up!

Ugh, even with that fix (which was merged upstream today), it looks 
like when you have arm64 bare metal with a qemu armhf VM, neon 
doesn't get included in /proc/cpuinfo despite arm64 supporting it as 
part of the core architecture. So my plan to deal with autopkgtest 
won't work..



Actually it sounds like there's a lot of overlap with arm64's asimd, so 
maybe checking for 'neon' *or* 'asimd' is the way to go.

Bug#1053256: ITP: bypass-paywalls-firefox-clean -- Firefox browser plugin to bypass various paywalls

[Andres Salomon]

Package: wnpp
Severity: wishlist
Owner: Andres Salomon 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: bypass-paywalls-firefox-clean
  Version : 3.3.5.0
  Upstream Contact: https://gitlab.com/magnolia1234
* URL : 
https://gitlab.com/magnolia1234/bypass-paywalls-firefox-clean
* License : MIT
  Programming Lang: Javascript 
  Description : Firefox browser plugin to bypass various paywalls

Add-on allows you to read articles from (supported) sites that implement a
paywall. You can also add a domain as custom site and try to bypass the
paywall.
.
Note: this plugin may leak information about your web browsing based on the
techniques used to bypass paywalls. For example, for some sites it will load
text from Google's webcache, thereby letting Google know that you read a
certain article. The plugin only operates on sites that you opt-into.


I use this package on both firefox and chromium, and would welcome this
to be co-maintained by Debian Mozilla Extension Maintainers if they're
interested. I've already got a working package, but I'm still trying to
figure out whether we really need separate source packages for the firefox
and chromium plugins.

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On Sun, 24 Oct 2021 15:06:50 -0400 Andres Salomon wrote:
> Stable (bullseye) still contains chromium 90, which has had many
> security issues. Testing & unstable contain 93, and stable should really
> be quickly updated via stable-security to at least chromium 93 (as its
> already been packaged and proven to build) or ideally 95 (the latest
> stable chromium release).
>
>
>


So what's happening with chromium in both sid and stable? I saw on 
d-release that it was removed from testing (#998676 and #998732), with a 
discussion about ending security support for it in stable. I'm willing 
to help out with chromium packaging if the problem is simply lack of 
time (or I could just as easily help with something like 
ungoogled-chromium, #939406, if the plan is to have that in debian 
instead). Either way, both as a user and a developer, it is really not 
great to have chromium in limbo.   :(

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 12/5/21 6:41 AM, Moritz Mühlenhoff wrote:

Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
Exactly that.

I'd suggest anyone who's interested in seeing Chromium supported to first
update it in unstable (and then work towards updated in bullseye-security).


I started doing just that: https://salsa.debian.org/dilinger/chromium 
(v96 and misc-fixes branches).


Michel, it looks like upstream deprecated use_x11 and now relies on 
ozone; do you have the patches for your ozone-based packages somewhere?


I tried just setting use_ozone=true in debian/rules, but there's a whole 
bunch of BUILD.gn inclusion stuff that breaks. Would save me a lot of 
time if you've already made it work.


Thanks,

Andres

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 12/13/21 5:31 PM, Moritz Muehlenhoff wrote:

On Sun, Dec 12, 2021 at 08:11:00PM -0500, Andres Salomon wrote:

On 12/5/21 6:41 AM, Moritz Mühlenhoff wrote:

Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
Exactly that.

I'd suggest anyone who's interested in seeing Chromium supported to first
update it in unstable (and then work towards updated in bullseye-security).

I started doing just that: https://salsa.debian.org/dilinger/chromium (v96
and misc-fixes branches).

As a side note: If any of the system/* patches cause issues, feel free to switch
to the vendored copies. Vendoring in general is frowned upon since it requires 
that
a fix in a libraries spreads out to all vendored copies, but for Chromium 
there's
a steady stream of Chromium-internal security issues anyway, so for all
practical purposes it doesn't make a difference if the Chromium security 
releases
also include a fix for a vendored lib like ICU.

Cheers,
 Moritz



I've got 96.0.4664.110 building on both bullseye and sid, and am currently

debugging some crashes. The only thing I had to vendor was some nodejs

libraries, although it's very tempting to take a chainsaw through the 
various


patches and re-vendor a bunch of other libraries as Jeff suggested. Still on

the v96 branch of https://salsa.debian.org/dilinger/chromium

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On Thu, 23 Dec 2021 01:49:53 -0500
Andres Salomon  wrote:

> On 12/13/21 5:31 PM, Moritz Muehlenhoff wrote:
> > On Sun, Dec 12, 2021 at 08:11:00PM -0500, Andres Salomon wrote:  
> >> On 12/5/21 6:41 AM, Moritz Mühlenhoff wrote:  
> >>> Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
> >>> Exactly that.
> >>>
> >>> I'd suggest anyone who's interested in seeing Chromium supported
> >>> to first update it in unstable (and then work towards updated in
> >>> bullseye-security).  
> >> I started doing just that:
> >> https://salsa.debian.org/dilinger/chromium (v96 and misc-fixes
> >> branches).  
> > As a side note: If any of the system/* patches cause issues, feel
> > free to switch to the vendored copies. Vendoring in general is
> > frowned upon since it requires that a fix in a libraries spreads
> > out to all vendored copies, but for Chromium there's a steady
> > stream of Chromium-internal security issues anyway, so for all
> > practical purposes it doesn't make a difference if the Chromium
> > security releases also include a fix for a vendored lib like ICU.
> >
> > Cheers,
> >  Moritz  
> 
> 
> I've got 96.0.4664.110 building on both bullseye and sid, and am
> currently
> 
> debugging some crashes. The only thing I had to vendor was some nodejs
> 
> libraries, although it's very tempting to take a chainsaw through the 
> various
> 
> patches and re-vendor a bunch of other libraries as Jeff suggested.
> Still on
> 
> the v96 branch of https://salsa.debian.org/dilinger/chromium
> 


Alright, crashes are solved and the packages are now usable. After some
cleanups (listing CVEs in changelogs, merging/pushing a bunch of
commits in my branch, possibly dropping strong stack protection from
builds to silence warnings from older clang versions, and going through
lintian errors/warnings), it should be ready to upload.

How should I handle this? NMU to sid, let people try it out, and then
deal with buster/bullseye? Upload everything all at once? I'm also
going to try building for buster, unless the security team doesn't
think I should bother. That may involve vendoring some additional
libraries, so we don't have to carry a bunch of additional patches.

I also haven't heard from anyone on the chromium team yet - should I
add myself as an uploader and do a normal (non-NMU) upload? Do any of
them care?

Thanks,
Andres

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 1/2/22 12:53 PM, Mattia Rizzolo wrote:

On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote:

I've got 96.0.4664.110 building on both bullseye and sid

Trying it, I see it still build-depends on python-jinja2.  That package
is now gone, so it's not actually buildable in sid anymore.

Correlated, do you know how long do they plan on keeping using python2?
That's plainly unsuitable, it really is not going to last much longer in
debian.



Sorry, I hadn't pushed the commits yet. I just did, but like I said I 
still need to clean 'em up.

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On Sun, 2 Jan 2022 20:15:01 +0100
Moritz Muehlenhoff  wrote:

> On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote:
> > How should I handle this? NMU to sid, let people try it out, and
> > then deal with buster/bullseye?  
> 
> Yeah, let's proceed with unstable first in any case.
> 
> > Upload everything all at once? I'm also
> > going to try building for buster, unless the security team doesn't
> > think I should bother.  
> 
> I saw
> https://salsa.debian.org/dilinger/chromium/-/commit/5c05f430e192961527ec9a64bbaa64401dc14d95
> , but buster now also includes LLVM/clang 11 (it was introduced to
> support a more recent Rust toolchain needed for Firefox), so you
> might be reduce complexity here further:
> https://tracker.debian.org/pkg/llvm-toolchain-11
> 
> It's in buster-proposed-updates since there hasn't been a point
> release since, but for the purposes of buster-security builds, it
> doesn't matter (they chroots have been modified to includen
> buster-proposed-updates temporarily):

Ah, very helpful, thanks! I'll give buster a try (just created
the 'v96-buster' branch). Between that and various backports, I think
we might be in good shape.

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On Sun, 2 Jan 2022 15:32:28 -0500
Andres Salomon  wrote:

> On Sun, 2 Jan 2022 20:15:01 +0100
> Moritz Muehlenhoff  wrote:
> 
> > On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote:  
> > > How should I handle this? NMU to sid, let people try it out, and
> > > then deal with buster/bullseye?
> > 
> > Yeah, let's proceed with unstable first in any case.
> >   
> > > Upload everything all at once? I'm also
> > > going to try building for buster, unless the security team doesn't
> > > think I should bother.
> > 
> > I saw
> > https://salsa.debian.org/dilinger/chromium/-/commit/5c05f430e192961527ec9a64bbaa64401dc14d95
> > , but buster now also includes LLVM/clang 11 (it was introduced to
> > support a more recent Rust toolchain needed for Firefox), so you
> > might be reduce complexity here further:
> > https://tracker.debian.org/pkg/llvm-toolchain-11
> > 
> > It's in buster-proposed-updates since there hasn't been a point
> > release since, but for the purposes of buster-security builds, it
> > doesn't matter (they chroots have been modified to includen
> > buster-proposed-updates temporarily):  
> 
> Ah, very helpful, thanks! I'll give buster a try (just created
> the 'v96-buster' branch). Between that and various backports, I think
> we might be in good shape.

Unfortunately it needs a newer nodejs than what's in buster, so I'll go
back to focusing on bullseye & sid for now.  :(

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

Thanks for testing! Are you doing this under sid?


On 1/3/22 7:39 AM, Mattia Rizzolo wrote:

On Sun, Jan 02, 2022 at 06:53:52PM +0100, Mattia Rizzolo wrote:

the v96 branch of https://salsa.debian.org/dilinger/chromium

FWIW, I'm trying to build it myself as well

Here it started chrashing as soon as I tried to open a new tab, and
after that it refuses to load my main profile (but it loads others).


Here is what it prints on the console:

mattia@warren /tmp % chromium
[3249439:3249439:0103/133254.120313:ERROR:power_monitor_device_source_stub.cc(11)]
 Not implemented reached in virtual bool 
base::PowerMonitorDeviceSource::IsOnBatteryPower()
[3249485:3249485:0103/133254.419923:ERROR:gpu_init.cc(457)] Passthrough is not 
supported, GL is desktop, ANGLE is
[3249485:3249485:0103/133254.445016:ERROR:sandbox_linux.cc(376)] 
InitializeSandbox() called with multiple threads in process gpu-process.
[3249439:3249468:0103/133258.019370:ERROR:chrome_browser_main_extra_parts_metrics.cc(226)]
 crbug.com/1216328: Checking Bluetooth availability started. Please report if 
there is no report that this ends.
[3249439:3249468:0103/133258.020176:ERROR:chrome_browser_main_extra_parts_metrics.cc(229)]
 crbug.com/1216328: Checking Bluetooth availability ended.
[3249439:3249468:0103/133258.020199:ERROR:chrome_browser_main_extra_parts_metrics.cc(232)]
 crbug.com/1216328: Checking default browser status started. Please report if 
there is no report that this ends.
[3249439:3249468:0103/133258.284415:ERROR:chrome_browser_main_extra_parts_metrics.cc(236)]
 crbug.com/1216328: Checking default browser status ended.
[3249439:3249439:0103/133259.591406:FATAL:accessibility_paint_checks.cc(60)] 
Check failed: node_data.GetNameFrom() == 
ax::mojom::NameFrom::kAttributeExplicitlyEmpty (kAttribute vs. 
kAttributeExplicitlyEmpty) 0x55c6fb7c92d0: BookmarkButton is focusable but has 
no accessible name or placeholder, and is not explicitly marked as empty.


Hm, that's a new one.

Looks like upstream turned those assert crashes into debug statements in 
newer releases. Please try to following patch:


https://chromium.googlesource.com/chromium/src/+/409b167aac2cd07f6606febcc2b6f3fa286ce749%5E%21/

If that doesn't help, also try the following:

https://chromium.googlesource.com/chromium/src/+/ed83cbdb051c676083dde799cfec982f721e5b68%5E%21/

That second one adds a SkipAccessibilityPaintChecks setting which will 
skip that whole code block.




BrowserRootView -> NonClientView -> OpaqueBrowserFrameView -> BrowserView -> 
TopContainerView -> BookmarkBarView -> BookmarkButton
#0 0x55c6ef3a2d79 (/usr/lib/chromium/chromium+0x824bd78)
[...]
#39 0x55c6eaa1052a _start
   r8:   r9: 7fffbda69a50 r10: 0008 r11: 
0246
  r12: 01d0 r13: 55c6f8cc8480 r14: 55c6f8cc8490 r15: 
7fffbda6a508
   di: 0002  si: 7fffbda69a50  bp: 7fffbda69ca0  bx: 
7f7cb6875540
   dx:   ax:   cx: 7f7cbdfe6891  sp: 
7fffbda69a50
   ip: 7f7cbdfe6891 efl: 0246 cgf: 002b0033 erf: 

  trp:  msk:  cr2: 
[end of stack trace]
[1]3249439 IOT instruction (core dumped)  chromium


(It looks like it's not immediatly obvious how to start it under gdb, so
I'm not providing a nicer stack trace)



In general, you install the -dbgsym packages and run chromium -g

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 1/4/22 11:46, Mattia Rizzolo wrote:

[...]
[413:413:0104/174404.300230:FATAL:render_process_host_impl.cc(4227)] Check 
failed: host->GetBrowserContext() == browser_context (0x645f47d0 vs. 
0x658dcb30) Single-process mode does not support multiple browser contexts.


Okay, that's funny - appears to be a fatal error due to being run under gdb.

I pushed a commit to the skip-a11y-checks branch, please give that a 
try. I need to take a look at other distributions that are shipping 
chromium to see if they're just disabling DCHECKs outright, or what.

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 1/4/22 15:15, Mattia Rizzolo wrote:

On Tue, Jan 04, 2022 at 02:50:20PM -0500, Andres Salomon wrote:

Okay, that's funny - appears to be a fatal error due to being run under gdb.

Well, it was also crashing outside of gdb ^^


I pushed a commit to the skip-a11y-checks branch, please give that a try. I
need to take a look at other distributions that are shipping chromium to see
if they're just disabling DCHECKs outright, or what.

build started...



Just took a look at fedora, arch, and ungoogle-chromium debian 
packaging. They're all setting is_official_build=true, which completely 
disables those DCHECKs. We should probably set it like that as well, 
although the dcheck_is_configurable=true thing that I added to the 
skip-a11y-checks branch should at least allow the DCHECKs to not be 
fatal - so there's no need to restart your build.