E-Learning Management Solutions & Development Packages !!

[Anu]

Hello,

I am Anupreet (*Senior Moodle consultant*)

We are an expert team of more than 16 developers with a combined experience
of more than 82 years. We are completely focused on following the best
practices of Moodle and always giving best learning management system
experience to all our clients. We had already delivered more than 232
Moodle projects.

Our primary aim is to have a long term relationship with all our clients by
providing excellent output always.

*Some of our services are: -*

1.   Moodle installation

2.   Moodle Custom theme development

3.   Moodle plugin development

4.   Moodle plugin customization

5.   Moodle upgrade

6.   API integration

7.   Moodle custom reports development

8.   Custom payment gateway integration

9.   Moodle multi-tenant system development

10.   Moodle consulting

If needed, we can provide reference of our clients as well.

Why Moodle :- Moodle is the best learning management system available. It
is highly flexible and can get customized as per our needs. It has a strong
Moodle community which are always delivering best. We are an active member
of Moodle community and already delivered many complex plugins to our
clients.


*Our focus is on highest level of quality possible.*

Please let me know your opinion or interest with further communication mode
(Email / Phone call / Skype / Google hangout), then we can send you more
details about package/action with special Offers.

Looking for your reply and interest..



Thanks & Regards,
Anupreet
Senior Moodle Consultant





*(Note:* We are not spammers and are against spamming of any kind. If you
are not interested then you can reply with a simple \"NO\",We will never
contact you again.)

Re: Mass Bug Filing: Missing Build-Depends: graphviz

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Mar 20, 2016 at 08:07:55PM +0100, Adam Borowski wrote:
> On Sun, Mar 20, 2016 at 06:51:23PM +, Bas Wijnen wrote:
> > That also means that programs calling dot will need graphviz in their
> > Build-Depends, no matter what the default is.
> 
> As is, a number of them do call dot without the build-dependency.

Yes, so that's a bug in those programs, not in doxygen.  It would be "fixed" by
adding graphviz as a Depends to doxygen, but that would be incorrect.

> > > The disappoining moral for this is that nobody looks at their build 
> > > logs...
> > 
> > I don't think that's disappointing at all!  It means we have built a system
> > that will let us know when something is wrong.
> 
> That would be the case if doxygen propagated the error, which it does not.

And that _is_ a bug in doxygen, IMO.  If it cannot produce the requested
output, it should abort with an error.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW74DXAAoJEJzRfVgHwHE6jBIP/RbYo/q85gRUI5YIyEwAETF0
RLpIWDvWFvJRhg9TGfVA3VfeAmLrsOG59V6cwuszObY1I1VX1NVpJi1RoUTiZ9O2
d7l3boQ8YRb8ll3e49LLsfHoIWw6Tp30KjbrrvsOWjH/18NDZkEK89uXFzK+/U8/
kDMADNsFvpo6/5MzSp59LSn7+YvKKuOOSypkPR2K1DzYhCL8lPno3lq8lCX6uAz/
oXjwIuFMR1KNJx/pxL9DeM+bP+9qwe0xQlL48C7kuGzvyT0ZF2gofETtlHvAbrQe
Mg3y7EbBKU6hNLi7hs9KqI8G9h+9FuyI5jeyNv0ixQQrtbDWlY8j2LBOQbwBGnNO
PeSQ0e+HmcRQgPCqBcysGxmCfTpJmfS+lAC5Q3ip62sVHIQzot/GnQBUBVZLUi2W
JGBF+JJirQ33cIw8v67Uguy4GO3/ba/I+NZFKug4poPvskmuVhMJHB0gU5Nr3mL0
Sn3dC54mzPtQk6Eq8oace9hZl39v3dHhWG/Oce/dL8sKhwkIUhc19LGk/mc0aHCQ
FC2bTVLMeCM3ZjCso1piXA10WeD5JFK2hg4B4sQCtbePQLfWXTsLsKSkNdEWqpU3
NeEeMtVaQwyMV0WRQD5JKSoClpTSsQf7cF+c+U3IKVOhkZJpwh8TKUQASo9f6Ywe
Rj66EyyM2s72+7qVxS9Z
=fTpp
-END PGP SIGNATURE-

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Paul Wise]

On Mon, Mar 21, 2016 at 8:38 AM, Josh Triplett wrote:

> Ah.  So I assume that packages using versioned Provides probably
> shouldn't get uploaded to the archive until that happens?

There are already packages in the archive using versioned Provides:
libjpeg62, python cffi packages, several php packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Build failures with libc6 2.23 from experimental

[Martin Michlmayr]

I compiled unstable with libc6 2.23 (2.23-0experimental0) from
experimental.

I filed the following build failures:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=2.23;users=debian-gl...@lists.debian.org

-- 
Martin Michlmayr
http://www.cyrius.com/

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Josh Triplett]

James McCoy wrote:
> On Mar 20, 2016 4:31 PM, "Ben Hutchings"  wrote:
> > On Sun, 2016-03-20 at 12:39 -0700, Josh Triplett wrote:
> > > Ian Jackson wrote:
> > > > The Wanderer writes ("Re: Possible MBF: Packages depending on iceweasel 
> > > > but not firefox/firefox-esr"):
> > > > > Now, one thing which seems like it _could_ fix this without requiring 
> > > > > a
> > > > > MBF would be for firefox and firefox-esr to acquire 'Provides:
> > > > > iceweasel'. That seems like a misuse of the system to me, however, 
> > > > > and a
> > > > > suboptimal solution at best.
> > > > I don't understand what is wrong with this approach.  It seems
> > > > perfectly sensible to me.
> > > Leaving aside any other reasons: many packages have a versioned
> > > dependency on iceweasel, and we don't have versioned provides.
> > [...]
> >
> > Yes we do, since dpkg 1.18.

Interesting!  I didn't realize that.

> Yet others parts of our infrastructure still need updates to handle then 
> (e.g., britney).

Ah.  So I assume that packages using versioned Provides probably
shouldn't get uploaded to the archive until that happens?

- Josh Triplett

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[James McCoy]

On Mar 20, 2016 4:31 PM, "Ben Hutchings"  wrote:
>
> On Sun, 2016-03-20 at 12:39 -0700, Josh Triplett wrote:
> > Ian Jackson wrote:
> > >
> > > The Wanderer writes ("Re: Possible MBF: Packages depending on
iceweasel but not firefox/firefox-esr"):
> > > >
> > > > Now, one thing which seems like it _could_ fix this without
requiring a
> > > > MBF would be for firefox and firefox-esr to acquire 'Provides:
> > > > iceweasel'. That seems like a misuse of the system to me, however,
and a
> > > > suboptimal solution at best.
> > > I don't understand what is wrong with this approach.  It seems
> > > perfectly sensible to me.
> > Leaving aside any other reasons: many packages have a versioned
> > dependency on iceweasel, and we don't have versioned provides.
> [...]
>
> Yes we do, since dpkg 1.18.

Yet others parts of our infrastructure still need updates to handle then
(e.g., britney).

Cheers,
James

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Ben Hutchings]

On Sun, 2016-03-20 at 12:39 -0700, Josh Triplett wrote:
> Ian Jackson wrote:
> > 
> > The Wanderer writes ("Re: Possible MBF: Packages depending on iceweasel but 
> > not firefox/firefox-esr"):
> > > 
> > > Now, one thing which seems like it _could_ fix this without requiring a
> > > MBF would be for firefox and firefox-esr to acquire 'Provides:
> > > iceweasel'. That seems like a misuse of the system to me, however, and a
> > > suboptimal solution at best.
> > I don't understand what is wrong with this approach.  It seems
> > perfectly sensible to me.
> Leaving aside any other reasons: many packages have a versioned
> dependency on iceweasel, and we don't have versioned provides.
[...]

Yes we do, since dpkg 1.18.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

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

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Josh Triplett]

Ian Jackson wrote:
> The Wanderer writes ("Re: Possible MBF: Packages depending on iceweasel but 
> not firefox/firefox-esr"):
> > Now, one thing which seems like it _could_ fix this without requiring a
> > MBF would be for firefox and firefox-esr to acquire 'Provides:
> > iceweasel'. That seems like a misuse of the system to me, however, and a
> > suboptimal solution at best.
> 
> I don't understand what is wrong with this approach.  It seems
> perfectly sensible to me.

Leaving aside any other reasons: many packages have a versioned
dependency on iceweasel, and we don't have versioned provides.

(Though *if* apt, dpkg, and all associated tools have the behavior of
satisfying a versioned dependency on a virtual package if the providing
package has the right version, that would potentially work since
iceweasel and firefox/firefox-esr share the right versioning scheme.)

- Josh Triplett

Re: Mass Bug Filing: Missing Build-Depends: graphviz

[Adam Borowski]

On Sun, Mar 20, 2016 at 06:51:23PM +, Bas Wijnen wrote:
> That also means that programs calling dot will need graphviz in their
> Build-Depends, no matter what the default is.

As is, a number of them do call dot without the build-dependency.

> > But this is inconsistent with having graphviz in the Suggests line for
> > doxygen.
> 
> I agree that if it is the default, it should be Recommends, not Suggests.  
> This
> doesn't change anything for the problem you're describing, however.
> 
> > The disappoining moral for this is that nobody looks at their build logs...
> 
> I don't think that's disappointing at all!  It means we have built a system
> that will let us know when something is wrong.

That would be the case if doxygen propagated the error, which it does not.

> That means we don't need to poll for errors, because they will be pushed
> to us.  (I think porters are still doing this manually at least some of
> the time; I think FTBFS bugs should be reported automatically.)
> 
> In other words, my solution to this bug would be to make doxygen exit with an
> error code when calling dot fails.  Then make will fail, it's an FTBFS, it 
> gets
> fixed, and everyone is happy.

I've started a rebuild of all 552 packages in unstable that build-depend on
doxygen or anything that recursively pulls doxygen (eclipse-eclox doxyqml
doxygen-latex doxygen-gui doxygen-dbg python3-breathe python-breathe).
My build environment has a /usr/bin/dot that aborts the build when called,
which should detect this error even if doxygen output is redirected or
mangled.  I'll let you know how widespread the FTBFS are when finished.

On a slow-ass machine, 57 builds done in 2.5 hours so far, so it'll take a
while.

-- 
A tit a day keeps the vet away.

Re: Mass Bug Filing: Missing Build-Depends: graphviz

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I think you are mistaken about a few things.

On Sun, Mar 20, 2016 at 06:04:55PM +0100, Santiago Vila wrote:
> The maintainer points out that the default value for HAVE_DOT is NO,
> so he's reluctant to add the build-dependency.

If the program can be used without it, it should not be a Depends.  That's what
Recommends are for.  Default values have nothing to do with it; Depends are for
things that will make the program unusable if they aren't present, Recommends
are for things that should almost always be installed with the program.

That also means that programs calling dot will need graphviz in their
Build-Depends, no matter what the default is.

> But this is inconsistent with having graphviz in the Suggests line for
> doxygen.

I agree that if it is the default, it should be Recommends, not Suggests.  This
doesn't change anything for the problem you're describing, however.

> The disappoining moral for this is that nobody looks at their build logs...

I don't think that's disappointing at all!  It means we have built a system
that will let us know when something is wrong.  That means we don't need to
poll for errors, because they will be pushed to us.  (I think porters are still
doing this manually at least some of the time; I think FTBFS bugs should be
reported automatically.)

In other words, my solution to this bug would be to make doxygen exit with an
error code when calling dot fails.  Then make will fail, it's an FTBFS, it gets
fixed, and everyone is happy.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW7vEqAAoJEJzRfVgHwHE6Gm4QAKAhBvdYk+2kTZ6SKTjgH/B0
4OIBO8nSOJe+O5yTB3AordZq2zZS1afM0oWB3JiVfa6l6Ka9dfC8f9TOlvW5xGnm
pj0OO7b7jrH5oK5XToqj3DvDphNKpNwWnHKbeBWlJY779SVBa50kdwnbtg77wa5k
ZBl1NWLFlFeRgjbG6BQpn1l50NyRLMzTumLFtF+rpZACAwoiH+bkJVDlu83lfM72
/B4WLl9G7wxnhwhtfs2PcvRaYF8EzGuNDizu2PbwCp31CKUszF4+0q9JiqHtTwmV
VIFxB31fSU/RpmEIxI086wStd/Rax+Cn8HfAyTY6/tIOVBCeHYnNajWZkVEcNsoj
srsaGpPEGJouGr/MLqQIk5n6LLsiERq4aha5WpmccmgkNCxTIUXZlU62J6y5DzlT
lDkG5NXkEuf1qsk9bUJQEAbvdCKfbX6mtlbibxtGlSpeZ6LwfsQ+M9MoX300kH84
UYHMovo6M9CHXLdxt9AJOVBJTbERXbKVysnrov2pVlZSZiPFu7M/haz6Um13Vsku
AlIpYRYpfTRiNZ/dg1Tf0AtnMkSIqhy1441Jj+Egpe9EXAs9GfWaYNOa1yZYm1d8
1Wcbh0NdzakVDNmTWuPg47bGt7IOGUcgM74DQuRLCWxcaOOnErs0nI7+3x3kZ+5/
77few9WmaB+ZHhDWb+Vv
=AU0O
-END PGP SIGNATURE-

Re: Mass Bug Filing: Missing Build-Depends: graphviz

[Santiago Vila]

Ok, this is postponed for now.

One of the bugs I was going to report was already reported:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778478

The maintainer points out that the default value for HAVE_DOT is NO,
so he's reluctant to add the build-dependency.

But this is only true in doxygen upstream.

The problem is that Debian doxygen changes the default for HAVE_DOT to
YES (in debian/patches/dot-config.diff), telling doxygen that it may
assume that the "dot" command is installed.

But this is inconsistent with having graphviz in the Suggests line for
doxygen.

So either doxygen does not change the default value for HAVE_DOT, or,
if it does, it should have graphviz in the Depends line.

I've reported this as Bug#818787. The maintainer (Matthias) will have to decide.

The disappoining moral for this is that nobody looks at their build logs...

Thanks.

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Ian Jackson]

The Wanderer writes ("Re: Possible MBF: Packages depending on iceweasel but not 
firefox/firefox-esr"):
> Now, one thing which seems like it _could_ fix this without requiring a
> MBF would be for firefox and firefox-esr to acquire 'Provides:
> iceweasel'. That seems like a misuse of the system to me, however, and a
> suboptimal solution at best.

I don't understand what is wrong with this approach.  It seems
perfectly sensible to me.

It has the advantage that if we think that Mozilla might change their
minds again, we could avoid changing all the rdeps, and retain
the flexibility to rename back, later.

Ian.

Bug#818786: ITP: node-get-stdin -- Get stdin as a string or buffer

[Jonathan Ulrich Horn]

Package: wnpp
Serverity: wishlist
Owner: Jonathan Ulrich Horn 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-get-stdin
  Version : 5.0.1
  Upstream Author : Sindre Sorhus 
* URL : https://github.com/sindresorhus/get-stdin
* License : Expat
  Description : Get stdin as a string or buffer

 Node-get-stdin is a Node.js module to get input from STDIN with
Javascript Promises.
 .
 Node.js is an event-based server-side JavaScript engine.



signature.asc
Description: OpenPGP digital signature

Re: Mass Bug Filing: Missing Build-Depends: graphviz

[Santiago Vila]

On Sun, Mar 20, 2016 at 02:31:23PM +0100, Christian Seiler wrote:
> There are 358 packages in unstable that currently have B-D/B-D-I: doxygen
> but no B-D/B-D-I: graphviz. But my guess is that not all of them (probably
> not even most of them) actually run dot during Doxygen build.
> 
> Of those, 276 source packages have doxygen in B-D but not graphviz in
> either B-D. (And there is one package, gdcm, which has doxygen in B-D but
> graphviz in B-D-I.)
> 
> Are you going to rebuild all 358 of these packages to test this? (If so,
> do you need help splitting this up?) Or do you have a better method in
> mind to figure this out?

Good question. I routinely check fot "dpkg-buildpackage -A" in
stretch, so I already have a bunch of build logs to start.

I'll consider checking all affected packages afterwards.

Thanks.

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[The Wanderer]

On 2016-03-20 at 06:43, Jakub Wilk wrote:

> * Josh Triplett , 2016-03-18, 15:06:

>> Firefox addon packages (xul-ext-*) typically have a Depends on
>> iceweasel, sometimes with alternatives for icedove or other
>> supported packages that can use the addon.  With the switch to
>> firefox and firefox-esr, iceweasel has become a transitional
>> package depending on firefox-esr.  The dependencies of these addon
>> packages prevent installing only the firefox package and removing
>> firefox-esr and the transitional iceweasel package.
> 
> So let's fix Depends of the transitional package. No MBF is needed.

I don't understand how that would help. It would let you install
'firefox-esr | firefox' to satisfy the dependency of xul-ext-foo, but it
would not let you remove iceweasel without also removing xul-ext-foo.


Now, one thing which seems like it _could_ fix this without requiring a
MBF would be for firefox and firefox-esr to acquire 'Provides:
iceweasel'. That seems like a misuse of the system to me, however, and a
suboptimal solution at best.

There is an argument to be made that firefox-esr should Provides:
firefox (or that both should Provides: a single virtual package), or
something along those lines, to avoid requiring packages to list both
alternatives explicitly. I'm not sure that wouldn't have too many
downsides to be a good approach, however.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Archive changes

[Joerg Jaspert]

On 14247 March 1977, Joerg Jaspert wrote:

> I've just activated a few changes to the archive we talk(ed) about for a
> long time. And while it is not exactly the start of this release cycle,
> it should still work out nicely (so one hopes).

Tuesday to now - i think the majority of what breaks with this change
should be found by now.

> As of now, InRelease/Release files, Packages and Sources no longer
> provide MD5Sum and SHA1sums, only SHA256.

>From the breakage people mentioned, I think this will change, and the
following seems (to me) to be the best way now: SHA1 stay off. But MD5
will come back, until the day we release stretch. Anything later than
stretch (and its support suites) will NOT carry MD5sums.

That hopefully gives enough time for those places where it's a larger
change to get rid of MD5.

> Additionally I turned off generating gzip compressed versions of those
> files, xz is there.

I would have imagined changing a (de)compressor being simpler than
possibly adjusting checksums that one may use as a key into a data
struct or so.

Turns out it does breaks more than I thought. Yet it sounds less serious
than the checksums, so - opinions? Keep it xz only? Bring back gz? For
how long, til stretch too, or shorter?

> To test it, this is limited to experimental. We hope nothing breaks on it,
> but lets try for a few days. If that works out, we should adjust
> unstable, and another short time later coordinate with the release team
> to adjust testing, so it ends up in the next release.

Adjusting unstable:

I've just turned off SHA1 sums there (next dinstall delivers),
compression waits for replies to the above, MD5 for release time.

-- 
bye, Joerg
Naturally; worms that don't know what they are doing end up as
fish bait, instead of getting invited into weird math experiments.
-- Lars Wirzenius

Re: Mass Bug Filing: Missing Build-Depends: graphviz

[Christian Seiler]

On 03/20/2016 01:52 PM, Santiago Vila wrote:
> There seems to be more than ten packages which:
> 
> * Have doxygen in Build-Depends.
> * Do not have graphviz in Build-Depends.
> * Try to run "dot" during the build.
> * The build does not fail because doxygen keeps working as if
>   nothing bad happened, violating Policy 4.6.
>   (This is already reported as Bug #818379).
> 
> I intend to report every such package that I find as having a missing
> "Build-Depends: graphviz".

There are 358 packages in unstable that currently have B-D/B-D-I: doxygen
but no B-D/B-D-I: graphviz. But my guess is that not all of them (probably
not even most of them) actually run dot during Doxygen build.

Of those, 276 source packages have doxygen in B-D but not graphviz in
either B-D. (And there is one package, gdcm, which has doxygen in B-D but
graphviz in B-D-I.)

Are you going to rebuild all 358 of these packages to test this? (If so,
do you need help splitting this up?) Or do you have a better method in
mind to figure this out?

> I'm still in doubt about severity of #818379. It makes a lot of
> packages to violate Policy 4.6. Is this enough to be RC?

At the very least it should be "important" and not "normal".

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Mass Bug Filing: Missing Build-Depends: graphviz

[Santiago Vila]

Greetings.

There seems to be more than ten packages which:

* Have doxygen in Build-Depends.
* Do not have graphviz in Build-Depends.
* Try to run "dot" during the build.
* The build does not fail because doxygen keeps working as if
  nothing bad happened, violating Policy 4.6.
  (This is already reported as Bug #818379).

I intend to report every such package that I find as having a missing
"Build-Depends: graphviz".

As soon as Bug #818379 is fixed, those bugs would be FTBFS,
so I'm going to report this as "severity: important", i.e. just
a step below "serious".

I'm still in doubt about severity of #818379. It makes a lot of
packages to violate Policy 4.6. Is this enough to be RC?

Thanks.

Re: a poll for Dgit workflows

[Ian Jackson]

Daniel Stender writes ("a poll for Dgit workflows"):
> I've experimented with applying `gbp import-orig` on an extra
> upstream branch and merging into e.g. dgit/sid, but this seems to be
> substandard because `dgit quilt-fixup` wants to quiltify all the
> changes in the working tree, which isn't wanted.

FYI I am (still) working on support in dgit for pushing from a
patches-unapplied git branch, which might be helpful.

Another easy approach is to switch to a non-quilt source format.  This
will work if you don't need the other things that `3.0 (quilt)' does.

> The next thing which would be interesting is how to rework patches
> e.g. unfuzzing them (for rebase isn't possible on freshly cloned
> repos with no previous Git history?).

It's quite easy with git to rebase a series of commits onto another
branch with disjoint hitory.  (And if the other history has the right
files in it, it will actually work.)  See git-rebase(1), specifically
--onto.

Ian.

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Simon McVittie]

On Sun, 20 Mar 2016 at 11:43:54 +0100, Jakub Wilk wrote:
> Also, why there are two firefox* packages, and what's the difference between
> them? (They have identical descriptions...)

As far as I understand it (not a Mozilla maintainer):

firefox-esr is the Extended Support Release version
,
which works like Ubuntu LTS: a subset of releases are designated as
long-term-supported, and the rest have a shorter support lifetime.

firefox-esr will only receive major-version updates when the supported ESR
version changes, like the iceweasel packages in current stable. firefox
will track all releases, including the short-term-supported ones like 46;
it has an artificial RC bug to stop it from entering testing, because
the non-ESR releases aren't supportable in stable.

The first version of Firefox that returned to Debian, 45, is an ESR
version. Whenever the latest release happens to be ESR, the firefox and
firefox-esr packages will coincide.

S

Bug#818396: ITP: fuel-ui -- OpenStack Fuel deployment server - Web GUI

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: fuel-ui
  Version : 9.0~0+2016.03.15.git.74d6c7a29b
  Upstream Author : OpenStack Foundation 
* URL : https://github.com/openstack/fuel-ui
* License : Apache-2.0
  Programming Lang: JavaScript, HTML
  Description : OpenStack Fuel deployment server - Web GUI

 Fuel is an open source deployment and management tool for OpenStack. Developed
 as an OpenStack community effort, it provides an intuitive, GUI-driven
 experience for deployment and management of OpenStack, related community
 projects and plug-ins.
 .
 Fuel brings consumer-grade simplicity to streamline and accelerate the
 otherwise time-consuming, often complex, and error-prone process of deploying,
 testing and maintaining various configuration flavors of OpenStack at scale.
 Unlike other platform-specific deployment or management utilities, Fuel is an
 upstream OpenStack project that focuses on automating the deployment and
 testing of OpenStack and a range of third-party options, so it’s not
 compromised by hard bundling or vendor lock-in.
 .
 This package provides the static file bundled JS built using NPM and Gulp. At
 this point the use of NPM and Gulp makes it a non-free package, but the
 package maintainer hopes to fix this soon.

- - - - -

Note from the maintainer: currently, the package in the Git on Alioth is doing
HOME=$(CURDIR) npm install
HOME=$(CURDIR) node_modules/.bin/gulp build --static-dir=compressed_static

This is of course not acceptable for an upload to main. I will try to work out
packaging each individual Javascript (node) dependencies to make it happen.
Though in the mean while, if you want to try Fuel with its web GUI, you can
use the git repository on Alioth and build the package yourself:
Vcs-Git: https://anonscm.debian.org/git/openstack/fuel-ui.git

The rest of Fuel doesn't have such issue, and can still be used without the
Web GUI, using the fuelclient cli.

Bug#818409: ITP: puppet-module-saz-rsyslog -- Puppet module for rsyslog

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-saz-rsyslog
  Version : 2.2.1
  Upstream Author : Steffen Zieger 
* URL : https://github.com/saz/puppet-rsyslog
* License : Apache-2.0
  Programming Lang: Ruby, Puppet
  Description : Puppet module for rsyslog

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This module manages both the installation and configuration of rsyslog.

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Jakub Wilk]

Can someone explain why we are bringing Firefox back? Are we going to 
rename it again if^Wwhen Mozilla stops liking us?


Also, why there are two firefox* packages, and what's the difference 
between them? (They have identical descriptions...)


* Josh Triplett , 2016-03-18, 15:06:
Firefox addon packages (xul-ext-*) typically have a Depends on 
iceweasel, sometimes with alternatives for icedove or other supported 
packages that can use the addon.  With the switch to firefox and 
firefox-esr, iceweasel has become a transitional package depending on 
firefox-esr.  The dependencies of these addon packages prevent 
installing only the firefox package and removing firefox-esr and the 
transitional iceweasel package.


So let's fix Depends of the transitional package. No MBF is needed.

--
Jakub Wilk

Bug#818547: RFH: vpnc -- Cisco-compatible VPN client

[Florian Schlichting]

Package: wnpp
Severity: normal

I request assistance with maintaining the vpnc package. I'm no longer
actively using it, and I never got around to learn enough about ipsec
to really understand what's going on and (sometimes) going wrong. Hence
I feel I'm unable to properly debug and support some kinds of issues,
and my hope is that this RFH is read as an encouragement to pick things
up and move them forward as you see fit (sources are in collab-maint
git, no need to coordinate with me beforehand).

The package is in an ok shape generally without any pressing issues;
upstream is nice, but development has slowed to a crawl and support for
new hardware (Norton, Fortigate?) may be patchy in places. Still, it
continues to be useful for many people. Perhaps vpnc needs a
reenvigorated upstream more than a new packager?


The package description is:
 vpnc is a VPN client compatible with cisco3000 VPN Concentrator (also
 known as Cisco's EasyVPN equipment). vpnc runs entirely in userspace
 and does not require kernel modules except for the tun driver to
 communicate with the network layer.
 .
 It supports most of the features needed to establish connection to the
 VPN concentrator: MD5 and SHA1 hashes, 3DES and AES ciphers, PFS and
 various IKE DH group settings.

Bug#818408: ITP: puppet-module-aodh -- Puppet module for OpenStack Aodh

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-aodh
  Version : 8.0.0~b1
  Upstream Author : OpenStack Foundation 
* URL : https://github.com/openstack/puppet-aodh
* License : Apache-2.0
  Programming Lang: Ruby, Puppet
  Description : Puppet module for OpenStack Aodh

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This module manages both the installation and configuration of OpenStack
 Aodh.

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Niels Thykier]

David Prévot:
> Le 18/03/2016 18:06, Josh Triplett a écrit :
> 
>> I would suggest that Firefox addon packages should depend on "firefox |
>> firefox-esr"
> 
> Most of those packages are mozilla-devscripts for the build and just
> need to be rebuilt to get fixed. Even if our infrastructure has all the
> needed tools to binNMU all of them as a proper transition, some
> limitations on the way arch:all binNMU are handled currently prevents us
> from having most of them already fixed, see #818104.
> 
> What is currently needed if the arch:all binNMU doesn’t get fixed, is
> “just” to upload all of them. I’m currently dragged into doing that for
> hundred of PHP classes packages because of this no arch:all binNMU
> limitation, so I hope someone else from the Debian Mozilla Extension
> Maintainers could take the lead on it (new members are welcome ;).
> 
> Regards
> 
> David
> 

For those wondering about the reasons:

 * dak has a "no arch:all binNMU" check that rejects arch:all binNMUs.
   - It might be time to lift this restriction.

 * These days we could in theory binNMU source packages building only
   arch:all packages.

 * There is a caveat with source packages building both arch:all and
   arch:any packages, where the substvars no longer ensures
   installability (because they assume that version of arch:all is the
   version of the source package).

   - I have tried to device a lintian check which might help us get an
 overview of this situation.

Thanks,
~Niels







signature.asc
Description: OpenPGP digital signature