Re: how to deal with a missed so bump already uploaded ?

[Julien Cristau]

On Sat, May 17, 2014 at 07:33:04 +0200, Tobias Frost wrote:

> IMHO the severity should be raised to critical as it breaks unrelated
> software.
> 
Reverse dependencies are anything but unrelated.

Cheers,
Julien


signature.asc
Description: Digital signature

Samsung ATIV XE700T1C-K01AU driver development

[Brendon Green]

Hello Debian developers,

I am writing this from a Samsung XE700T1C hybrid tablet, running Debian
Sid.  Debian's current support for this hardware is quite poor, and I would
like to help change that.

Currently, the device's "Elan Microelectronics Corp" "Keyboard+Smartpad"
USB keyboard dock does not work at all, requiring me to use an external
Logitech K400r keyboard.

The touchscreen works, but does not appear to respond to multitouch.  The
integrated Wacom tablet+stylus works well, including support for
translating "pen down" into a right-click when the side button is pressed.
 It would, however, be nice to be able to implement a middle-click also.

I do not yet know if the sensors (accelerometer, orientation, ambient
light) or GPS work, as I am unsure how to test them.

My ultimate goal would be to be able to install KDE Active onto the device,
and have everything work as seamlessly as it does with Windows 8.1.  To
achieve this, I am willing to work together with Debian's developers to fix
the hardware issues, possibly even hacking the kernel if required.

I have used Debian and its derivatives since Woody 3.0, and have enjoyed
watching it evolve.  I feel this could be my chance to give something back.

Kind regards,
Brendon Green

RE:how to deal with a missed so bump already uploaded ?

[PICCA Frederic-Emmanuel]

> Reverse dependencies are anything but unrelated.

Hello julien, from the point of view of the release team.
What should be do now ?

to my opinion, all we have to do is to upload
zeromq3 with this ugly but necessary +really versionnumber

4.0.3+really-3.2.4-1

then the problem should be fixed once migrated into testing.

is that all ?

thanks for your help

Fred

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1e96...@sun-dag3.synchrotron-soleil.fr

Re: arm64 update - help wanted

[Ian Campbell]

On Fri, 2014-05-16 at 20:44 -0300, Antonio Terceiro wrote:
> On Fri, May 16, 2014 at 07:43:18AM +0100, Ian Campbell wrote:
> > On Thu, 2014-05-15 at 22:49 -0300, Antonio Terceiro wrote:
> > > On Thu, May 15, 2014 at 08:20:53PM +0100, Ian Campbell wrote:
> > > > On Thu, 2014-05-15 at 02:10 +0100, Wookey wrote:
> > > > > Also if anyone has expertise in language porting we'd like to hear
> > > > > from you. Below is the list of languages we believe still need 
> > > > > porting to arm64:
> > > > 
> > > > Ruby wasn't on the list, is that under control?
> > > > 
> > > > Ruby seems to be at the bottom of the build-dep chain for the kernel
> > > > (linux->patchutils->rpm->libsemanage->ruby).
> > > 
> > > The code is ported, but starting at 1.9 Ruby needs an existing Ruby
> > > interpreter to build. Ruby 1.8 needs only gcc-4.6 ... which needs
> > > patchutils. So we got ourselves a loop there.
> > 
> > FWIW I managed to build ruby1.8 with gcc-4.9 using the patch below. I
> > don't know if it works though.
> 
> Making it build is the easy part. :)

:-D

> I had to force gcc-4.6 some time ago because building with gcc-4.7 (the
> default at the time IIRC) caused segmentation faults. Looking at newer
> comments at the corresponding bug logs (#674541) there are suggestions
> about gcc flags that fix the issue, so I tried them here and it seems to
> work, at least as far as being usable to bootstrap ruby2.1. I have
> uploaded that now, let's see what happens.

Cool, thanks!

I think it was mentioned in this thread somewhere already -- should
#742102 (removal request) be postponed until Ruby can be bootstrapped?

Ian.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1400318366.29121.31.ca...@dagon.hellion.org.uk

Re: how to deal with a missed so bump already uploaded ?

[Alessandro Ghedini]

On sab, mag 17, 2014 at 08:28:13 +, PICCA Frederic-Emmanuel wrote:
> > Reverse dependencies are anything but unrelated.
> 
> Hello julien, from the point of view of the release team.
> What should be do now ?
> 
> to my opinion, all we have to do is to upload
> zeromq3 with this ugly but necessary +really versionnumber
> 
> 4.0.3+really-3.2.4-1

1:3.2.4 is not as ugly. The 3.x series is unlikely to get any new upstream
releases anyway, so the epoch shouldn't be a problem in the future.

> then the problem should be fixed once migrated into testing.
> 
> is that all ?

Note that e.g. haskell-zeromq4-haskell already requires zeromq 4.x to build, and
others (python-zmq, hbro, ...) depend on libzmq3 >= 4.0.1, so zeromq4 should be
packaged first, those packages updated to build depend on libzmq4-dev and then
zeromq3 re-uploaded with the old version. The other reverse build-deps of
zeromq3 should probably be binNMUed as well once that's done to get the proper
build-time macros.

Cheers


signature.asc
Description: Digital signature

Re: how to deal with a missed so bump already uploaded ?

[Julien Cristau]

On Sat, May 17, 2014 at 12:42:10 +0200, Alessandro Ghedini wrote:

> Note that e.g. haskell-zeromq4-haskell already requires zeromq 4.x to build, 
> and
> others (python-zmq, hbro, ...) depend on libzmq3 >= 4.0.1, so zeromq4 should 
> be
> packaged first, those packages updated to build depend on libzmq4-dev and then
> zeromq3 re-uploaded with the old version. The other reverse build-deps of
> zeromq3 should probably be binNMUed as well once that's done to get the proper
> build-time macros.
> 
Is there any chance we can avoid shipping 3 different zeromq versions?

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#748383: ITP: bash8 -- bash script style guide checker

[Andreas Metzler]

On 2014-05-17 Thomas Goirand  wrote:
> On Sat May 17 2014 02:54:13 AM EDT, Andreas Metzler  wrote:

>> On 2014-05-16 Thomas Goirand  wrote:
>> [...]
>>> * Package name       : bash8
>> [...]
>>> Description         : bash script style guide checker
 
>>> This program attempts to be an automated style checker for bash
>>> scripts to fill the same part of code review that pep8 does in most
>>> OpenStack projects. It started from humble beginnings in the DevStack
>>> project, and will continue to evolve over time.
 
>> how about choosing a different package name? As a user I would expect
>> to find bash v8 inside a "bash8" package.

> This is a reference to "pep8" in the Python.

Yes, the long description says so. Still it is not good name, imho. Note
that pep8 is *not* named python8.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140517113143.gh1...@downhill.g.la

Re: how to deal with a missed so bump already uploaded ?

[Michael Biebl]

Am 16.05.2014 22:56, schrieb PICCA Frederic-Emmanuel:
> Hello,
> 
> the zeromq upstream forgot to do an so bump when releasing the 4.x series.
> The breakage was discovers quite late so it is now in testing.
> the package should be revert to the 3.2.4 version.
> 
> you can find all the information about this breakage in the bug #743508.
> 
> So my question is how to deal with this mess ?

What about keeping version 4.0.4 but renaming libzmq3 to libzmq3a and
then binNMU all reverse dependencies for which this is sufficient and
port the remaining ones.

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: arm64 update - help wanted

[Antonio Terceiro]

On Sat, May 17, 2014 at 10:19:26AM +0100, Ian Campbell wrote:
> On Fri, 2014-05-16 at 20:44 -0300, Antonio Terceiro wrote:
> > On Fri, May 16, 2014 at 07:43:18AM +0100, Ian Campbell wrote:
> > > On Thu, 2014-05-15 at 22:49 -0300, Antonio Terceiro wrote:
> > > > On Thu, May 15, 2014 at 08:20:53PM +0100, Ian Campbell wrote:
> > > > > On Thu, 2014-05-15 at 02:10 +0100, Wookey wrote:
> > > > > > Also if anyone has expertise in language porting we'd like to hear
> > > > > > from you. Below is the list of languages we believe still need 
> > > > > > porting to arm64:
> > > > > 
> > > > > Ruby wasn't on the list, is that under control?
> > > > > 
> > > > > Ruby seems to be at the bottom of the build-dep chain for the kernel
> > > > > (linux->patchutils->rpm->libsemanage->ruby).
> > > > 
> > > > The code is ported, but starting at 1.9 Ruby needs an existing Ruby
> > > > interpreter to build. Ruby 1.8 needs only gcc-4.6 ... which needs
> > > > patchutils. So we got ourselves a loop there.
> > > 
> > > FWIW I managed to build ruby1.8 with gcc-4.9 using the patch below. I
> > > don't know if it works though.
> > 
> > Making it build is the easy part. :)
> 
> :-D
> 
> > I had to force gcc-4.6 some time ago because building with gcc-4.7 (the
> > default at the time IIRC) caused segmentation faults. Looking at newer
> > comments at the corresponding bug logs (#674541) there are suggestions
> > about gcc flags that fix the issue, so I tried them here and it seems to
> > work, at least as far as being usable to bootstrap ruby2.1. I have
> > uploaded that now, let's see what happens.
> 
> Cool, thanks!
> 
> I think it was mentioned in this thread somewhere already -- should
> #742102 (removal request) be postponed until Ruby can be bootstrapped?

The upstream source tree is, at least in theory since I never tried it,
cross-buildable, so that would be my preferable long-term solution.

Besides I'm not sure for how long we will be able to use this ruby1.8
trick ...  and if that is the case one can always grab a copy of the
ruby1.8 source from archive.d.o for bootstrapping.

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Bug#748471: ITP: erlang-lhttpc -- lightweight HTTP/1.1 client implemented in Erlang

[Philipp Huebner]

Package: wnpp
Severity: wishlist
Owner: Philipp Huebner 

* Package name: erlang-lhttpc
  Version : 1.3.0
  Upstream Author : Erlang Training and Consulting Ltd.
* URL : https://github.com/esl/lhttpc/
* License : BSD 3-Clause
  Programming Lang: Erlang
  Description : lightweight HTTP/1.1 client implemented in Erlang

 lhttpc is a lightweight HTTP/1.1 client implemented in Erlang,
 developed at Erlang Training and Consulting Ltd.
 .
 Features:
  * Persistent connections (configurable timeout)
  * HTTP / HTTPS (ssl) support
  * HTTP versions < 1.1 should be supported
 .
 Pipelining will probably never be supported...
 .
 Limitations
  * No support for "streaming" the response body
  * No support for SSL options, such as client certificates
  * The client can't follow redirects
  * It's not possible to limit the number of outgoing connections
  * No proper support for Except: 100-continue behaviour


This is another one of of the optionl (build-)dependencies for current
ejabberd releases. It is the last one, after this the set is complete.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140517135910.8223.44545.report...@emmagan.debalance.de

Redefining critical bug severity (was: how to deal with a missed so bump already uploaded ?)

[Russ Allbery]

Julien Cristau  writes:
> On Sat, May 17, 2014 at 07:33:04 +0200, Tobias Frost wrote:

>> IMHO the severity should be raised to critical as it breaks unrelated
>> software.

> Reverse dependencies are anything but unrelated.

Over the years, I've seen endless confusion about the current definition
of a critical bug severity:

makes unrelated software on the system (or the whole system) break, or
causes serious data loss, or introduces a security hole on systems
where you install the package.

The confusion seems to always be around the "unrelated software" part of
that definition.  The intended meaning is completely unrelated software on
the system, indicating a package that's mangling the system in some
fundamental way, but I've frequently seen people believe, sincerely, that
reverse dependencies, Perl programs that use a buggy module, or X programs
on a system with a buggy video driver qualify as unrelated software.

This makes me think that part of the bug definition is adding more
confusion than clarity.  Should we just drop it?

I think defining critical as:

makes the entire system unusable, or causes serious data loss, or
introduces a security hole on systems where you install the package

is closer to how we actually use the severity, and would avoid some of
these bug severity arguments.

-- 
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: https://lists.debian.org/87sio84ddf.fsf...@windlord.stanford.edu

Re: arm64 update - help wanted

[Luke Kenneth Casson Leighton]

>  suggestion, wookey: i'd love to help... but obviously with no
> hardware that's kinda hard: is there a clear set of instructions
> somewhere - a wiki page for example - on how to debootstrap an arm64
> qemu so that even if it's dead slow it's still possible to help out?

https://wiki.debian.org/Arm64Qemu

wookey i found this - it's not entirely clear (lots of options, not
step-by-step): what is relevant to getting up and running, is the page
still relevant, has aarm64 made it into the latest debian qemu package
yet.

tia,

l.


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

Re: arm64 update - help wanted

[Luke Kenneth Casson Leighton]

On Thu, May 15, 2014 at 2:10 AM, Wookey  wrote:
> The debian-port arm64 rebootstrap is progressing nicely, and we just
> passed 4200 source packages built, with another few hundred
> pending. There are now 2 buildds running.

 awesome

> Thus I'd love it if anyone else could help go through the failures
> pile and file bugs, or upload old existing ones, or classify them on
> the wiki. Or if they happen to be your packages then just fix them :-)
>
> I've put some links on the wiki page
> https://wiki.debian.org/Arm64Port#Bug_tracking

 suggestion, wookey: i'd love to help... but obviously with no
hardware that's kinda hard: is there a clear set of instructions
somewhere - a wiki page for example - on how to debootstrap an arm64
qemu so that even if it's dead slow it's still possible to help out?

 l.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAPweEDyrR8woYLt3i=DLkyf3e-K=c=8ddhcjcwe2liwqxgh...@mail.gmail.com

Re: arm64 update - help wanted

[Adam Borowski]

On Sat, May 17, 2014 at 05:24:38PM +0100, Luke Kenneth Casson Leighton wrote:
> > is there a clear set of instructions
> > somewhere - a wiki page for example - on how to debootstrap an arm64
> > qemu so that even if it's dead slow it's still possible to help out?
> 
> https://wiki.debian.org/Arm64Qemu
> 
> wookey i found this - it's not entirely clear (lots of options, not
> step-by-step): what is relevant to getting up and running, is the page
> still relevant, has aarm64 made it into the latest debian qemu package
> yet.

The page is obsolete, since a month ago that code is already in unstable.
It's qemu-user only, though, so you can use it to build and run stuff but
not to debug bootloaders, the kernel or such.

-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140517164856.ga1...@angband.pl

Bug#748484: ITP: libmarpa-r2-perl -- BNF grammar parser

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libmarpa-r2-perl
  Version : 2.084000
  Upstream Author : Jeffrey Kegler
* URL : https://metacpan.org/release/Marpa-R2
* License : LGPL-3
  Programming Lang: Perl + C
  Description : BNF grammar parser

 Marpa::R2 parses any language whose grammar can be written in BNF.
 That includes recursive grammars, ambiguous grammars, infinitely
 ambiguous grammars and grammars with useless or empty productions.
 Marpa does both left- and right-recursion in linear time -- in fact if
 a grammar is in any class currently in practical use, Marpa will parse
 it in linear time.

This package is required by libcatmandu-perl.

It will be maintained inside the pkg-perl team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQF8BAEBCgBmBQJTd6VKXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0
RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWZ7kIAMSctTpMrMhFJ/XLKmKKxVBU
i3eywBFAqZs8RJFKnXawDyCV48ZI8fmNsCzojKGYe5DsrLGSdR2mRCOJ9d32sHsb
gS/iNrZI1hCX9dzYDhPLNGw0kGNObN02HpWu5K+rrQHsHrctLKL9k0jhwcbrO3fF
P5TBPo3rQHgPWq0hm5QnW1UESvyOj1TqDDZJnIszgoZ6Cl3ZQsNHUZ3dC9A+nXny
TbQORsTBnDP9lhE/dFFn8O4bPWDIxzvh+v30G7eJ/VDsdxrar5JRdjPGJ2kRGKi/
fPStVNiWLQl6HWfC+6yCVIqwfXwOuVuxe70EkDbqBexv9ZQ5V4W52jrDEfIZpcE=
=J6MI
-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: 
https://lists.debian.org/20140517180710.4042.79408.report...@bastian.jones.dk

Re: Redefining critical bug severity (was: how to deal with a missed so bump already uploaded ?)

[Josh Triplett]

Russ Allbery wrote:
> Over the years, I've seen endless confusion about the current definition
> of a critical bug severity:
> 
> makes unrelated software on the system (or the whole system) break, or
> causes serious data loss, or introduces a security hole on systems
> where you install the package.
> 
> The confusion seems to always be around the "unrelated software" part of
> that definition.  The intended meaning is completely unrelated software on
> the system, indicating a package that's mangling the system in some
> fundamental way, but I've frequently seen people believe, sincerely, that
> reverse dependencies, Perl programs that use a buggy module, or X programs
> on a system with a buggy video driver qualify as unrelated software.
> 
> This makes me think that part of the bug definition is adding more
> confusion than clarity.  Should we just drop it?
> 
> I think defining critical as:
> 
> makes the entire system unusable, or causes serious data loss, or
> introduces a security hole on systems where you install the package
> 
> is closer to how we actually use the severity, and would avoid some of
> these bug severity arguments.

I agree, but I'd add an additional clause to cover another part of how
the severity is interpreted in practice: "or cannot be recovered from
via the normal use of the packaging system".

In other words, any package that requires magic fiddling with dpkg or
the dpkg database to recover from, even to upgrade to a fixed version of
that package, has a critical bug.

In practice, though, I don't think the distinction between critical,
grave, and serious matters much in practice; packages should have few
enough RC bugs that any such bug will show up on the top of the
package's bug list, so it doesn't really matter how much more than
serious it is.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140517194328.GA11576@thin

Bug#748500: ITP: libconfig-onion-perl -- layered configuration

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libconfig-onion-perl
  Version : 1.004
  Upstream Author : Dave Sherohman 
* URL : https://metacpan.org/release/Config-Onion
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : layered configuration

 Config::Onion stores all configuration settings in four layers:
 Defaults, Main, Local, and Override. Each layer can be added to as many
 times as you like. Within each layer, settings which are given multiple
 times will take the last specified value, while those which are not
 repeated will remain untouched.

This package is required by libcatmandu-perl.

It will be maintained inside the pkg-perl team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQF8BAEBCgBmBQJTd7+RXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0
RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vW0wEH/jOmB0SqE7vztvzu4WYmI1fC
CRZ7tYaK5aJJ5LAPSPSsUQ3KUVxt+CXLDnfw3M8dvfyb9YnZXf3k1ZY3uF8MGqYD
WlO5dG5dvDX07SzNgf1OvDiaN5FqQf5Ci/NTDW6NQDG+CKUlyyAlO15WOeLWGjQH
M0/3Z6dbd73b9ppXFM+8nzPAB9fwGqrCNoTNzOMpga3NQZkMi5R6oersEP1FMMZX
BEPDMW58AZTiI0qMGSvbw3c0wfynoj2YD6+jIyGQyT4YjUewk5MXi+lJcm+s3sHm
G46xyd0aGfPAn6TsgQ4m+30Lq2cLHTeYgF06wkvn3HA+JCfxV4HEr/oMqTBbKhs=
=oCBZ
-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: 
https://lists.debian.org/20140517195918.12591.74554.report...@bastian.jones.dk

Re: Redefining critical bug severity

[Manoj Srivastava]

On Sat, May 17 2014, Russ Allbery wrote:

> Over the years, I've seen endless confusion about the current definition
> of a critical bug severity:

> makes unrelated software on the system (or the whole system) break, or
> causes serious data loss, or introduces a security hole on systems
> where you install the package.

> The confusion seems to always be around the "unrelated software" part of
> that definition.  The intended meaning is completely unrelated software on
> the system, indicating a package that's mangling the system in some
> fundamental way, but I've frequently seen people believe, sincerely, that
> reverse dependencies, Perl programs that use a buggy module, or X programs
> on a system with a buggy video driver qualify as unrelated software.

> This makes me think that part of the bug definition is adding more
> confusion than clarity.  Should we just drop it?

Could this explanation instead be added as an informative
 footnote? Packages that declrare a direct or indirect dependency are
 not unrelated?

>makes the entire system unusable, or causes serious data loss, or
>introduces a security hole on systems where you install the package

There is a gap, I think, between the previous meaning and this
 statement.  If you upload a change to a java-xsml-parser library, and
 it breaks make, that does not cause the whole system to be unusable, or
 data loss, or a security hole.

Under the old reading, this is a critical bug, but not under the
 new reading. In my opinion, it remains a critical bug, to berak totally
 unrelated software.


manoj

-- 
"Rembrandt's first name was Beauregard, which is why he never used it."
Dave Barry
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


signature.asc
Description: PGP signature

Bug#748522: ITP: librdf-aref-perl -- another RDF Encoding Form

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: librdf-aref-perl
  Version : 0.11
  Upstream Author : Jakob Voß
* URL : https://github.com/nichtich/RDF-aREF
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : another RDF Encoding Form

 aREF (another RDF Encoding Form) is an encoding of RDF graphs in form
 of arrays, hashes, and Unicode strings.
 .
 RDF::aREF implements decoding from aREF data to RDF triples.

This package is required by libcatmandu-rdf-perl.

It will be maintained inside the pkg-perl team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQF8BAEBCgBmBQJTd/ISXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0
RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWWe0IAKZn3+HNpSDGTsWJIMULZfBT
cKorO5TDdJGDtVA/hfJ7LyAoye1hvfQnJtKL9dxiauDQF6zwDNik/merqr4GxYo9
Fx83krvNy7b7W2Jw6ZMfT90mW+zpMuUjfs7rWafqeFXWmeLmN/74GE57TrzCH7+v
7Nk8a2cToLGVm76wJNmD2ROO2jgytN/qlXRQVxapbIgjYjxalsmtRgUhhnH0LZrP
ZxD/RdJXE+NGkk6VAp6h4NTtJDPuCRWlonpmVhRkS8HjRVT/JD9vs96oE3gb7OBx
f/9GLCIsSOLp97NJWDbxEWPo9yKOdV6N3iYoYm29ofgqvNSLHvUcOa4eTeGwadw=
=hzBo
-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: 
https://lists.debian.org/20140517233447.3569.85160.report...@bastian.jones.dk

Re: arm64 update - help wanted

[Paul Wise]

On Sun, May 18, 2014 at 12:48 AM, Adam Borowski wrote:

> The page is obsolete, since a month ago that code is already in unstable.
> It's qemu-user only, though, so you can use it to build and run stuff but
> not to debug bootloaders, the kernel or such.

Full aarch64 system emulation is in qemu upstream now so those can be
tested with a small amount of work:

http://translatedcode.wordpress.com/2014/05/13/aarch64-system-emulation-has-landed-in-qemu-upstream/

-- 
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: 
https://lists.debian.org/caktje6ek00upc9l8om0ku668c-xifrzfrp+3ycux+l_p1k7...@mail.gmail.com