> because your situation is quite the exception.
Had the same issue here. jovie which I never used was installed and depends on
kde-runtime.
apt/apt-get couldn't resolve it. I had to:
sudo dpkg -i /var/cache/apt/archives/kde-cli-tools-data_4%3a5.24.2-1_all.deb
sudo dpkg -i --force-overwrite
libcurl3-gnutls 7.50.1-1
> ii zlib1g 1:1.2.8.dfsg-2+b1
>
> curl recommends no packages.
>
> curl suggests no packages.
>
> -- debconf-show failed
>
>
Mehdi khanpor
On 2021-01-27 15:49, Laurent Bonnaud wrote:
On 1/23/21 9:07 PM, Mehdi Dogguy wrote:
Thanks for the bugreport and sorry for not replying earlier!
No problem!
I wasn't able to reproduce this bug.
Thanks for trying!
FWIW, I've just uploaded dochelp 0.1.8 with a couple of bugfixe
Package: doc-base
Version: 0.11
Severity: wishlist
Hi,
I created dochelp some years ago to have simple yet effective tool to
browse doc-base registered documentation installed on one's system.
dochelp doesn't require any webserver or heavy tool. It generates a
static web page which allows search
On Sat, Jan 23, 2021 at 09:07:13PM +0100, Mehdi Dogguy wrote:
> I wasn't able to reproduce this bug. Are you able to identify which
> package specifically made dochelp crash? It would help a lot to debug
> it.
>
FWIW, I've just uploaded dochelp 0.1.8 with a couple of bugfix
)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages dochelp depends on:
> ii libc6 2.29-4
> ii libjs-jquery 3.3.1~dfsg-3
> ii libpcre3 2:8.39-12+b1
>
> dochelp recommends no packages.
>
> dochelp suggests no packages.
>
> -- no debconf information
>
> --
> Laurent.
--
Mehdi Dogguy
ules=yes
> ProtectKernelTunables=yes
> ProtectSystem=strict
> ReadWritePaths=/var/lib/mldonkey
> RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
> RestrictRealtime=yes
> StateDirectory=mldonkey
> SystemCallArchitectures=native
> Type=simple
> User=mldonkey
> WorkingDirectory=/var/lib/mldonkey
>
> [Install]
> WantedBy=multi-user.target
--
Mehdi Dogguy
On 2021-01-05 22:07, Christoph Berg wrote:
Re: Mehdi Dogguy
Bug #876966 in ben reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
I pulled scripts.js manually and change works nicely. Thanks!
Thanks a lot for checking, Christoph!
Happy
hi,
on jessie, after upgrade to libssh2-1_1.4.3-4.1+deb8u2, the following PHP
code doesn't work anymore.
could it be related to this fix?
https://github.com/libssh2/libssh2/commit/ca2744483eac4e707084df5fc55cc69d57571dde
PHP Warning: ssh2_auth_pubkey_file(): Authentication failed for test
usin
Sure, but it is still an improvement over the current situation and is simple
enough to minimize its impact. Of course, it should be considered as a
wrkaround, until upstream releases a fixed version.
Le 29 octobre 2018 19:41:06 GMT+01:00, Brian Smith
a écrit :
>Hi Mehdi,
>
>
>On
issue for users
(and reverse dependencies) while giving upstream more time to
investigate it.
--
Mehdi
the code didn't change at all. I was able to
reproduce the issue, but I am not actually sure yet from where the
regression is coming.
--
Mehdi
Hi Jonas,
On 2018-10-15 19:54, Lippuner, Jonas wrote:
I'm having the same issue with libpsm2-2 version 11.2.68-1. Downgrading
to 10.3.58-2 fixes it for me.
Can you please explain how you experienced the bug? I've understood
Drew's
case, but maybe yours is slightly different.
--
Mehdi
On 2018-09-09 10:44, Ralf Jung wrote:
Hi Mehdi,
On 2018-09-07 12:42, Ralf Jung wrote:
Package: opam
Version: 2.0.0-2
Severity: normal
Dear Maintainer,
Quoting from https://opam.ocaml.org/doc/2.0/External_solvers.html:
As of 2.0.0, opam comes with a CUDF solver built-in by default, so
lt-in solver is not enabled in the Debian
package
because we are missing ocaml-mccs to make it work. So, for now, the
dependency
is still needed.
Regards,
--
Mehdi
any longer.
Time permitting, I will continue to upload new releases and fix
outstanding bugs
but certainly not in sync with frama-c's release cycle. I am willing to
mentor
people familiar with OCaml and willing to maintain Frama-c in the
future.
--
Mehdi
Hi nico,
On 2018-08-23 16:53, Nicolas Braud-Santoni wrote:
Hi Mehdi,
On Thu, Aug 23, 2018 at 03:00:22PM +0200, Mehdi Dogguy wrote:
> [...]
> It makes opam unusable for jessie users: already initialised ones can't
> install new compilers nor update packages, and with a fresh ins
emoval, or document in this bugreport how to point
their
installation to a frozen working mirror?
In the meantime, I'll work on a {sloppy-,}backport of 1.2.2.
--
Mehdi
Indeed :-)
Le 22 juin 2018 05:00:35 GMT+02:00, Andy Li a écrit :
>On Fri, Jun 22, 2018 at 5:01 AM, Mehdi Dogguy wrote:
>> Excellent work! I've reviewed it and it looks fine. I'll upload it
>shortly.
>> Would you mind retitling thing bug to an "ITP: ..."
it and it looks fine. I'll upload it
shortly.
Would you mind retitling thing bug to an "ITP: ..." and setting yourself
as its owner?
Cheers,
--
Mehdi
Control: reopen -1
Hi Roland,
If I am not mistaken, your last upload moves files across binary
packages but doesn't add necessary Breaks/Replaces. In the current
state, upgrades are broken because older libfabric1 and newer
libfabric-dev are not co-installable.
Regards,
--
Mehdi
Source: openmpi
Version: 3.1.0-6
Severity: normal
Hi,
PSM2 was accepted in Debian a few weeks ago. It would be very nice to
see its support enabled in OpenMPI.
Cheers,
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Archi
build fail later in
the process (can't generate manpages and test-suite doesn't succeed).
Do you confirm this on your side as well?
--
Mehdi
Package: wnpp
Severity: wishlist
* Package name: odoc
Version : 1.2.0
Upstream Author : Thomas Refis and al.
* URL : https://github.com/ocaml/odoc
* License : ISC
Programming Lang: OCaml
Description : documentation generator for OCaml
odoc is a document
Package: courier-imap
Version: 4.15-1.6
Severity: grave
Justification: renders package unusable
Dear Maintainer,
* What led up to the situation?
apt-get update
apt-get -y -V upgrade
apt-get -V -y install ntpdate wget sudo dnsutils aptitude apt-utils
lsb-release bash-complet
It's based on the discussion with upstream at
https://discuss.ocaml.org/t/the-forever-beta-issue/1779/6
Thanks for the pointer.
Cheers,
--
Mehdi
Package: opam
Version: 1.2.2-6+b1
Severity: serious
opam fails to build from source using latest cmdliner which was uploaded
to Debian/Sid a few days ago:
File "client/opamArg.ml", line 384, characters 25-29:
Error: This expression has type
?docv:string ->
(string -> ('a, [ `Msg
s:
$ ocamlbuild -pkg ben foo.cmx
$ ocamlopt -shared -o foo.cmxs _build/foo.cmx
In short: Do not use ocamlbuild to generate the .cmxs
file.
--
Mehdi
ed in Debian).
Regards,
--
Mehdi
Package: wnpp
Severity: wishlist
* Package name: ppx-tools-versioned
Version : 5.1
Upstream Author : Alain Frisch and al.
* URL : https://github.com/ocaml-ppx/ppx_tools_versioned
* License : MIT
Programming Lang: OCaml
Description : Tools for authors of
Package: wnpp
Severity: wishlist
* Package name: markup.ml
Version : 0.7.6
Upstream Author : Anton Bachin
* URL : https://github.com/aantron/markup.ml
* License : BSD-2
Programming Lang: OCaml
Description : Error-recovering streaming HTML5 and XML parser
On 2018-05-14 18:46, Sebastiaan Couwenberg wrote:
On 05/14/2018 08:26 AM, Mehdi Dogguy wrote:
On 2018-05-14 08:01, Sebastiaan Couwenberg wrote:
Unfortunately that doesn't apply cleanly on top of 0.7.4 for stretch.
If
you can provide a rebased commit for 0.7.4 I'm willing to test t
On 2018-05-14 08:01, Sebastiaan Couwenberg wrote:
Unfortunately that doesn't apply cleanly on top of 0.7.4 for stretch.
If
you can provide a rebased commit for 0.7.4 I'm willing to test that.
No problem. Here it is (attached). Thanks for your tests!
Kind Regards,
--
Mehdi--- a/_
are used again.
FWIW, I've got a better fix:
https://salsa.debian.org/debian/ben/commit/c298da34ec0f4ebc0e68e51a220c2fd9b04fa6fd
It fixes the issue at its root, and doesn't only workaround one specific
case.
--
Mehdi
On 2018-05-13 21:10, Sebastiaan Couwenberg wrote:
On 05/13/2018 08:32 PM, Mehdi Dogguy wrote:
On 2018-05-13 15:44, Sebastiaan Couwenberg wrote:
Those are the files in the current working directory, and may be from
a
different distribution.
All the global.conf files use a separate cache-dir
ones, these
settings are no longer used. It looks like the hardcoded defaults are
used instead.
Indeed. I think I found the culprit. Can you test this commit?
https://salsa.debian.org/debian/ben/commit/aba1f9a8e567502da18c11b8b89dc45f9eed4c19
Kind Regards,
--
Mehdi
Hi Sebastiaan,
On 2018-05-13 14:13, Sebastiaan Couwenberg wrote:
On 05/13/2018 01:59 PM, Mehdi Dogguy wrote:
On 2018-05-13 13:51, Sebastiaan Couwenberg wrote:
On 05/13/2018 01:25 PM, Mehdi Dogguy wrote:
On 2017-09-22 18:37, Bas Couwenberg wrote:
Package: ben
Version: 0.7.4+b4
Severity
On 2018-05-13 13:51, Sebastiaan Couwenberg wrote:
On 05/13/2018 01:25 PM, Mehdi Dogguy wrote:
On 2017-09-22 18:37, Bas Couwenberg wrote:
Package: ben
Version: 0.7.4+b4
Severity: important
Dear Maintainer,
Since the upgrade to stretch my ben setup no longer works as before.
The `ben tracker
his bug will be closed with
the next upload.
Regards,
--
Mehdi
true;" in your global.conf file?
--
Mehdi
'prerm remove' avoids having a dangling link
> once the actual file gets removed, but 'prerm remove' is not called in
> all cases (e.g. unpacked but not configured packages or disappearing
> packages) so the postrm must remove the alternative again
> (update-alternatives gracefully handles removal of non-existing
> alternatives).
>
Regards,
--
Mehdi
On 12/01/2018 21:45, Hattne, Johan wrote:
>
>> On Jan 12, 2018, at 15:00, Mehdi Dogguy wrote:
>>
>> I agree. My patch would only help others to not fall into the trap of
>> using slurm's default pid paths. A more suitable mid-term goal would be to
>>
pstream. I'll leave this bugreport open
(and retitle it accordingly) to remind us about what's remaining to do.
Before doing so, I'd like to hear from my co-maintainer about the reasons of
why we are using /var/run/slurm-llnl instead of /var/run in case I've missed
something.
Regards,
--
Mehdi
iguration files for (respectively) slurmctld, slurmd and slurmdbd.
I am not going to revert changes on the run directory in the debian
packaging for now (as I guess my co-maintainer had good reasons to override
them), but I'll change debian's provided slurm's defaults to be coherent
with the reste of the package.
Regards,
--
Mehdi Dogguy
Hi Ross,
It is great to hear that pkg-multimedia is willing to take care of this
package. Did you make any progress on this package?
AFAIK, current version is broken and doesn't work anymore. An update to
the latest upstream version is very much needed.
Regards,
--
Mehdi
> - add 0012-Reproducible-build.patch
I made a typo in the changelog and closed the wrong bug. Sorry for that. I am
opening it again.
Regards,
--
Mehdi Dogguy
pstream asking whether bytecode architectures are still supported.
I didn't want to patch Frama-C to make it build again there is there is no
will from upstream to support those architectures (It is trivial to fix but
might a useless effort). I am still waiting for their reply.
--
Mehdi
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Slurm 16.05.9-1 has been uploaded to Unstable a while ago and is a bug
fix release. The diff is large but it contains many fixes (See summary
in upstream's NEWS file) and Slurm minor release
t;> A: Recommend to Appoint David Bremner
>>> B: Further Discussion
>>>
>>> ===END
>>
>> I vote A > B
>
> So, with that vote added, option A defeats B by 4 votes, and we thus
> agree to recommend David for the TC.
>
> Mehdi, does
d accept a fix for this bug (potentially after Feb 5th, if the patch is
not ready 10 days before the freeze). Trading a known broken feature with a
patch that might get the functionality back is not a big risk.
> Maybe we can ask Helmut to provide a patch?
>
We can. Adding him in the loop (as I guess submitters are not automatically
subscribed to bugs).
Cheers,
--
Mehdi
to see what this has to do with my complaint.
>
Ok, so the bug is in the description. Could you please provide a patch which
enhances the descriptions and makes them less confusing?
Regards,
--
Mehdi
Caml.
while ocaml-nox's description has:
This package contains everything needed to develop OCaml applications
that do not require the graphics library.
So, if you are trying to build ocaml binaries, ocaml-nox should be preferred
over ocaml-base-nox.
What do you think?
Regards,
--
Mehdi
On 21/12/2016 20:59, Ralf Treinen wrote:
> Hi Mehdi,
>
> On Wed, Dec 21, 2016 at 03:09:10PM +0100, Mehdi wrote:
>> Hi Ralf,
>>
>> Did you ask for its removal?
>>
>> FWIW, i'm also for its removal from debian since the project is dead
>&
t continue to rot as part of d-o-m.
>
>I am for (2). So, if noone steps up for (1), and if there are no
>objections
>by one week from now, I will ask ftp for removal.
>
>Cheers -Ralf.
--
Mehdi
b's build failure
there.
Regards,
--
Mehdi
signature.asc
Description: OpenPGP digital signature
On 06/11/2016 10:19, Adrian Bunk wrote:
> On Sun, Nov 06, 2016 at 09:59:20AM +0100, Mehdi Dogguy wrote:
>> I've tried a rebuild on harris with pic_code set to true for arm. The build
>> succeeded and all tests passed fine. Do you want to run more tests or should
>
Salut Ralf,
On 06/11/2016 08:27, Ralf Treinen wrote:
> Salut Mehdi,
>
> On Sat, Nov 05, 2016 at 06:36:06PM +0100, Mehdi Dogguy wrote:
>> Hi Ralf,
>>
>> On Tue, Oct 25, 2016 at 09:08:34AM +0200, Ralf Treinen
>> wrote:
>>> Hi Chris,
>>>
>&
ent to fix this, and already requested.
>
The binNMU has been scheduled and the only missing issue is to do with PIC on
armhf. The issue needs to be fixed in OCaml only. Hence, I am reassigning the
bug. Once OCaml is fixed on armhf, ocamlgraph could be given back to build.
Regards,
--
Mehdi
figure out how to make Cflags.pic_code true,
> which shouldn't be too hard. I will try this tomorrow when I'm less tired.
>
I've tried a rebuild on harris with pic_code set to true for arm. The build
succeeded and all tests passed fine. Do you want to run more tests or should
I upload this change?
Regards,
--
Mehdi
rovide libsexplib-camlp4-dev.
>
libsexplib-camlp4-dev is gone for good. So, there is nothing to fix in sexplib
and reverse dependencies have to be fixed. Hence, closing this bugreport
and opening required new bugreports.
Regards,
--
Mehdi Dogguy
;
Did you understood what actually makes it fail? It builds fine in a clean
chroot on my machine (dunno by which miracle).
The errors orginally reported by Chris are also not the same seen on the
buildds.
Regards,
--
Mehdi Dogguy
g on
a backward compatible patch to make it work with both OpenSSL 1.0 and
1.1.
So I'd wait until he is ready. In the worst case scenario, we can still
fallback to OpenSSL 1.0 to give us more time to work on the patch.
Regards,
--
Mehdi
tried to rebuild parmap in a clean Sid chroot and I am unable
to reproduce the build failure. You can find attached my build log.
Does it still fail for you?
Regards,
--
Mehdi
dpkg-buildpackage: info: source package parmap
dpkg-buildpackage: info: source version 1.0~rc7-1
dpkg-buildpackage: in
... but why not requesting a rebuild of the package
instead of opening this bug? Is there anything else to do besides doing the
binNMU?
--
Mehdi
anymore. Similar fixes have been
applied to other softs.
Another way to avoid the bug in Debian is to use OpenSSL 1.0 by choosing
libssl1.0-dev in the Build-Depends line. It doesn't fix the issue but prevents
the system from removing it from testing.
Regards,
--
Mehdi
From: Mehdi Dogguy
Da
On 06/10/2016 00:32, John Paul Adrian Glaubitz wrote:
> On 10/06/2016 12:21 AM, Mehdi Dogguy wrote:
>> I have read your message, and I can understand it can be difficult at
>> time to deal with recurrent bugreports. But, I do not feel comfortable
>> with the way you expressed
utors and users, to be able to interact in
a safe and pleasant environment. We are all here to make fun! So
please, let's make it enjoyable the best we can.
[1] https://www.debian.org/code_of_conduct
All best,
--
Mehdi Dogguy
and simplify the step of identifying
the new member's login name, can you please add the login in the subject? (Or
where you feel appropriate).
Something like "Subject: New Debian Developer, $status: $name <$login>" would
be perfect.
Thanks for your work!
--
Mehdi
grating some code to new versions of some libraries.
Regards,
--
Mehdi
should not focus our attention on them.
>We can hope that usually people who are pleased by TC decisions are
>more numerous, but in the context of an "idea enablement" team, it
>is much more important that stakeholders don't have an initially
> negative view of the team members.
>
I truly believe project members to not have an initial negative view of
the TC.
Regards,
--
Mehdi
roadmap. Your example of the Reproducible Builds is only
speculation and I fail to link it to reality, tbh. Again, the idea of the
roadmap is not to _decide_ which ideas people should _not_ work on, but
rather which ones should be promoted to gather more momentum.
Regards,
--
Mehdi
ug (and also
partly later in this mail). Please let me know if there are other points I
didn't clarify.
>> During the BOF, a bunch of people volunteered to be part of the Roadmap
>> team, even though it was unclear what the Roadmap team should do and how it
>> should do that.
lans to implement.
> During the BOF, a bunch of people volunteered to be part of the Roadmap team,
> even though it was unclear what the Roadmap team should do and how it should
> do
> that.
>
> Initally, Mehdi wanted the TC to be the Roadmap team, but given the intent of
> f
team in 5.3100. It would be nice if someone
could adopt this package and update it to latest upstream version.
Bonus points if maintainer makes a backport too... ;)
Regards,
--
Mehdi Dogguy
On 20/04/2016 11:50, Julien Cristau wrote:
> Control: tags -1 confirmed
>
> On Mon, Apr 11, 2016 at 00:57:58 +0200, Mehdi Dogguy wrote:
>
>> Hi,
>>
>> On 10/04/2016 17:27, Julien Cristau wrote:
>>>> --- a/debian/changelog
>>>> +++ b/debi
ng
>> +files using wget and curl.
>> +
>
> Missing "closes:"?
>
Fixed in attached new diff.
Cheers.
--
Mehdi
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+opam (1.2.0-1+deb8u1) jessie; urgency=medium
+
+ * Stop using insecure and no-check-certificate
fetching
+ files using wget and curl.
+
+ -- Mehdi Dogguy Sun, 10 Apr 2016 12:27:13 +0200
+
opam (1.2.0-1) unstable; urgency=medium
* New upstream release.
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,4 +1,6 @@
[DEFAULT]
+debian-branch = "debian/jessie"
+upstream-branch =
On Sun, Mar 20, 2016 at 06:58:34PM +0100, Mehdi Dogguy wrote:
> On Thu, Nov 12, 2015 at 10:38:39AM +0100, IOhannes m zmölnig
> wrote:
> > Control: severity -1 important
> > thanks.
> >
> > i'm unable to reproduce the problem on my xfce4 machine.
> >
ough.
I agree that it still does something, but I would not call the package
usable. Its main purpose is really not to check signatures, but to
help signing/encrypting messages. So the severity should reflect that.
Regards,
--
Mehdi Dogguy
or target 'AAC.vo' failed
>> make[4]: *** [AAC.vo] Error 1
>> make[4]: Leaving directory '/<>'
>
This looks like a duplicate of #813459.
Regards,
--
Mehdi
Control: reassign 812178 camlp5
Control: severity 812178 important
Control: found 812178 camlp5/6.14-1
Control: fixed 812178 camlp5/6.14-2
On 21/01/2016 09:25, Mehdi Dogguy wrote:
> Trying to build matita with a fixed camlp5 package that includes upstream
&g
Hi Claudio,
On 25/01/2016 20:54, Claudio Sacerdoti Coen wrote:
> Dear Mehdi,
>
> the most recent camlp5 version in git seems to fix enough bugs to let
Thanks for handling this with camlp5's upstream. I can confirm it builds
fine with latest two fixes in camlp5. I'll prepare
On 2016-01-20 01:14, Mehdi Dogguy wrote:
Hi,
On 19/01/2016 23:07, Christoph Berg wrote:
Long story, but that's the real-world example here. In fact I'm
considering upgrading the apt.pg.o build host to stretch just because
of this bugfix, and because a backport of the current dos
Package: matita
Version: 0.99.1-3
Severity: serious
Dear Maintainer,
Trying to build matita with a fixed camlp5 package that includes upstream
fix (caca3dd0643ec5aae9df4399fa73eb280808ef18) fails with the following
error:
OCAMLC hExtlib.ml
File "hExtlib.ml", line 463, characters 10-23:
War
Hi Enrico,
On 20/01/2016 11:15, Enrico Tassi wrote:
> On Sun, Oct 18, 2015 at 11:03:35PM +0200, Mehdi Dogguy wrote:
>> Package: src:matita
>> Version: 0.99.1-3
>> Severity: serious
>>
>> Dear Maintainer,
>
> This bugs is due to camlp5 and fixed in
>
Hi
On 20/01/2016 01:10, Pietro Abate wrote:
> Hi
>
> On 20/01/16 00:00, Mehdi Dogguy wrote:
>> Only did a quick grep:
>>
>> % git grep -n "\"src:" **/*.ml
>> applications/deb-buildcheck.ml:182: let (name,filter) =
>> Debian.Debutil.
eck.ml" should not be
kept. That's the part that will require a newer Extlib if a workaround cannot
be found.
Regards,
--
Mehdi
diff -ruNd dose3-4.1/myocamlbuild.ml.pp new/myocamlbuild.ml.pp
--- dose3-4.1/myocamlbuild.ml.pp 2016-01-04 12:53:12.0 +0100
+++ new/myocamlbuild.ml
Hi Pietro,
Thanks for the quick reply!
On 19/01/2016 23:41, Pietro Abate wrote:
>
> This change was indeed intentional.
Thanks for the confirmation!
>
> Mehdi, where are these places in the code that still expect "src:" ?
> I've removed this prefix from all th
.2. I'd appreciate a
confirmation by upstream though.
@Pietro: Can you please enlighten us on this issue?
Regards,
--
Mehdi
sed in 4.2.
Please let us know if the fix addresses all your concerns or needs further
changes.
Regards,
- --
Mehdi
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJWnp5jAAoJEDO+GgqMLtj/wEIP/3j8IlGdOSQUeFpKECEY9Mph
HJ5RT5Lj7MrbtsDpQGGcY4bQCCwT5hqexpJunA3oVS737zdQA1
ntering an issue that is not covered by what I've described, please
do share it with us so that we can try to help you.
>
> Have fun.
>
Likewise.
Kind regards,
--
Mehdi
on't work with OCaml >=4.02.3.
For now, we've requested the removal of Unison 2.40 and 2.32 from
Stretch and we are looking for a solution to make 2.48 also work
in stable.
Regards,
--
Mehdi
Package: ftp.debian.org
Severity: normal
Hi,
Unison 2.32 is broken now that we moved to OCaml 4.02.3 (See #809225).
Just like Unison 2.40, please remove it from the archive.
Regards,
--
Mehdi
ersion in Stretch.
If you need a working Unison setup across multiple systems based on different
versions, you may copy needed Unison binary around, for now.
Regards,
--
Mehdi
On 2016-01-08 11:28, Enrico Zini wrote:
On Thu, Jan 07, 2016 at 09:05:51PM +0100, Mehdi Dogguy wrote:
Indeed. You can also see #807019 for more information about this bug.
At this point, we are stuck with no real solution (except doing
massive
backports). Some people copy over unison binary
Package: ftp.debian.org
Severity: normal
Hi,
Unison 2.40 is broken now that we moved to OCaml 4.02.3 (See #807019).
Please remove it from the archive. I've uploaded an updated meta-unison
package which removes the dependency on this package.
Regards,
--
Mehdi
019 for more information about this bug.
At this point, we are stuck with no real solution (except doing massive
backports). Some people copy over unison binary on Jessie systems to
be able sync, or install Jessie's unison on their testing or sid box.
Regards,
--
Mehdi
Source: ben
Version: 0.7.0
The documentation as well the templates contain http links. Those should
use
https instead of http.
ly. This is done for many packages: OCaml for its bootstrap
and most probably ghc (didn't check tbh). Also, compiling gcc requires
a gcc. :-P
My 2 cents,
--
Mehdi
Hi,
On 04/01/2016 11:57, SOUBEYRAND Yann - externe wrote:
>
> Thank you for the review of the package.
>
> FYI I've open a RFS to find a sponsor for the upload
> (https://bugs.debian.org/809809).
>
I've uploaded it.
Thanks for your contribution!
Regards,
--
Mehdi
1 - 100 of 1290 matches
Mail list logo
