Re: Candidates for removal from testing (2013-01-24)

2013-01-25 Thread Josselin Mouette 
Le vendredi 25 janvier 2013 à 07:15 +0100, Christian PERRIER a écrit : 
> Quoting Niels Thykier (ni...@thykier.net):
> 
> > Pierre Chifflier 
> >glpi
> 
> I looked briefly at the RC bug for glpi (#694642). It seems that an
> embedded Flash file provided with the package has a security issue.

It does, however:
- the SWF file is not used from the JS library, which points directly to
the upstream site (ugh),
- the code that makes use of it is not used from anywhere in the GLPI
code itself (re-ugh).

So all in all it is ugly (as in most PHP webapps), but it doesn’t seem
release-critical to me.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1359104000.27214.28.camel@pi0307572

Re: Candidates for removal from testing (2013-01-24)

2013-01-25 Thread Pierre Chifflier 
On Fri, Jan 25, 2013 at 07:15:43AM +0100, Christian PERRIER wrote:
> Quoting Niels Thykier (ni...@thykier.net):
> 
> > Pierre Chifflier 
> >glpi
> 
> I looked briefly at the RC bug for glpi (#694642). It seems that an
> embedded Flash file provided with the package has a security issue.
> 
> I have no clue at all if this .swf file is of critical use for GLPI
> (from the directory tree, it seems to be provided in a "resource"
> directory, so maybe not of big importance).
> 
> Still, it would be sad to have GLPI disappear from Debian for this, as
> this is one of the good free implementations of computer asset
> management systems and quite widely popular in France.
> 
> Pierre, have you noticed that? I dont see any contribution of yours in
> #694642, so you may have missed this release critical bug
> 
> 

Hi,

Sadly, I just discovered this bug. I have checked my mailbox, but have
found no trace of any received mail, maybe because it was reaffected to
glpi after another package ?
Anyway, I'm working on it to have glpi fixed today or in the next few
days.
glpi embeds a copy of extjs, I think the best fix will be to
remove it and replace it by symlinks to the proper Debian package.

I would like to ask the release team not to remove glpi, for the reasons
Christian gave.

Regards,
Pierre



signature.asc
Description: Digital signature

Re: Candidates for removal from testing (2013-01-24)

2013-01-25 Thread Paul Wise 
n Fri, Jan 25, 2013 at 4:53 PM, Josselin Mouette wrote:

> So all in all it is ugly (as in most PHP webapps), but it doesn’t seem
> release-critical to me.

The SWF files do not appear appear to have source code in glpi.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Call for DebConf volunteers and DebConf14/15 bids

2013-01-25 Thread Andreas Tille 
Hi,

On Fri, Jan 25, 2013 at 02:26:00AM +, Moray Allan wrote:
> 
> 3. Please consider joining the DebConf team, whether or not you are
> associated with a future bid!  There are many possible ways to help in
> the months before DebConf, including technical contributions,
> fundraising, or specific tasks like talk scheduling.  Ask how you can
> help on the DebConf team list, or drop by the #debconf-team channel on
> irc.debian.org.

As in some previous years I'd volunteer in talks selection and
scheduling.
 
> See you in Switzerland (and maybe see some of you at FOSDEM first),

Looking foreward (to both ;-))

  Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130125104634.gc27...@an3as.eu

Re: Backports upgrade policy (ButAutomaticUpdates:yes)

2013-01-25 Thread Wookey 
+++ martin f krafft [2013-01-25 16:06 +1300]:
> also sprach David Kalnischkies  [2013.01.25.0020 
> +1300]:
> > You can find much of the same discussion in the bugreport requesting
> > implementation of this feature in APT: #596097
> 
> Thanks for the pointer! I missed this discussion un^Wfortunately.
> Anyway, it seems that most people are in favour of this change, and
> your message pretty much sums up the reasons.

You message was not usless as I never knew about the 100 < P < 500
feature, and the need to pin/not pin according to what effect you
wanted vs AutomaticUpdates setting. Making this info more widely known
would be a useful service so that people get the behaviour they want.

(maybe it already is and I'm the only one no-one told, but I doubt it
:-)

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130125114839.gj5...@stoneboat.aleph1.co.uk

Re: Backports upgrade policy (ButAutomaticUpdates:yes)

2013-01-25 Thread Henrique de Moraes Holschuh 
On Fri, 25 Jan 2013, Wookey wrote:
> +++ martin f krafft [2013-01-25 16:06 +1300]:
> > also sprach David Kalnischkies  [2013.01.25.0020 
> > +1300]:
> > > You can find much of the same discussion in the bugreport requesting
> > > implementation of this feature in APT: #596097
> > 
> > Thanks for the pointer! I missed this discussion un^Wfortunately.
> > Anyway, it seems that most people are in favour of this change, and
> > your message pretty much sums up the reasons.
> 
> You message was not usless as I never knew about the 100 < P < 500
> feature, and the need to pin/not pin according to what effect you
> wanted vs AutomaticUpdates setting. Making this info more widely known
> would be a useful service so that people get the behaviour they want.
> 
> (maybe it already is and I'm the only one no-one told, but I doubt it
> :-)

Sorta.  It is in manpage apt_preferences(5), but...

Now, complete documentation of the Release files, where the tags you can use
in repositories to get such nice functionality like ButAutomaticUpdates...
Does anyone know where such a thing might dwell?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130125131900.ga29...@khazad-dum.debian.net

Re: Linux Future

2013-01-25 Thread Vincent Lefevre 
On 2013-01-23 20:45:49 -0800, Russ Allbery wrote:
> Adam Borowski  writes:
> 
> > There are two ways to design a system:
> > * a monolithic well-integrated system, granting features and efficiency at
> >   the cost of portability and hackability
> > * the traditional Unix way, with a stress on replaceable tools that do only
> >   one thing, granting freedom to tinker, using the system in a way not
> >   envisioned by its creators
> 
> ...at the cost of occasional complex, difficult-to-debug interactions
> between the separate components, and a larger total code base to support
> fallbacks and alternatives to provide loose coupling between the
> components.

I disagree. A monolithic system makes things more difficult to debug,
in particular when one needs to include 3rd-party code, because
everything gets tainted (e.g. the Linux kernel + non-free drivers,
Firefox + extensions...). A clean separation between components with
a good specification makes more clear where a bug can be.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130125134737.ga25...@xvii.vinc17.org

Re: Backports upgrade policy (ButAutomaticUpdates:yes)

2013-01-25 Thread Guillem Jover 
On Fri, 2013-01-25 at 11:19:00 -0200, Henrique de Moraes Holschuh wrote:
> Now, complete documentation of the Release files, where the tags you can use
> in repositories to get such nice functionality like ButAutomaticUpdates...
> Does anyone know where such a thing might dwell?

I don't think there's a central place for complete documentation for
most if not all index files, the times that I've had to check this
stuff out, I've had to read various projects source code (dak, apt,
dpkg-scan*, etc).

I've had in mind for a while now to add man pages for the indices to
dpkg, even if there's currently no dpkg-dev script making use or
generating Releases files, I think it makes sense to put it there as
it's on the lowest layer of the stack. I'll try to get those in for
1.17.x, if no one else sends patches. :)

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130125140820.ga22...@gaara.hadrons.org

Re: Bootstrappable Debian - proposal of needed changes

2013-01-25 Thread Michael Biebl 
Hi,

looking over your proposal, I was missing a few things (sorry if this
was mentioned in one of the replies, I've only skimmed over the thread).

a/ It's good practice to explicitly enable/disable features via
configure switches, to have reliable build results in tainted build
environments. What's the plan to annotate such optional features and
manage the configure switches in debian/rules?

b/ You mentioned documentation (gtk-doc) as optional build dependency.
Same packages do not ship the documentation in a separate binary
package, but as part of the -dev package. Is there an idea to annotate
optional files in .install files, so dh_install will not fail if files
are missing when building certain profiles or is there an alternative
idea how to handle this?


Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Backports upgrade policy (ButAutomaticUpdates:yes)

2013-01-25 Thread David Kalnischkies 
On Fri, Jan 25, 2013 at 2:19 PM, Henrique de Moraes Holschuh
 wrote:
> On Fri, 25 Jan 2013, Wookey wrote:
>> +++ martin f krafft [2013-01-25 16:06 +1300]:
>> > also sprach David Kalnischkies  [2013.01.25.0020 
>> > +1300]:
>> > > You can find much of the same discussion in the bugreport requesting
>> > > implementation of this feature in APT: #596097
>> >
>> > Thanks for the pointer! I missed this discussion un^Wfortunately.
>> > Anyway, it seems that most people are in favour of this change, and
>> > your message pretty much sums up the reasons.
>>
>> You message was not usless as I never knew about the 100 < P < 500
>> feature, and the need to pin/not pin according to what effect you
>> wanted vs AutomaticUpdates setting. Making this info more widely known
>> would be a useful service so that people get the behaviour they want.
>>
>> (maybe it already is and I'm the only one no-one told, but I doubt it
>> :-)
>
> Sorta.  It is in manpage apt_preferences(5), but...
>
> Now, complete documentation of the Release files, where the tags you can use
> in repositories to get such nice functionality like ButAutomaticUpdates...
> Does anyone know where such a thing might dwell?

Assuming s/Now/No/ … apt_preferences(5) is in fact the most complete
documentation on this matter as there are only these two flags in regards
to pinning (the other "special" values for pinning should not be made
 available to repositories as I described in the original bugreport).

If you on the other hand mean what a Release (and various other) files can
generally contain I would refer you to the discussion we had last year in
May on debian-devel. You can delve into it from #481129 and #671503.
WIP-Result: https://wiki.debian.org/RepositoryFormat

If I remember correctly the short version is: Having an ftp-master approved
debian-policy appendix defining this would be very welcomed, but needs
input from various teams which already have no time to work on all the tasks
they already have … :/


Best regards

David Kalnischkies


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

Re: Candidates for removal from testing (2013-01-24)

2013-01-25 Thread Steven McDonald 
Hi there,

On Thu, 24 Jan 2013 15:47:08 +0100 (CET)
ni...@thykier.net (Niels Thykier) wrote:

> # #696816
> remove jenkins/1.447.2+dfsg-2

Just for the information of anybody reading this thread, I have just
submitted a fix for this bug. It was a trivial backport; the bug was
already fixed in upstream git (and in experimental).

Thanks,
Steven.


signature.asc
Description: PGP signature

Bug#698951: ITP: libattica -- Attica is a Qt library that implements the Open Collaboration Services API version 1.6.

2013-01-25 Thread rm 
Package: wnpp
Severity: wishlist
Owner: rm 

* Package name: libattica
  Version : 4.0.1
  Upstream Author : Jonas Erlandsson 
* URL : http://www.kde.org
* License : LGPL
  Programming Lang: C++, QT
  Description : Attica is a Qt library that implements the Open
Collaboration Services API version 1.6.
 It grants easy access to the services such as querying information about
persons and contents.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130125165922.4226.37620.reportbug@debian

Re: Linux Future

2013-01-25 Thread Uoti Urpala 
Russ Allbery wrote:
> Adam Borowski  writes:
> 
> > There are two ways to design a system:
> > * a monolithic well-integrated system, granting features and efficiency at
> >   the cost of portability and hackability
> > * the traditional Unix way, with a stress on replaceable tools that do only
> >   one thing, granting freedom to tinker, using the system in a way not
> >   envisioned by its creators
> 
> ...at the cost of occasional complex, difficult-to-debug interactions
> between the separate components, and a larger total code base to support
> fallbacks and alternatives to provide loose coupling between the
> components.
> 
> Just to complete both sides of the picture.  (I'm more of a second camp
> person myself, but they both have drawbacks.)
> 
> The traditional UNIX way is great if everyone can agree on a clean and
> minimal API between the components that enables thorough independent
> testing of the components and minimizes complex multi-component
> interactions.  Were that this were always the case  Most of the places
> where people reach for other strategies are places where it's not clear
> those conditions hold.
> 
> Whenever you have a complex programming problem, break it into a client
> and a server.  Now you have two complex programming problems, a protocol
> design problem, and a security vulnerability.

I'd add to this that the appropriate approach to the same problem can
change over time. Using modular components can be a good strategy when
you're trying to get the basic functionality working and it's likely it
turns out you need to completely redo parts of the approach. However,
when increasing the quality of something, it's natural for integration
level to go up. Few real problems are truly modular. At a basic level
you have can just have independent "parser for file format X" and "IO
layer", but when you get closer to optimal program behavior, "parse file
format X when input comes from disk" and "parse file format X when input
comes from network stream" may no longer be the same task.

You could build a basic browser from components like UI for displaying
bitmaps and relaying mouse clicks, an IO layer, and a HTML renderer that
lists required extra resource files, then after getting the contents of
those returns a rendered bitmap of the page. These could have simple
APIs and could be developed by different people with little interaction.
But when you move to higher-quality browsers, you'll at least need APIs
with hundreds of elements. Those will require the developers to
cooperate much more closely, and it won't be easy to switch to an
"equivalent" component.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1359133652.1887.25.camel@glyph.nonexistent.invalid

Re: multiarch dependency hell. build amd64, can't install without also building i386

2013-01-25 Thread Thorsten Glaser 
Paul Johnson  gmail.com> writes:

> I've just learned that, if I build amd64 packages, I can't install
> them for testing because I've not also built the i386 packages.

Just test in cowbuilder --login.

> That's really inconvenient! I don't understand why there has to be a
> linkage between the shared library versions on amd64 and i386. Aren't
> they separate?

No. Not in Multi-Arch, which is about sharing those things that aren’t
separate across architectures in packages of the precisely same version.

HTH & HAND,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20130125t221327-...@post.gmane.org

Re: Candidates for removal from testing (2013-01-24)

2013-01-25 Thread Ben Hutchings 
On Thu, 2013-01-24 at 18:56 -0500, Andrew Starr-Bochicchio wrote:
> On Thu, Jan 24, 2013 at 9:47 AM, Niels Thykier  wrote:
> > Debian QA Group 
> >bzr-gtk
> 
> >   --8<8<-- removals --8<8<--
> > # #697402
> > remove bzr-gtk/0.103.0+bzr792-3
> 
> As jwilk has already mentioned in the bug report, [1] this should be
> assigned elsewhere. Though, it is not exactly clear where.
> 
> To briefly summarize, the bug is that having bzr-gtk and python-gtk2
> installed at the same time causes "pydoc -k foobarbaz" to crash. This
> is because pydoc imports all packages in order to find out what
> modules they contain.
[...]

I'm surprised that doesn't result in disaster more often...

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.


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