Re: update on binary upload restrictions

[Marc Haber]

On Thu, 25 Jan 2007 01:23:35 +, James Troup <[EMAIL PROTECTED]>
wrote:
>(o) logging 
>
>The build logs at buildd.debian.org are invaluable in trying to debug
>problematic builds.  Byhand builds and other unofficial builds often
>don't send an associated log to buildd.debian.org.

Is it technically and/or socially possible to send build logs to
buildd.debian.org?

>(o) build effort coordination
>
>There's a reason the buildd suite is called 'wanna-build'.  The core
>of it, both when Roman first wrote it all those years ago and now, is
>the sensible and efficient coordination of builds amongst multiple
>build daemons.  Having a random additional build daemon that's not
>part of the 'wanna-build' system breaks this and all the advantages it
>brings.

Has it become technically and/or socially easier to get access to
wannabuild? I remember that rejection or "no answer" is the usual
reaction to a wannabuild access request even for architectures that
are in trouble.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Suggesting new method to handle dpkg diversions

[Mike Hommey]

On Thu, Jan 25, 2007 at 01:20:47AM -0600, Peter Samuelson <[EMAIL PROTECTED]> 
wrote:
> 
> [keeping debian-devel CC, this seems to still be relevant]
> 
> [Goswin von Brederlow]
> > What if each package could list all its current diversions in
> > DEBIAN/diverions (i.e. in the control.tar.gz)? Upon install dpkg
> > would then add those diversions to its list and removed them on
> > deinstall. During updates it would add new diversions before
> > unpacking and remove obsolete diversions after removal of old files.
> 
> Sounds to me like a job for a 'dh_diversions' script, and
> 'debian/packagename.diversions' files in the source package.  Or maybe
> a 'dh_alternatives' that handles both alternatives and diversions,
> since they are similar concepts and alternatives are a great deal more
> common.

That wouldn't handle removing (some of) them between 2 versions of a
package. This would be possible with specially crafted .diversions files
but you possibly never get away with old diversions, and bloat the
.diversions files. OTOH, doing it at dpkg level is just simpler from the
maintainer POV.

Mike


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

Re: Suggesting new method to handle dpkg diversions

[Peter Samuelson]

[keeping debian-devel CC, this seems to still be relevant]

[Goswin von Brederlow]
> What if each package could list all its current diversions in
> DEBIAN/diverions (i.e. in the control.tar.gz)? Upon install dpkg
> would then add those diversions to its list and removed them on
> deinstall. During updates it would add new diversions before
> unpacking and remove obsolete diversions after removal of old files.

Sounds to me like a job for a 'dh_diversions' script, and
'debian/packagename.diversions' files in the source package.  Or maybe
a 'dh_alternatives' that handles both alternatives and diversions,
since they are similar concepts and alternatives are a great deal more
common.

Presumably slave alternatives would be handled by indenting the slave
line just under its master.

Peter


signature.asc
Description: Digital signature

Re: update on binary upload restrictions

[Greg Folkert]

On Wed, 2007-01-24 at 19:10 -0800, Steve Langasek wrote:
> On Wed, Jan 24, 2007 at 09:15:44PM -0500, Joey Hess wrote:
> > > [2] Unfortunately there was very little notice of goedel's move and it
> > > was originally scheduled only to take a couple of days but was
> > > unavoidably delayed by external factors.
> 
> > I hope that one of the offers of hardware for an alpha buildd that
> > resulted in the meantime will be followed up on, so we get some
> > redundancy?
> 
> Has already been followed up on.  Tim Cutts has graciously offered the use
> of a 4-way ES45 system, which I expect DSA will be getting access to within
> the day.  (Oh, and this is hardware that it wasn't even possible to run
> Debian on until a month and a half ago, and the box was only recently
> decommissioned -- lest anyone try to play the "DSA should have accepted this
> a long time ago" card...)

But the DSA shoulda done it 3 years ago... you know before this idea
even came up. Regardless that it was only available 6 weeks ago.

meh, stupid realistic time-lines... who needs them.

Anywho, that is awesome.
-- 
greg, [EMAIL PROTECTED]

The technology that is
Stronger, better, faster:  Linux


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

Bug#408347: ITP: proda -- multiple alignment of protein sequences with repeated and shuffled elements

[Charles Plessy]

Package: wnpp
Severity: wishlist
Owner: Charles Plessy <[EMAIL PROTECTED]>

  Package name: proda
  Version : 1.0
  Upstream Author : Tu Minh Phuong, Chuong Do, Robert Edgar, and Serafim 
Batzoglou
  URL : http://proda.stanford.edu/
  License : Public domain
  Description : multiple alignment of protein sequences with repeated and 
shuffled elements

 ProDA is a system for automated detection and alignment of homologous
 regions in collections of proteins with arbitrary domain architectures.
 Given an input set of unaligned sequences, ProDA identifies all
 homologous regions appearing in one or more sequences, and returns a
 collection of local multiple alignments for these regions.
 .
 ProDA is published in: Phuong T.M., Do C.B., Edgar R.C., and Batzoglou
 S. Multiple alignment of protein sequences with repeats and
 rearrangements. Nucleic Acids Research 2006 34(20), 5932-5942.
 .
  Homepage: http://proda.stanford.edu/

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.16-2-486
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)


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

How to maintain packaging files for multiple distributions in the same tree?

[Øystein Gisnås]

Is there a good way to let Maemo-specific packaging files coexist with
Debian unstable files in the upstream tree? Currently there is a
debian/ upstream, but it is Debian unstable specific. Btw tinymail is
not part of the official Debian Archive.

The problem is that of maintaining packages files for several
distributions in the same tree, preferably by using diff techniques
between them.

Cheers,
Øystein Gisnås

-- Forwarded message --
From: Philip Van Hoof <[EMAIL PROTECTED]>
Date: 23.jan.2007 19:52
Subject: Re: compiling/packaging tinymail on maemo 3.0 (bora)
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], Øystein Gisnås <[EMAIL PROTECTED]>


Hey Oystein,


Is there a way to have a maemo-specific directory or control file? I can
imagine this would break the original debian package support.


On Tue, 2007-01-23 at 19:59 +0200, [EMAIL PROTECTED] wrote:

Hi all,

Just to share some findings; I am a bit of a debian packaging n00b,
but the following seems to work.

1) apply the patch
  - this removes dependencies that are not necessary/available
on the maemo 3.0 / bora platform
  - also it fixes the ICONV_10646 undefined issue
  - and it places the packages in Section: user/extra
  (otherwise the app manager on your 770/n800 will
  not accept it)
2) build the package with:
  $ DEB_CONFIGURE_USER_FLAGS="--with-platform=maemo"
dpkg-buildpackage -rfakeroot

BTW, there might be a problem running autogen.sh, as some of the m4
macros seem not
be correctly installed in bora; this seems like a bug; but can be worked
around
by manually copying the missing m4 files to /usr/share/aclocal. Ugly,
but it works.

The patch is not really suitable for non-bora tinymail, but hopefully I
(or someone
else) can come up with something better.

Best wishes,
Dirk.
___
tinymail-devel-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/tinymail-devel-list

Re: How to change the severity of a bug to serious???

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:
> On Wed, Jan 24, 2007 at 07:44:35PM -0600, Jacques Normand wrote:

>> I am trying to change the bug #383889 to serious and make it release
>> critical. I have explained in it why I want it RC and the document at
>> http://release.debian.org/etch_rc_policy.txt lists that

>> * makes unrelated software on the system (or the whole system)
>>   break

>> is a reason for rc-bug. In this case, the whole desktop locks and there
>> is no easy way to unlock it. (Which is effectively breaking the system).

>> So how do I do that?

> You seem to have gotten your answer on the procedure, but your rationale
> for upgrading this particular bug is flawed.  The package doesn't render
> the system unusable, it's your misconfiguration of PAM that does so.

You cannot enable verify_ap_req_nofail unless everything that's going to
do PAM configuration can read the system keytab file.  Most of the screen
savers run as a normal user and can't read the keytab unless it's readable
by the user running the screen saver.

Later versions of pam-krb5 will support configuring it to look at a
different keytab so that you can provide a lower-privilege world-readable
keytab for this purpose.  Until then, you either want to leave the
Kerberos library default, which will verify the tickets if the keytab is
readable and otherwise skip that step, or make the system keytab readable
by any user who may run the screen saver.

For more information, see:



The support alluded to in that bug is already implemented in the upstream
version of pam-krb5, but I also incorporated PKINIT support and the code
has been rather unstable.  I'm holding off upgrading the Debian package
until after the etch release.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: How to change the severity of a bug to serious???

[Steve Langasek]

severity 383889 important
thanks

On Wed, Jan 24, 2007 at 07:44:35PM -0600, Jacques Normand wrote:
> I am trying to change the bug #383889 to serious and make it release
> critical. I have explained in it why I want it RC and the document at
> http://release.debian.org/etch_rc_policy.txt lists that

> * makes unrelated software on the system (or the whole system)
>   break

> is a reason for rc-bug. In this case, the whole desktop locks and there
> is no easy way to unlock it. (Which is effectively breaking the system).

> So how do I do that?

You seem to have gotten your answer on the procedure, but your rationale for
upgrading this particular bug is flawed.  The package doesn't render the
system unusable, it's your misconfiguration of PAM that does so.

I've tested gnome-screensaver here and it work fine with this config.

/etc/pam.d/common-auth:
authsufficient  pam_krb5.so ignore_root
authrequiredpam_unix.so try_first_pass nullok_secure

/etc/pam.d/common-account:
account sufficient  pam_krb5.so
account requiredpam_unix.so


Note that the default /etc/pam.d/gnome-screensaver shipped is misleading; it
doesn't mention that this service will query the authorization functions
("acct") in addition to the authorization functions.  You may need to check
there for the source of your authentication problem.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: update on binary upload restrictions

[Steve Langasek]

On Wed, Jan 24, 2007 at 09:15:44PM -0500, Joey Hess wrote:
> > [2] Unfortunately there was very little notice of goedel's move and it
> > was originally scheduled only to take a couple of days but was
> > unavoidably delayed by external factors.

> I hope that one of the offers of hardware for an alpha buildd that
> resulted in the meantime will be followed up on, so we get some
> redundancy?

Has already been followed up on.  Tim Cutts has graciously offered the use
of a 4-way ES45 system, which I expect DSA will be getting access to within
the day.  (Oh, and this is hardware that it wasn't even possible to run
Debian on until a month and a half ago, and the box was only recently
decommissioned -- lest anyone try to play the "DSA should have accepted this
a long time ago" card...)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: update on binary upload restrictions

[Joey Hess]

James Troup wrote:
> alpha has recently had restrictions added because the main alpha
> buildd has been down due to relocation[2] for some time now and so, as
> a result, the number of byhand builds on random machines has shot up.
> Once Goedel is back (tomorrow - apparently) and if the byhand builds
> stop, these restrictions could be relaxed.

Sounds like you have a way to track the quantity and source of
binary-only uploads. Does it come down to perusal of the upload queue
and/or of wasted builds on the buildds, or is there something nicer,
like a list or graph?

(I'm looking for more data here, becuase I don't currently have enough
for an informed opinion about some of the factors underlying the
approach that you chose to deal with the problems you mentioned. If that
makes any sense..)

> [2] Unfortunately there was very little notice of goedel's move and it
> was originally scheduled only to take a couple of days but was
> unavoidably delayed by external factors.

I hope that one of the offers of hardware for an alpha buildd that
resulted in the meantime will be followed up on, so we get some
redundancy?

>  (b) source only uploads are in my experience very often badly tested
>  if they're even tested at all.  For a long time after Ubuntu
>  switched to source only uploads, it was really obvious that a
>  large number of them hadn't even been test built, never mind
>  installed or used.[3][4]

Hmm, are you implying that it eventually got better?

-- 
see shy jo, who's done the odd binary-only upload for arm before


signature.asc
Description: Digital signature

Re: How to change the severity of a bug to serious???

[Ben Finney]

Jacques Normand <[EMAIL PROTECTED]> writes:

> So how do I do that?

Much information about the Debian BTS is available at its website:

http://www.debian.org/Bugs/>

That page has a link to the information on manipulating bug reports
via email:

http://www.debian.org/Bugs/server-control>

-- 
 \   "Ice Water? Get some onions - that'll make your eyes water!"  |
  `\   -- Groucho Marx |
_o__)  |
Ben Finney


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

How to change the severity of a bug to serious???

[Jacques Normand]

Hi,

I am trying to change the bug #383889 to serious and make it release
critical. I have explained in it why I want it RC and the document at
http://release.debian.org/etch_rc_policy.txt lists that

* makes unrelated software on the system (or the whole system)
  break

is a reason for rc-bug. In this case, the whole desktop locks and there
is no easy way to unlock it. (Which is effectively breaking the system).

So how do I do that?

thanks

jacques


signature.asc
Description: Digital signature

update on binary upload restrictions

[James Troup]

Hi,

   Summary
   ===

I've done some work in dak to improve the binary upload restrictions
that are currently in place to hopefully reduce some of the collateral
damage that resulted from the initial implementation.  Binary upload
restrictions are now per-suite/component/architecture which means that
uploads to experimental and/or non-free should no longer be affected.
The current restrictions are listed below[1] for reference.


 Why restrictions on binary uploads?
 ===

So there are several reasons why these restrictions have been put in
place:

(o) reproducibility

It's vitally important that packages in our archive can be rebuilt on
our buildds and not require a custom environment or source
modifications or other special treatment.  When they can't, scaled
across as many packages and architectures as we have, it makes the job
of the security team nearly impossible.

The best (and IMO, only) pragmatic way of doing this is to actually
have built them on a real buildd.

(o) logging 

The build logs at buildd.debian.org are invaluable in trying to debug
problematic builds.  Byhand builds and other unofficial builds often
don't send an associated log to buildd.debian.org.

(o) build effort coordination

There's a reason the buildd suite is called 'wanna-build'.  The core
of it, both when Roman first wrote it all those years ago and now, is
the sensible and efficient coordination of builds amongst multiple
build daemons.  Having a random additional build daemon that's not
part of the 'wanna-build' system breaks this and all the advantages it
brings.

(o) emulated/cross-compiled buildd-ing considered potentially harmful

The idea of emulated buildds or cross compiling has been around for a
long time.  Personally I don't think it's a good idea, but that's not
really the point.  The point is that one person should not
unilaterally make the decision that they are or are not OK.  If it's
the consensus of the release managers and the architecture porting
team that they want to use emulated buildds and/or cross compiling, I
absolutely will not stop them from doing so.

---

(Now if at this point, you're thinking about source only uploads,
 please see [*].)


  Why are the current set of restrictions in place?
  =

arm has had restrictions in place ever since Aurelien decided to
unilaterally turn on emulated buildd(s) for arm with no consensus from
the arm porting team or the release managers.  This was problematic
for all the reasons listed above.  Also, fundamentally, arm was not in
trouble release-wise because it lacked build power, but because it
lacked _humans_ willing and able to deal with the failing builds.

alpha has recently had restrictions added because the main alpha
buildd has been down due to relocation[2] for some time now and so, as
a result, the number of byhand builds on random machines has shot up.
Once Goedel is back (tomorrow - apparently) and if the byhand builds
stop, these restrictions could be relaxed.

-- 
James

[1]


Binary-Upload-Restrictions
{
 Components
 {
   main;
   contrib;
 };
 unstable
 {
   arm
   {
 9BF093BC475BABF8B6AEA5F6D7C3F131AB2A91F5;
 70BC7F9D8C60D2265B7076A23760DBCFFD6645AB;
 F849E2025D1C194DE62BC6C829BE5D2268FD549F;
   };
   alpha 
   {
 9BF093BC475BABF8B6AEA5F6D7C3F131AB2A91F5;
 70BC7F9D8C60D2265B7076A23760DBCFFD6645AB;
   };   
  };
};


[2] Unfortunately there was very little notice of goedel's move and it
was originally scheduled only to take a couple of days but was
unavoidably delayed by external factors.




[*]

 Why not move to source only uploads?
 

A question that often comes up when this subject is discussed is 'hey,
I agree about the logging and reproducibility points above, so why not
move to source only uploads so you get those for all binaries?'

So, again, this is not something I personally think is a good idea but
I won't stand in the way of consensus of the Release Managers and the
developer community as a whole.  I think it's a bad idea for two
reasons:

 (a) we don't currently have the buildd infrastructure for this - it
 would require a minimum of 2 (preferably 3) machines dedicated to
 being i386 buildds.  It would also make i386 uploads much more
 sensitive to delays and really require better coverage than one
 human could provide.

 (b) source only uploads are in my experience very often badly tested
 if they're even tested at a

Bug#408315: ITP: mysql-workbench -- Official MySQL database schema designer / editor

[Tyler MacDonald]

Package: wnpp
Severity: wishlist
Owner: Tyler MacDonald <[EMAIL PROTECTED]>


* Package name: mysql-workbench
  Version : x.y.z
  Upstream Author : MySQL AB
* URL : http://dev.mysql.com/downloads/gui-tools/5.0.html
* License : GPL
  Programming Lang: C
  Description : Official MySQL database schema designer / editor

MySQL Workbench is a graphical tool for designing databases. It allows
database administrators to design database schemas visually, and existing
MySQL schemas can also be imported, edited in the graphical interface, then
re-exported to a MySQL database server.

This product is still in alpha, but appears to work well, and it already has
a lot of useful functionality.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1)


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

Re: ITP: Calc::Color -- it perl module.i am creating debian package'

[Ernesto Hernández-Novich]

On Wed, 2007-01-24 at 14:54 +0530, Deepak Kumar Tripathi wrote:
> Package: libcalccolor-perl
> 
> Severity:  wishlist

If you mean [1], I've already packaged it as libcolor-calc-perl [2].

[1] http://search.cpan.org/author/CFAERBER/Color-Calc-1.04/Calc.pm
[2] http://packages.debian.org/unstable/perl/libcolor-calc-perl
-- 
Ernesto Hernández-Novich - Linux 2.6.17 i686 - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can't aptitude it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 438C 49A2 A8C7 E7D7 1500 C507 96D6 A3D6 2F4C 85E3


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

Bug#408287: ITP: keyjnotegui -- KDE frontend for the presentation programm KeyJnote

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko <[EMAIL PROTECTED]>


* Package name: keyjnotegui
  Version : 0.3.4
  Upstream Author : Sebastian Wiesner <[EMAIL PROTECTED]>
* URL : http://developer.berlios.de/projects/keyjnotegui
* License : GPL
  Programming Lang: Python
  Description : KDE frontend for the presentation programm KeyJnote
 
 Provides easy access to the most common options of keyjnote from a 
 simple gui:
  - page transitions to use
  - fullscreen control
  - geometry size
  - caching of images/pages
  and others

-- System Information:
Debian Release: testing/unstable
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-amd64-generic
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)


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

Suggesting new method to handle dpkg diversions

[Goswin von Brederlow]

Hi,

I'm CCing debian-devel because many developers might have run into
diversion troubles and might be intrested in this but aren't
subscribed on debian-dpkg. Please reply only there.


Have you ever used dpkg-divert in a package? Ever run into the problem
how to properly remove a diversion on upgrade or remove? In what
script to do it? Limited to which $1 arguments?

To me it seems like diversions are more complicated than they could be
and coupled with the dpkg bug in sarge a nightmare.

What if each package could list all its current diversions in
DEBIAN/diverions (i.e. in the control.tar.gz)? Upon install dpkg would
then add those diversions to its list and removed them on
deinstall. During updates it would add new diversions before unpacking
and remove obsolete diversions after removal of old files.

I think most diversions could be handled this way simplifying the
maintainer scripts and removing the risk of screwing it up. Dpkg would
take care to install/update/remove diversions in the right order and
packages could not leave old diversions behind by mistake.

To implement this there would have to be a way to mark packages as
supporting the DEBIAN/diversions file so dpkg can see if the package
has no diversions or just doesn't follow the new method. I haven't
thought about that part yet.

Thoughts, ideas, comments?
Now tell me I'm nuts.

MfG
Goswin


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

Re: x86 buildd for experimental ?

[Raphael Hertzog]

On Wed, 24 Jan 2007, Steffen Moeller wrote:
> > All packages that can be autobuilt on i386 have been autobuilt, and that
> > was finished more than a week ago. But nice to hear that "nothing" has
> > happened.
> 
> The original poster certainly was not aware of the experimental.debian.net 
> site. I have seen it announced on some mailing lists, but not too many sites 
> are linking to it, thus it is not easy to find while browsing.
> 
> In google:
> 
> link:http://www.debian.org -> 90.000 pages
> link:http://www.alioth.debian.org -> 10.000 pages
> link:http://buildd.debian.org -> 83 pages
> link:http://www.buildd.net -> 19 pages
> link:http://experimental.debian.net -> 1 page, debian-kernel mailing list 
> 2005, in a thread not unlike this one.
> 
> As a quick solution I suggest to place the experimental.debian.net link more 
> visibly at the various buildd-associated sites. 

FWIW, there's a link in the PTS next to "Build logs" there's a "more"
link.

Example:
http://packages.qa.debian.org/g/gnome-session.html points to 
http://experimental.debian.net/build.php?pkg=gnome-session

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

ITP:libdbd-mock-perl .A Debian package for perl module called DBD::Mock

[Deepak Kumar Tripathi]

Package: libdbd-mock-perl
Version: 1.34-1
Severity: wishlist

From: Deepak Tripathi <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: ITP:libdbd-mock-perl ,A debian package for DBD::Mock module
Maintainer: Debian Perl Group
[EMAIL PROTECTED]
Uploader:-  Deepak Tripathi  <[EMAIL PROTECTED]>
Upstrem Author: Chris Winters <[EMAIL PROTECTED]>, Stevan Little
<[EMAIL PROTECTED]>
X-Mailer: reportbug 3.8
Date: Tue, 23 Jan 2007 20:31:21 +0530
X-Debbugs-Cc: [EMAIL PROTECTED]


You can Download original tar from
http://search.cpan.org/CPAN/authors/id/R/RK/RKINYON/DBD-Mock-1.34.tar.gz

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-386
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)



PS:-I can not able to send it from console ,because some issue in
firewall.

Thanks
Deepak Tripathi





The information contained in, or attached to, this e-mail, contains 
confidential information and is intended solely for the use of the individual 
or entity to whom they are addressed and is subject to legal privilege. If you 
have received this e-mail in error you should notify the sender immediately by 
reply e-mail, delete the message from your system and notify your system 
manager. Please do not copy it for any purpose, or disclose its contents to any 
other person. The views or opinions presented in this e-mail are solely those 
of the author and do not necessarily represent those of the company. The 
recipient should check this e-mail and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused, directly or 
indirectly, by any virus transmitted in this email.

www.aztecsoft.com

Bug#407446: [Fwd: Re: Bug#407446: general: automatic mount network share in filesystem.]

[Josselin Mouette]

Le mercredi 24 janvier 2007 à 11:08 +0100, Jean-Michel a écrit :
> > This is already possible:
> >   * at the system level using the BSD automounter, see the example
> >   
> 
> > in the am-utils package;
> >   
> This seems to works with NFS.
> But what's about Samba?

I thought it was also mentioned in the examples. In all cases, you can
adapt the NFS scripts for samba, or find such scripts on Google.

> >   * in GNOME with gnome-vfs.
> >   
> This allows to browse the network, but is not compatible with every 
> application. Is it?

It is compatible with most GNOME applications and with OOo (with
openoffice.org-gnomevfs). That's less applications than with an
automounter, but it will handle authenticated access.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Bug #118715 and #246680

[Lionel Elie Mamane]

On Sat, Jan 20, 2007 at 09:07:28PM +0100, Turbo Fredriksson wrote:

> Is there no interest in fixing this even though there's patch(es!)?

A cursory glance suggests that code is not actively maintained (no
release since May 2005). That may be the reason the Debian bind
maintainers are reluctant to add this code to the package, they would
have to support it and fix eventual bugs themselves, etc.

> I can make a new one if asked, I'm running with this on all MY
> machines anyway.

Are you willing to handle all bug reports / fixes / ... for this code,
and becoming a comaintainer of bind9 for that purpose? Maybe they
would accept that. Or maybe not. I can't speak for them.

-- 
Lionel


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

ITP:libdbd-mock-perl ,A Debian Package for DBD::Mock module.

[Deepak Kumar Tripathi]

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Deepak Tripathi <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: ITP:libdbd-mock-perl ,A debian package for DBD::Mock module
Maintainer: Debian Perl Group
[EMAIL PROTECTED]
Uploader:-  Deepak Tripathi  <[EMAIL PROTECTED]>
Upstrem Author: Chris Winters <[EMAIL PROTECTED]>, Stevan Little
<[EMAIL PROTECTED]>
X-Mailer: reportbug 3.8
Date: Tue, 23 Jan 2007 20:31:21 +0530
X-Debbugs-Cc: [EMAIL PROTECTED]

Package: libdbd-mock-perl
Version: 3.7.2
Severity: wishlist

You can Download original tar from
http://search.cpan.org/CPAN/authors/id/R/RK/RKINYON/DBD-Mock-1.34.tar.gz

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-386
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)



PS:-I can not able to send it from console ,because some issue in
firewall.

Thanks
Deepak Tripathi




The information contained in, or attached to, this e-mail, contains 
confidential information and is intended solely for the use of the individual 
or entity to whom they are addressed and is subject to legal privilege. If you 
have received this e-mail in error you should notify the sender immediately by 
reply e-mail, delete the message from your system and notify your system 
manager. Please do not copy it for any purpose, or disclose its contents to any 
other person. The views or opinions presented in this e-mail are solely those 
of the author and do not necessarily represent those of the company. The 
recipient should check this e-mail and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused, directly or 
indirectly, by any virus transmitted in this email.

www.aztecsoft.com

Re: x86 buildd for experimental ?

[Steffen Moeller]

On Wednesday 24 January 2007 10:06, Marc 'HE' Brockschmidt wrote:
> Mike Hommey <[EMAIL PROTECTED]> writes:
> > On Wed, Jan 24, 2007 at 12:18:48AM +0100, Martin Zobel-Helas 
<[EMAIL PROTECTED]> wrote:
> >> On Tue Jan 23, 2007 at 20:51:27 +0100, Mike Hommey wrote:
> >>> (More than a few days later, it seems like still nothing is
> >>> happening...)
[...]
> It is. The missing packages are FTBFS due to insufficient
> build-dependencies. The build-logs for all packages are, as advertised,
> on experimental.debian.net.
>
> All packages that can be autobuilt on i386 have been autobuilt, and that
> was finished more than a week ago. But nice to hear that "nothing" has
> happened.

The original poster certainly was not aware of the experimental.debian.net 
site. I have seen it announced on some mailing lists, but not too many sites 
are linking to it, thus it is not easy to find while browsing.

In google:

link:http://www.debian.org -> 90.000 pages
link:http://www.alioth.debian.org -> 10.000 pages
link:http://buildd.debian.org -> 83 pages
link:http://www.buildd.net -> 19 pages
link:http://experimental.debian.net -> 1 page, debian-kernel mailing list 
2005, in a thread not unlike this one.

As a quick solution I suggest to place the experimental.debian.net link more 
visibly at the various buildd-associated sites. 

Many greetings

Steffen



pgp4zbaOBvRFO.pgp
Description: PGP signature

Bug#407446: [Fwd: Re: Bug#407446: general: automatic mount network share in filesystem.]

[Jean-Michel]

Sujet:
Re: Bug#407446: general: automatic mount network share in filesystem.
Expéditeur:
Josselin Mouette 
Date:
Fri, 19 Jan 2007 11:14:53 +0100

Destinataire:
Jean-Michel <>, [EMAIL PROTECTED]

Delivered-To:


Le jeudi 18 janvier 2007 à 14:55 +0100, Jean-Michel a écrit :
  

Package: general
Severity: wishlist


samba network share might be automagically mouted in file system.

share partage on computer machine from domain domaine, with user utilisateur 
shoud be
available in filesystem throw:

/network/samba/domaine/machine/utilisateur/partage/SomeFoldersFromRemoteComputer

In the same way that processes are available with /proc.

The only technical issue I see is when to provide password, and how to
store them.



This is already possible:
  * at the system level using the BSD automounter, see the example
  



in the am-utils package;
  

This seems to works with NFS.
But what's about Samba?

  * in KDE using kioslaves;
  


I do not know it.

  * in GNOME with gnome-vfs.
  
This allows to browse the network, but is not compatible with every 
application. Is it?

Re: ITP: Calc::Color -- it perl module.i am creating debian package'

[Damyan Ivanov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -=| Deepak Kumar Tripathi, 24.01.2007 11:24 |=-
> Package: libcalccolor-perl

Deepak,

I would have been nice if you used report bug and its support for
X-Debbugs-CC to send your ITP to debian-perl. Now I am not able to
comment directly to the bug log, since it is not yet available on
bugs.debian.org.

Your package name is wrong, did you read the perl packaging policy?

Also, You fail to mention the upstream source of the module. Is this the
same as the already packaged libcolor-calc-perl?


dam
- --
Damyan Ivanov   Modular Software Systems
[EMAIL PROTECTED]
phone +359(2)928-2611, 929-3993  fax +359(2)920-0994
mobile +359(88)856-6067 [EMAIL PROTECTED]/Gaim
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtyo/Hqjlqpcl9jsRAllkAJwP2AIR82XPLk3pvaZwWVv7HzLsEwCgrJ+i
zUHszb08swsOQrHJ6Bi56q4=
=NsU4
-END PGP SIGNATURE-


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

ITP: Calc::Color -- it perl module.i am creating debian package'

[Deepak Kumar Tripathi]

Package: libcalccolor-perl
Severity:  wishlist














Thanks
Deepak Tripathi



The information contained in, or attached to, this e-mail, contains 
confidential information and is intended solely for the use of the individual 
or entity to whom they are addressed and is subject to legal privilege. If you 
have received this e-mail in error you should notify the sender immediately by 
reply e-mail, delete the message from your system and notify your system 
manager. Please do not copy it for any purpose, or disclose its contents to any 
other person. The views or opinions presented in this e-mail are solely those 
of the author and do not necessarily represent those of the company. The 
recipient should check this e-mail and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused, directly or 
indirectly, by any virus transmitted in this email.

www.aztecsoft.com

Re: x86 buildd for experimental ?

[Marc 'HE' Brockschmidt]

Mike Hommey <[EMAIL PROTECTED]> writes:
> On Wed, Jan 24, 2007 at 12:18:48AM +0100, Martin Zobel-Helas <[EMAIL 
> PROTECTED]> wrote:
>> On Tue Jan 23, 2007 at 20:51:27 +0100, Mike Hommey wrote:
>>> (More than a few days later, it seems like still nothing is
>>> happening...)
>> i can see a couple of logs signed by Marc, so what do you complain about
>> exactly? Marc is working on all packages from experimental, though it
>> might take a while to build all packages in the right order do get all
>> packages (like gnome 2.10) compiled in the right order.
> I would assume 10 days is enough to "automatically" build all that
> is in experimental...

It is. The missing packages are FTBFS due to insufficient
build-dependencies. The build-logs for all packages are, as advertised,
on experimental.debian.net.

All packages that can be autobuilt on i386 have been autobuilt, and that
was finished more than a week ago. But nice to hear that "nothing" has
happened.

Marc


pgpgF5loxTmam.pgp
Description: PGP signature