Re: Suggestion to developer tools

[Stefano Canepa]

On Fri, Mar 26, 2010 at 05:04:08PM -0500, ceduardo wrote:
> 2010/3/25 Brian Ryans :
> > Quoting ceduardo on 2010-03-18 17:32:27:
> >> What Do you developer tools sugges?
> >
If you use emacs for editing try its integration with gdb for
debugging. I like it. 

As a way to manage your source I think the best tool to learn are:
cmake and git.

Bye
Stefano

-- 
Stefano Canepa aka sc: s...@linux.it - http://www.stefanocanepa.it
Three great virtues of a programmer: laziness, impatience and hubris.
Le tre grandi virtù di un programmatore: pigrizia, impazienza e
arroganza. (Larry Wall)


signature.asc
Description: Digital signature

Why is srtp in testing?!?

[Jonas Smedegaard]

Hi fellow developers,

I maintain the packaging of SRTP for Debian.  I am quite happy that it 
finally entered testing.


But today when I wanted to do a minor update to the packaging, I 
discovered that my earlier -5 release for some reason hadn't been 
uploaded to Debian at all.


Now I am puzzled: 1.4.4~dfsg-4 is in testing.  The source package is 
arch-any, but the code fails to build on ia64, sparc and Hurd.


How could srtp enter testing without succesful build on some archs?!?


My question is not how to get srtp into testing the proper way: The -5 
that I prepared but failed to upload tightens to only known buildable 
archs (yes, help i much appreciated solving the underlying problems!).  
Question is how it happened without proper packaging hints on my side.



NB! Please cc me on responses to this - I am not subscribed to -devel.

Kind regards,

 - Jonas

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

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


signature.asc
Description: Digital signature

Re: Why is srtp in testing?!?

[Julien Cristau]

On Mon, Mar 29, 2010 at 11:27:41 +0200, Jonas Smedegaard wrote:

> Now I am puzzled: 1.4.4~dfsg-4 is in testing.  The source package is
> arch-any, but the code fails to build on ia64, sparc and Hurd.
> 
> How could srtp enter testing without succesful build on some archs?!?
> 
Missing build only prevent a package from moving to testing if they're
regressions (i.e. there are out of date binaries in unstable).

No need to change the packaging if the package already fails to build on
arches where it doesn't work.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: About new source formats for packages without patches

[Mark Brown]

On Sun, Mar 28, 2010 at 09:02:24AM +0200, Christian PERRIER wrote:

> I'm surprised by the resistance I see to these changes. I see the
> approach pushed by dpkg maintainers as fairly conservative with very
> progressive changes to existing packages and much respect for people
> who don't want to adopt the "new" source format.

> The currently debated change is to kindly suggest to maintainers who
> prefer sticking with 1.0 source format to mention this explicitely in
> their source tree. I really fail to see what is the burden in this.

Part of the issue here is that this was a default enabled lintian
warning (it's not any more, but it was).  Since a lot of people like to
keep their packages lintian clean this comes over as somewhat more
urgent than what you're suggesting above. 


-- 
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/20100329094514.ga13...@sirena.org.uk

Re: Suggestion to developer tools

[Tilo Schwarz]

On Thu, 18 Mar 2010 23:32:27 +0100, ceduardo  
 wrote:



Hi every body, thaks you for your suggestions.

Well I am learning about C, C++ and Linux programing, jeje I am trying
to be a Debian developer this is my objetive. On my practices use
emacs and others tools from console.

What Do you developer tools sugges?


vim + ctags + git (My personal favorite combo).

Regards,

Tilo


--
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/op.vabpe6m3a8e...@dellschleppa

Re: Why is srtp in testing?!?

[Jonas Smedegaard]

On Mon, Mar 29, 2010 at 11:34:39AM +0200, Julien Cristau wrote:

On Mon, Mar 29, 2010 at 11:27:41 +0200, Jonas Smedegaard wrote:

Now I am puzzled: 1.4.4~dfsg-4 is in testing.  The source package is 
arch-any, but the code fails to build on ia64, sparc and Hurd.


How could srtp enter testing without succesful build on some archs?!?

Missing build only prevent a package from moving to testing if they're 
regressions (i.e. there are out of date binaries in unstable).


No need to change the packaging if the package already fails to build 
on arches where it doesn't work.


Ah, I see.


Thanks for the enlightenment :-D


 - Jonas

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

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


signature.asc
Description: Digital signature

Re: About new source formats for packages without patches

[Julien BLACHE]

Ben Finney  wrote:

Hi,

>> The problem is that if debian/source/format is missing for one reason
>> or another, your package will be silently built as a 1.0 source
>> package.
>
> There's no need for it to be silent. The idea was raised that, after a
> period of silent deprecation, the recognition of source format 1.0 could
> cause a warning.

It's a well-known fact that every DD out there thoroughly reviews her
package's build log before uploading. Oh, wait, no, it isn't, quite the
contrary, actually.

> The only point I've been trying to understand is, regardless of how
> format 1.0 packages are handled once recognised, why the current
> undeclared format 1.0 packages can't be recognised as such indefinitely
> without any change in those packages.

Because there's no way to tell if it's an old 1.0 package or a 3.0 or
later package missing debian/source for whatever reason.


FWIW I think debian/source/format sucks big time and its content should
be moved to debian/control.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
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/87iq8f77pq@sonic.technologeek.org

Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)

[Colin Watson]

On Mon, Nov 23, 2009 at 04:26:21PM +0100, Goswin von Brederlow wrote:
> Benjamin Drung  writes:
> > Am Montag, den 23.11.2009, 09:18 +0100 schrieb Goswin von Brederlow:
> >> Benjamin Drung  writes:
> >> > When a new upstream version is released, I have to check all patches if
> >> > they were accepted by upstream or not. I have to check each patch if I
> >> > can drop it. It would make packaging new releases easier if there were
> >> > an optional Applied-Upstream field. Every patch that was applied
> >> > upstream can be dropped. "no" or "not-yet" would indicate that the patch
> >> > was not applied yet. If the patch was applied, it could contain the
> >> > revision (like "r4681") or a link to the VCS commit.
> >> >
> >> > What do you think about my suggestion?

I'd also find this very useful.  I mentioned it in
http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2010-03-25-thoughts-on-3.0-quilt-format.html
before Raphaël pointed me at this thread.

> So what you want is (overly verbose)
> 
> Accepted-upstream: r1234 345836583468534854856834568395648
> Will-Be-Obsolete-in: 1.2
> 
> while you still only have upstreams 1.1 in Debian.
> 
> I think the idea is good. The implementation seems to be in
> doubt (where should it mention this, what should the field be called).
> I would like to have both the information when it was commited and
> when it will be released. The commit would be interesting because
> often it differs from the debian patch to accomodate the newer
> upstream developement. The release to know when the patch can be
> removed.

Yes, I agree we need both.  (For instance, I forwarded a bunch of
patches just before OpenSSH 5.4p1 was released, many of which will be in
5.5p1; I plan to upload 5.4p1 soon, but would also like to annotate
which patches are in 5.5p1.)

I don't know that we need to bother with two fields, though.  There's
precedent in DEP-3 for fields with internal structure; the format of
Origin is not dissimilar to what we need here.  How about something like
the following?

Index: dep3.mdwn
===
--- dep3.mdwn   (revision 142)
+++ dep3.mdwn   (working copy)
@@ -178,6 +178,14 @@
 This field can be used to record the date when the meta-information
 was last updated. It should use the ISO date format `-MM-DD`.
 
+  * `Applied-Upstream` (optional)
+
+This field can be used to document the fact that the patch has been
+applied upstream. It may contain the upstream version expected to
+contain this patch, or the URL or commit identifier of the upstream
+commit (with commit identifiers prefixed with "commit:", as in the
+`Origin` field), or both separated by a comma and a space.
+
 Sample DEP-3 compliant headers
 --
 
@@ -217,6 +225,15 @@
 Bug-Debian: http://bugs.debian.org/265678
 Author: Thiemo Seufer 
 
+A patch submitted and applied upstream:
+
+Description: Fix widget frobnication speeds
+ Frobnicating widgets too quickly tended to cause explosions.
+Forwarded: http://lists.example.com/2010/03/1234.html
+Author: John Doe 
+Applied-Upstream: 1.2, 
http://bzr.example.com/frobnicator/trunk/revision/123
+Last-Update: 2010-03-29
+
 Related links
 -
 

Thanks,

-- 
Colin Watson   [cjwat...@debian.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/20100329104624.ga17...@master.debian.org

Re: About new source formats for packages without patches

[Raphael Hertzog]

On Mon, 29 Mar 2010, Julien BLACHE wrote:
> FWIW I think debian/source/format sucks big time and its content should
> be moved to debian/control.

Actually it's a design decision to put it outside of the control file:
it's easier to create/modify/discard automatically when needed.

I expect this to be of particular interest when we'll have VCS-powered
source formats (say "3.0 (git2quilt)") that generate source packages that
are plain "3.0 (quilt)" based on the git repository information.
For example, when importing historical version of the source package, you
might want to be able to discard/overwrite the source format information.

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


-- 
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/20100329105133.gd8...@rivendell

no updates since three days?

[Norbert Preining]

Is it possible that in the last three days nothing has been updated
or uploaded, or did I miss some important announcement? (was off
for some time in the moutains)

Since several days aptitude does not show any updates at all.

Best wishes

Norbert

Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, JapanTU Wien, Austria   Debian TeX Task Force
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

Now it is such a bizarrely improbable coincidence that
anything so mindboggingly useful could have evolved purely
by chance that some thinkers have chosen to see it as the
final and clinching proof of the non-existence of God.
The argument goes something like this: `I refuse to prove
that I exist,' says God, `for proof denies faith, and
without faith I am nothing.'
The Babel fish is a dead giveaway, isn't
it? It could not have evolved by chance. It proves you
exist, and so therefore, by your own arguments, you don't.
QED.'
 --- Douglas Adams, The Hitchhikers Guide to the Galaxy


-- 
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/20100329105627.gh7...@gamma.logic.tuwien.ac.at

Re: no updates since three days?

[Martin Zobel-Helas]

Hi, 

On Mon Mar 29, 2010 at 19:56:27 +0900, Norbert Preining wrote:
> Is it possible that in the last three days nothing has been updated
> or uploaded, or did I miss some important announcement? (was off
> for some time in the moutains)
> 
> Since several days aptitude does not show any updates at all.

you should read debian-devel-announce an it's follow-ups on this list.

http://lists.debian.org/debian-devel-announce/2010/03/msg00010.html
-- 
 Martin Zobel-Helas   | Debian System Administrator
 Debian & GNU/Linux Developer   |   Debian Listmaster
 Public key http://zobel.ftbfs.de/5d64f870.asc   -   KeyID: 5D64 F870
 GPG Fingerprint:  5DB3 1301 375A A50F 07E7  302F 493E FB8E 5D64 F870


-- 
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/20100329105923.gg18...@ftbfs.de

Re: no updates since three days?

[Norbert Preining]

On Mo, 29 Mär 2010, Martin Zobel-Helas wrote:
> you should read debian-devel-announce an it's follow-ups on this list.
> http://lists.debian.org/debian-devel-announce/2010/03/msg00010.html

Ah thanks, missed that one. Good to know that the uploads are not lost.

Best wishes

Norbert

Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, JapanTU Wien, Austria   Debian TeX Task Force
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

FARNHAM (n.)
The feeling you get about four o'clock in the afternoon when you
haven't got enough done.
--- Douglas Adams, The Meaning of Liff


-- 
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/20100329110440.gi7...@gamma.logic.tuwien.ac.at

Re: About new source formats for packages without patches

[Julien BLACHE]

Raphael Hertzog  wrote:

> I expect this to be of particular interest when we'll have VCS-powered
> source formats (say "3.0 (git2quilt)") that generate source packages that
> are plain "3.0 (quilt)" based on the git repository information.

This is becoming crazy, really.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
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/87eij3754s@sonic.technologeek.org

Bug#575817: ITP: django-auth-ldap -- LDAP authentication backend for Django

[Fladischer Michael]

Package: wnpp
Severity: wishlist
Owner: Fladischer Michael 
Owner: Fladischer Michael 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: django-auth-ldap
  Version : 1.0.2
  Upstream Author : Peter Sagerson 
* URL : http://bitbucket.org/psagers/django-auth-ldap/
* License : BSD
  Programming Lang: Python
  Description : LDAP authentication backend for Django

A Django authentication backend that authenticates against an LDAP
service. Configuration can be as simple as a single distinguished name
template, but there are many rich configuration options for working with
users, groups, and permissions.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkuwsccACgkQeJ3z1zFMUGaWmwCbBeM0+rmSjeC89+H8z83+fXdG
8wwAn3Blv+GF+lI0CnofkgwpvxFxoWVl
=JJYY
-END PGP SIGNATURE-



-- 
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/20100329135729.22730.28372.report...@fladi-uni.broker.freenet6.net

Re: About new source formats for packages without patches

[Sven Mueller]

Wouter Verhelst schrieb:
> I might want to have a file with "1.0 (non-native)" to have dpkg error
> out when I accidentally don't have a .orig.tar.gz file somewhere, for
> instance. As long as the absense of that file does not make things
> suddenly break, I don't think there's anything wrong with that.

I wholeheartedly agree here.

> Of course, this all conveniently ignores the fact that the above
> explicit non-native option isn't actually supported, which is
> unfortunate...

Didn't check for this: Is a bug open to request such a feature to
explicitly say "1.0 (native)" or "1.0 (non-native)"? I would also find
this option really useful

> [...]
>> I did say until dpkg is fixed. I think the fix in dpkg needs to be that
>> the lack of debian/source/format uniquely identifies source format 1.0
> 
> Unfortunately, "source format 1.0" actually encompasses *two* formats:
> native packages and non-native packages. I'm sure you've also
> incorrectly gotten native source packages on occasion when what you
> wanted was a non-native package.

Oh yes, unfortunately, I even once accidentally uploaded such a package
while doing a sponsored upload (did a rebuild but somehow managed to not
have the orig.tar.gz at the right place). Oh the shame ;-)

Regards,
Sven


-- 
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/4bb0fea7.5030...@debian.org

Re: About new source formats for packages without patches

[Russ Allbery]

Sven Mueller  writes:
> Wouter Verhelst schrieb:

>> Of course, this all conveniently ignores the fact that the above
>> explicit non-native option isn't actually supported, which is
>> unfortunate...

> Didn't check for this: Is a bug open to request such a feature to
> explicitly say "1.0 (native)" or "1.0 (non-native)"? I would also find
> this option really useful

There's really no meaningful difference between a hypothetical 1.0
(native) and the already-implemented 3.0 (native), so you can just use 3.0
(native) for that.

That doesn't solve the 1.0 (non-native) request, though, and I suspect
that's the more common case.

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


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

Packages up for adoption

[Luca Falavigna]

I'm asking for adopters for the following packages:

 * boa-constructor  http://bugs.debian.org/575844
 * drpython http://bugs.debian.org/575845
 * foff http://bugs.debian.org/575842
 * jokosher http://bugs.debian.org/575843
 * lfm  http://bugs.debian.org/575840
 * pythoncadhttp://bugs.debian.org/575839
 * qa-assistant http://bugs.debian.org/575841

Details are in the corresponding bug reports, if you're interested
please follow-up here or in the bugs.

Regards,

-- 
  .''`.
 :  :' :   Luca Falavigna 
 `.  `'
   `-


signature.asc
Description: PGP signature

Bug#575850: ITP: libspring-webflow-2.0-java -- Java MVC framework focused in View and Controller layers

[Miguel Landaeta]

Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta 

* Package name: libspring-webflow-2.0-java
  Version : 2.0.8.RELEASE
  Upstream Author : SpringSource, Inc.
* URL : http://springsource.org/webflow
* License : Apache-2.0
  Programming Lang: Java
  Description : Java MVC framework focused in View and Controller layers

The Web Flow module is a MVC extension that allows you to
define Controllers using a domain-specific-language. This
language is designed to model user interactions that require
several requests into the server to complete, or may be
invoked from different contexts. Provides:
 - A domain-specific-language for defining reusable
   controller modules called flows.
 - An advanced controller engine for managing conversational
   state.
 - First-class support for using Ajax to construct rich user
   interfaces.
 - First-class support for using JavaServerFaces with Spring.



-- 
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/20100329185131.ga9...@miguel.cc

Proposal: Automatic selection of hardware specific packages

[Guillem Jover]

Hi!

I've had this idea in my head for long, but as never found the time to
work on it, didn't feel appropriate to throw it to the wall and expect
someone else to implement it. Anyway, it seems to me it might be a nice
GSoC project, and not necessarily too complex. As I've my plate already
full, I'm not volunteering myself for mentoring, though. I'm CCing
de...@l.d.o as they should be in the loop and Petter as he was working
on integrating package data into discover-data at some point in the past,
which might be interested in mentoring.

Problem
~~~

I've always found it annoying that it's become very difficult to hunt
all packages that might be needed for or useful with the current
hardware on the system, and usually you tend to miss some. It might
be even trickier for non-technical users who might not even know they
need specific packages for something to work.

Proposal


Ideally the package manager front-ends would propose for installation to
the user all hardware related packages for currently detected hardware
in the system, or removal once such hardware is not present (although
that might need to be disabled for pluggable hardware). This could
include drivers, firmware, tools and applications [0]. There's a
distinction between packages that are required for something to work,
which could be handled somehow as Recommends, and packages which might
have additional functionality if the hardware is present, which could
be handled as Suggests.

Each package would provide a list of patterns for the hardware it
supports. Depending on their size, they could be provided in a new field
(for example Hardware-Id), or on a new control file (but then that would
need to get extracted from binary packages and collected into a foo-data
package for example) or something else. Those patterns would match
against the device IDs of cpu, pci, pnp, usb, eisa, dmi, pcmcia, acpi,
ieee1394, etc.

For some packages this information is already known, and can be
automatically extracted from some files (and possibly converted to the
chosen pattern format). For example X.Org drivers have an internal
list of patterns, not sure if those can be easily extracted, for Linux
kernel modules one can extract those with something like:

  ,---
  |PATH=/sbin:$PATH
  |
  |find -name '*.ko' | xargs modinfo -F alias | \
  |  egrep '^(pci|pnp|eisa|pcmcia|usb|acpi|dmi|ieee1394|ssb|wmi):'
  `---

[0] An incomplete list from when I looked into this could include:

  Drivers
  ---

  xserver-xorg-video-*, xserver-xorg-input-*, *-source, firmware-*

  Tools
  -

  Graphic cards: gatos, radeontool, rovclock, atitvout, s3switch,
i810switch, matroxset, nvclock, nvtv, libglide3.
  Sound cards: awesfx, ld10k1.
  Webcams: qcam, qpcr1k, pencam.
  CPUs: athcool, set6x86.
  Laptops: i8kutils, fnfxd, fnfx-client, toshset, toshutils, tpb,
spicctrl.
  Printers: foomatic-db-hpijs, hpijs, hplip, hpoj.
  SCSI: scsitools, sg-utils.

Design and Implementation
~

Things to decide and work on, would include:

 * The format of the patterns for each hardware type. There's
   existing examples that could be either reused or based for
   inspiration.

 * A tool to extract at package build time as much of the IDs as
   possible from existing files and convert them to the normalized
   form, if need be. (Ideally independent of any packaging helper.)

 * Consider and decide where to ship such information.

 * It might be a good idea to be able to have a global override, for
   testing purposes, and a faster initial deployment, once a working
   implementation is in place those could be moved to each package.

 * Decide how to make the front-ends use the information, for example
   by creating a shared library that does the detection and matching,
   and just returns the list of packages, or through an external
   program (say a new hwsel, or maybe just adapting and/or extending
   disover or any of the other hardware detectors to be easily integrated
   with the front-ends), etc.

 * The actual integration with the front-ends.

regards,
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/20100329215154.ga30...@gaara.hadrons.org

Re: Proposal: Automatic selection of hardware specific packages

[Ben Hutchings]

On Mon, 2010-03-29 at 23:51 +0200, Guillem Jover wrote:
> Hi!
> 
> I've had this idea in my head for long, but as never found the time to
> work on it, didn't feel appropriate to throw it to the wall and expect
> someone else to implement it. Anyway, it seems to me it might be a nice
> GSoC project, and not necessarily too complex. As I've my plate already
> full, I'm not volunteering myself for mentoring, though. I'm CCing
> de...@l.d.o as they should be in the loop and Petter as he was working
> on integrating package data into discover-data at some point in the past,
> which might be interested in mentoring.
> 
> Problem
> ~~~
> 
> I've always found it annoying that it's become very difficult to hunt
> all packages that might be needed for or useful with the current
> hardware on the system, and usually you tend to miss some. It might
> be even trickier for non-technical users who might not even know they
> need specific packages for something to work.
[...]

There are also some hardware-specific drivers and tools that may be
useful to some users but should not be recommended because they depend
on out-of-tree kernel drivers that conflict with the in-tree drivers.
Any solution should avoid conflating 'works with this device' and
'recommended on systems with this device'.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: Proposal: Automatic selection of hardware specific packages

[Frans Pop]

> Ideally the package manager front-ends would propose for installation to
> the user all hardware related packages for currently detected hardware
> in the system, or removal once such hardware is not present (although
> that might need to be disabled for pluggable hardware).

The implementation would IMO also to some extend need to be aware of the 
environment into which the installation is taking place. On a Gnome 
desktop system it should propose Gnome packages, on a KDE desktop system 
it should propose equivalent KDE packages.


-- 
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/201003300219.27189.elen...@planet.nl

Best practices for development workstations

[John Goerzen]

Hi folks,

I'm trying to solicit comments on what people are using for development
environments and how well it's working.  Here are some situations I
imagine are common:

1. workstation running sid

I've followed this model for over a decade.  It works well, in general,
and I keep up with development well enough that I can fix problems when
they arise.  However, it tends to lead to a certain amount of cruft over
the years.  Moreover, it's not really appropriate for a laptop or a
situation in which Internet access isn't readily available to fix
problems.  I'm hoping to move away from that model.

2. workstation running squeeze or lenny

I'm enjoying squeeze on my laptop and am considering switching my
workstations to it.  That, of course, means I will still need a sid
environment somewhere for building.  It also means that there are times
when the packages I build for sid will not be installable on my
workstation, which could be annoying.  On the other hand, breakage
should be more rare.

It will require some solution for sid, though.

2a. pbuilder

pbuilder, or some other chroot such as schroot, can help.  In theory, it
is a good plan.  I don't have to dedicate a lot of RAM to it.  The
problem is that a chroot doesn't establish terribly strict separation
from the main environment.  Despite promises to the contrary, I've had
weird things happen; for instance, an MTA, database server, or some
other daemon process might try to fire up from within the chroot, which
can result in highly confusing situations.  I am therefore somewhat
uncomfortable with this prospect.

The ability to easily rebuild a chroot is appealing.  However, I do not
have a fast mirror at home; my "broadband" connection is just barely
broadband.  pbuilder highly recommends a local or a fast mirror.  So I
am concerned about this approach for security reasons as well.

2b. Xen, KVM, qemu, or VirtualBox

The advantage of this approach is that it provides more complete
isolation from the host workstation.  I need not worry about it firing
up a second copy of cron, for instance.  On the other hand, it will have
less perfect integration with the host environment (though NFS and ssh
could probably let me write a script like pdebuild).  It will also
consume more resources, and especially more RAM and disk space, neither
of which can be as easily scaled up and down in this setup.

There is qemubuilder, but it seems to not support KVM, alas.

Suggestions?

-- John


-- 
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/4bb13fb4.4070...@complete.org

Re: Best practices for development workstations

[Russ Allbery]

John Goerzen  writes:

> 1. workstation running sid

> I've followed this model for over a decade.  It works well, in general,
> and I keep up with development well enough that I can fix problems when
> they arise.  However, it tends to lead to a certain amount of cruft over
> the years.  Moreover, it's not really appropriate for a laptop or a
> situation in which Internet access isn't readily available to fix
> problems.  I'm hoping to move away from that model.

> 2. workstation running squeeze or lenny

> I'm enjoying squeeze on my laptop and am considering switching my
> workstations to it.  That, of course, means I will still need a sid
> environment somewhere for building.  It also means that there are times
> when the packages I build for sid will not be installable on my
> workstation, which could be annoying.  On the other hand, breakage
> should be more rare.

I use a combination of the two of these except with testing on my primary
workstation (the one that I can't afford to have go down), but list and
deprioritize sid in sources.list on the workstation running testing.  Then
when testing builds of my own applications, I let apt resolve dependencies
from unstable where needed.

I've never had any trouble with running sid on my laptop other than
occasionally finding bugs (which is one big advantage of doing this; I
find and report bugs).  I just don't do upgrades while I'm travelling.  I
wait until I'm home again and have access to other systems and ways of
repairing the box.

> 2a. pbuilder

> pbuilder, or some other chroot such as schroot, can help.  In theory, it
> is a good plan.  I don't have to dedicate a lot of RAM to it.  The
> problem is that a chroot doesn't establish terribly strict separation
> from the main environment.  Despite promises to the contrary, I've had
> weird things happen; for instance, an MTA, database server, or some
> other daemon process might try to fire up from within the chroot, which
> can result in highly confusing situations.  I am therefore somewhat
> uncomfortable with this prospect.

I do all my builds with pbuilder and cowdancer, but don't do testing in
that environment.  I've never had problems with weird things happening
during the build itself.

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


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

Re: Best practices for development workstations

[Paul Wise]

On Tue, Mar 30, 2010 at 8:03 AM, John Goerzen  wrote:

> 1. workstation running sid

I used that until DebConf9 when I reinstalled and switched from i386 to amd64.

> 2. workstation running squeeze or lenny

At the moment I have only one workstation (a laptop). I use testing,
unstable and experimental, with pinning setup to upgrade within that
suite where I've upgraded a package, until the version migrates to a
lower suite.

This is not a total insurance against unbootability, for instance, due
to the fact that my system sometimes needs to boot from USB and grub
not being able to install itself to the disk a UUID/LABEL is from
(only a specific device like /dev/sda) , my /boot/grub got out of sync
with my MBR and grub couldn't find the right files so I needed Debian
Live to recover from this.

One problem with this approach is that you aren't helping to test sid,
filing bugs and so on, instead letting others do that work. If many
folks do this, testing will get more buggy over time. I plan to
rectify my contribution to sid by getting a fast desktop computer and
using that for testing sid.

My phone (OpenMoko) also runs Debian (and SHR, an OpenEmbedded-based
distro) too, I use the same setup as above, with one difference; my
pinning prefers stable, but sources.list doesn't reference lenny.
Probably I'll default to stable after squeeze is released.

> 2a. pbuilder

I'm using the cowbuilder variant of this for now.

> pbuilder, or some other chroot such as schroot, can help.  In theory, it
> is a good plan.  I don't have to dedicate a lot of RAM to it.  The
> problem is that a chroot doesn't establish terribly strict separation
> from the main environment.  Despite promises to the contrary, I've had
> weird things happen; for instance, an MTA, database server, or some
> other daemon process might try to fire up from within the chroot, which
> can result in highly confusing situations.  I am therefore somewhat
> uncomfortable with this prospect.

I've had problems with cowbuilder to, lighttpd FTBFS during [1] due to
lots of its tests failing.

1. http://wiki.debian.org/DebianThailand/MiniDebCamp2010/BSP

> So I am concerned about this approach for security reasons as well.

Could you detail your concerns here?

> 2b. Xen, KVM, qemu, or VirtualBox

qemu is too slow and my laptop doesn't have CPU virt bits so no KVM. I
used VirtualBox once when I was working on lilo RC bugs. I'd like to
use something more lightweight like LXC (or vserver) as a
pbuilder/sbuild backend at some point, haven't had the time to
investigate yet though.

-- 
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/e13a36b31003291802y5b1f9133ke14249807dc7f...@mail.gmail.com

Re: Best practices for development workstations

[Manoj Srivastava]

On Mon, Mar 29 2010, John Goerzen wrote:

> Hi folks,
>
> I'm trying to solicit comments on what people are using for development
> environments and how well it's working.  Here are some situations I
> imagine are common:
>
> 1. workstation running sid
>
> 2b. Xen, KVM, qemu, or VirtualBox

I have a desktop (and a separate laptop) both running Sid. I
 have a virtual machine that runs SELinux in strict mode  for package
 building on the desktop. I do not test on the build virtual machine;
 most of my testing is done on my desktop.

manoj
-- 
Kill Ugly Radio Frank Zappa
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


-- 
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/87k4su33ez@anzu.internal.golden-gryphon.com

Bug#575887: ITP: urg -- library to access Hokuyo URG/UTM laser range scanners

[Albert Huang]

Package: wnpp
Severity: wishlist
Owner: Albert Huang 
Owner: Albert Huang 


* Package name: urg
  Version : 0.8.11
  Upstream Author : Satofumi KAMIMURA 
* URL : 
http://www.hokuyo-aut.jp/02sensor/07scanner/download/urg_programs_en/   
* License : LGPL
  Programming Lang: C, C++
  Description : library to access Hokuyo URG/UTM laser range scanners
  
 Hokuyo infrared laser range scanners provide range measurements to nearby
 objects using LIDAR technology.  Uses include factory automation for automated
 safety systems and robotics research platforms.
 . 
 urg provides libraries and an API for controlling and reading data from Hokuyo
 sensors.



-- 
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/20100330051649.4709.59555.report...@ocha.csail.mit.edu