headers
Michael Gilbert | 1 Feb 04:13
Picon

Re: correct/ideal way to obtain root from a shell script

On Sat, 30 Jan 2010 22:58:20 +0000 Jon Dowland wrote:

> Hi folks,
> 
> I need to run a command as the superuser inside
> game-data-packager (gdp).  Up until now, I've been
> hardcoding a sudo invocation and depending on sudo.

maybe packaging isn't the best solution to the underlying problem?
wouldn't it be much more straightforward (from a user's perspective) if
the game data files were automagically loaded into an appropriate
location in their home dir rather packaged and installed into the root
file system?  

perhaps an additional utility could be provided (runnable with elevated
priviledge via user's method of choice) that packages the data from
their home dir and installs it to the root file system (that is if they
want it to be available for multiple users)?

anyway, just a thought.

mike
Permalink | Reply | 0 comments |
headers
Ben Finney | 1 Feb 04:40
Picon

Re: Bug#567816: ITP: htb-gen -- Simple and effective home/small/medium ISP bandwidth solution

Dererk <dererk <at> madap.com.ar> writes:

> I'm afraid I've to admit the description attached to the ITP is not
> going to be the final one, as I just copy&paste it from some parts of
> documentation as a reference.

When you have a new text for the package, please make use of
<URL:http://lists.debian.org/debian-l10n-english/> to get feedback and
suggestions for improvement.

--

-- 
 \      “Probably the earliest flyswatters were nothing more than some |
  `\    sort of striking surface attached to the end of a long stick.” |
_o__)                                                     —Jack Handey |
Ben Finney <ben <at> benfinney.id.au>
Permalink | Reply | 0 comments |
headers
Mike Hommey | 1 Feb 08:09

Re: correct/ideal way to obtain root from a shell script

On Sun, Jan 31, 2010 at 06:42:07PM +0000, Jon Dowland wrote:
> On Sun, Jan 31, 2010 at 01:14:35AM +0100, Josselin Mouette wrote:
> > Le samedi 30 janvier 2010 à 22:58 +0000, Jon Dowland a écrit : 
> > > I need to run a command as the superuser inside
> > > game-data-packager (gdp).  Up until now, I've been
> > > hardcoding a sudo invocation and depending on sudo.
> > 
> > Why do you need to run anything as root in a packaging tool?
> > 
> > Aren’t you looking for fakeroot instead?
> 
> gdp, by default, invokes dpkg to install the generated .deb
> file.

So what you are looking for is not a way to run something as root, but a
way to install a package as a user, which is different.

Something like apt-daemon is probably what you are looking for.

Mike

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
Permalink | Reply | 1 comment |
headers
Enrico Zini | 1 Feb 14:58
Picon
Favicon

Bug#567954: RFH: debtags -- Enables support for package tags

Package: wnpp
Severity: normal

I request assistance with maintaining the debtags package.

What I would like is a comaintainer who takes care of the everday
packaging chores (for example, redoing the fetch script to fix #481634
and #478590, or fixing the manpage in #542525).

I am looking for someone who already has packaging experience.

The package description is:
 debtags provides a system to download a database of package tags and keep
 it up to date.  A package tag is a small label that gets attached to a
 Debian package to represent one of its qualities.
 .
 A package tag database in the system can enable advanced package search
 techniques, and advanced package browsing functions in programs that
 support it.
 .
 This package has been made as a way to deploy and test package tags
 support until it gets integrated in the normal Debian workflow.

Ciao,

Enrico
Permalink | Reply | 0 comments |
headers
Enrico Zini | 1 Feb 15:00
Picon
Favicon

Bug#567955: RFH: apt-xapian-index -- maintenance tools for a Xapian index of Debian packages

Package: wnpp
Severity: normal

I request assistance with maintaining the apt-xapian-index package.

What I would like is a comaintainer who takes care of the everday
packaging chores (for example, testing and applying the patch for
#547074 and fixing #562078).

I am looking for someone who already has packaging experience.

The package description is:
 This package provides update-apt-xapian-index, a tool to maintan a Xapian
 index of Debian package information in /var/lib/apt-xapian-index.
 .
 update-apt-xapian-index allows plugins to be installed in
 /usr/share/apt-xapian-index to index all sorts of extra information, such as
 Debtags tags, popcon information, package ratings and anything else that would
 fit.
 .
 The index generated by update-apt-xapian-index is self-documenting, as it
 contains an autogenerated README file with information on the index layout and
 all the data that can be found in it.

Ciao,

Enrico
Permalink | Reply | 0 comments |
headers
Simon McVittie | 1 Feb 15:29
Picon
Favicon

Re: Debian policy update (3.8.4.0)

(Please cc me on this thread, I'm not subscribed to debian-devel.)

Goswin wrote:
> Looks fine from here. How does your -dev package look? The .so link, .la
> and .pc files (if any) are specifically important.

The -dev package has no Multi-Arch field, which seems to be how the multiarch
spec on the Ubuntu wiki intends things to be done? As such, I'm still using
/usr/lib for the -dev part.

It'd be somewhat more complex to rearrange things for a multiarch -dev package,
but could be done; I assume the recommended way to do that would be to use
"./configure --libdir=/usr/lib/${DEB_HOST_GNU_TYPE}"?

libdbus is probably an interesting example if you want to do that because it
has one architecture-dependent header file, which it places in ${libdir}, and
keeps the rest of /usr/include architecture-independent.

For the actual change I made, please see pkg-utopia svn or this commit mail:
http://lists.alioth.debian.org/pipermail/pkg-utopia-commits/2010-January/003534.html

The -dev package currently contains:
> /.
> /usr
> /usr/share
> /usr/share/doc
> /usr/share/doc/libdbus-1-dev
> /usr/share/doc/libdbus-1-dev/AUTHORS [and other docs]
> /usr/lib
> /usr/lib/libdbus-1.a
(Continue reading)

Permalink | Reply | 23 comments |
headers
Florian Weimer | 1 Feb 20:03
Picon

Re: Better tracebacks for C/C++ (and probably Ada & Fortran, too)

* Daniel Jacobowitz:

> On Sun, Jul 26, 2009 at 12:42:46AM +0200, Florian Weimer wrote:
>> I've built a small proof-of-concept library which creates Java-style
>> tracebacks for C and C++ programs.  In contrast to libc's backtrace()
>> function, it uses DWARF debugging information when available, so the
>> output is generally quite useful.  Debugging information is extracted
>> from the main executable and any loaded DSOs, or from the shadow debug
>> tree in /usr/lib/debug.
>
> Can't you do this just by forking addr2line and providing a shim layer
> that knows shared library load offsets?  That saves you the really
> grotty bits.

Thanks for the suggestion.  At least for tracebacks on crashes, this
seems to be an approach which works really well.  addr2line can even
generate virtual frames for inlined functions.

There are some drawbacks, though: addr2line doesn't print a separator
if it generates multiple frames, so it is necessary to invoke it with
a single address if you want to use the inlining data.  Resolving
symbols in libstdc++ doesn't work automatically for some reason (I
have to pass the /usr/lib/debug file as a workarond).  addr2line on
libstdc++ locations is quite slow, it adds a noticeable delay to the
traceback printing.  The build root/relative path distinction
sometimes present in the DWARF debugging information is not preserved.
There does not seem to be much control over the demangling; for
instance, I would rather use the plain, fully-qualified function name
(without argument types) if source line information is also available.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benjamin Drung | 1 Feb 20:34
Favicon

Bits from the Mozilla Extension Packaging Team

Hi,

This mail targets all developers, which maintain Mozilla extensions.

Source package name
===================

The source package name for extension should not contain the name of the
enhanced application. These prefixes should be dropped from the source
name:

firefox-
iceape-
icedove-
iceweasel-
mozilla-
thunderbird-

If the remaining string is too generic (for example, notify or sage),
the source package name should append -extension. For example,
firefoxnotify was renamed to notify-extension.

Binary package name
===================

The Mozilla extension packaging team decided to use xul-ext- (instead of
mozilla-, iceweasel-, etc.) as prefix for all Mozilla extensions [1].
This will group the extensions visually. There are currently 18
extensions that use this naming scheme already. Please rename the binary
package if not already done.
(Continue reading)

Permalink | Reply | 46 comments |
headers
Bill Allombert | 1 Feb 20:37
Picon
Favicon

Re: correct/ideal way to obtain root from a shell script

On Mon, Feb 01, 2010 at 07:30:23PM +0000, Jon Dowland wrote:
> gdp, by default, invokes dpkg to install the generated .deb
> file.
> 
> > I’ve been asking to move su-to-root to xdg-utils or
> > debianutils, but the situation is still stuck.
> 
> That sounds sensible.  Is there anything I can do to help?

Simply depends on the menu package which provide su-to-root, or
manage to convince xdg-utils upstream to provide xdg-su instead of asking
everyone to switch to policykit ?

> It looks like there might need to be a bit more
> join-the-dots between su-to-root and d-i's "disable root"
> question (to prime $SU_TO_ROOT_SU properly)

We need a solution that still works if user enable root password and disable
sudo after installation. Shadow will note tell you whether root has a password
or not. Maybe menu should have a debconf question (do you use sudo ?) that will
be prefilled by d-i. Technical advices and patches welcome.

Cheers, (Please CC me if you want an answer).
--

-- 
Bill. <ballombe <at> debian.org>

Imagine a large red swirl here.
Permalink | Reply | 5 comments |

Gmane