Jeremy Bícha wrote:
> https://www.mozilla.org/en-US/privacy/firefox/ which does include the
> new Terms of Use.
I don't see a link on that page to the new ToU. (It does link to some
ToU's of chatbots.)
> It is also linked to in Help > About Firefox.
Indeed it is! While this is a ways from "mak
Mozilla plans to put the new Terms of Use in front of users soon.
https://blog.mozilla.org/en/products/firefox/firefox-news/firefox-terms-of-use/
And actually asking you to acknowledge it is an important step, so we’re
making it a part of the standard product experience starting in early
Ma
I was looking at this bug the other day trying to determine why
git-annex was not in testing, and did not realize it was due to this
dbus issue. My mail below digs into it, if the issue is still
happening.
- Forwarded message from Joey Hess -
Date: Mon, 23 May 2022 12:48:21 -0400
From
Seeing this bug after upgrade. My imap server is dovecot.
--
see shy jo
signature.asc
Description: PGP signature
version 1.0.1 fixes this
--
see shy jo
signature.asc
Description: PGP signature
It could be converted to haskeline or raw IO, but gnu readline is the
kind of library I think it makes sense to have language bindings to, and
to use the bindings.
This patch seems to fix the build problem:
--- readline-1.0.3.0.orig/readline.cabal2020-06-17 17:09:11.438264895
-0400
+++ r
This is still happening, the legitimate public servers may not work with
electrum 3.3, but there are dozens of rogue servers that do and that are
exploiting this bug.
--
see shy jo
signature.asc
Description: PGP signature
Sean Whitton wrote:
> Errors are like this:
>
> .t/gpgtest/9/S.gpg-agent.extra:
> removeDirectoryRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:r
> emovePathRecursive:getSymbolicLinkStatus: does not exist (No such fil
Package: ghc
Version: 8.0.1-14
Severity: serious
git-annex: unable to decommit memory: Invalid argument
This happened with a git-annex built with this ghc, and bundled with
Debian's glibc (essentially a chroot), on a Fedora system with a 4.4.14
Linux kernel.
It apparently then led to memory corr
I suppose this is the problem that this bug report is about:
root@ia-bak:/usr/local/propellor# graphite-manage
Traceback (most recent call last):
File "/usr/bin/graphite-manage", line 15, in
execute_from_command_line(sys.argv)
File "/usr/lib/python2.7/dist-packages/django/core/management
Yaroslav Halchenko wrote:
> # ldd
> /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.10.3/network-protocol-xmpp-0.4.8-AArRa3ialU19Kz62aVPiMC/libHSnetwork-protocol-xmpp-0.4.8-AArRa3ialU19Kz62aVPiMC-ghc7.10.3.so
> | grep gnutls-deb
> libgnutls-deb0.so.28 => not found
joey@darkstar:~>dp
Joey Hess wrote:
> apt-get -y install ghc libghc-ifelse-dev libghc-missingh-dev
> libghc-unix-compat-dev libghc-data-default-dev libghc-exceptions-dev
> libghc-http-types-dev libghc-bloomfilter-dev libghc-old-locale-dev
> libghc-resourcet-dev libghc-monad-control-dev libghc-edit-
Joachim Breitner wrote:
> If we can isolate the problem nicely, I’ll be happy to discuss this
> with upstream.
deboostrap sid
in chroot:
mount -t proc proc /proc
apt-get -y install ghc libghc-ifelse-dev libghc-missingh-dev
libghc-unix-compat-dev libghc-data-default-dev libghc-exceptions-dev
li
Joachim Breitner wrote:
> I think I got it: Cabal tries to infer what feature are supported by
> looking at the dependencies, and their flags, and mumble mumble complex
> search space.
Except while Cabal falls over, cabal-install does not.
For example:
joey@kite:~/git-annex>dpkg-checkbuilddeps
Holger Levsen wrote:
> has anyone actually tested this patch?
Yes.
--
see shy jo
signature.asc
Description: Digital signature
Tianon Gravi wrote:
> I would actually be very surprised if the issues you've encountered so
> far are the only issues with Docker on a 3.2 kernel.
Just to be clear, my intent was not to use docker with an old kernel.
I was just deploying a system whose configuration included docker,
and since doc
Package: docker.io
Version: 1.3.3~dfsg1-1
Severity: serious
Here's a system that was upgraded to unstable but not yet rebooted into the new
kernel..
root@clam:~>uname -a
Linux clam 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux
root@clam:~>touch /hello-host
root@clam:~>docker exec oldusene
Raphael Geissert wrote:
> I've ran checkbashisms (from the 'devscripts' package) over the whole
> archive and I found that your package has a /bin/sh script that uses a
> "bashism".
>
> checkbashisms' output:
> > possible bashism in ./usr/bin/git-remote-gcrypt line 102 (setvar 'foo'
> > 'bar' shou
Package: guthub-backup
Version: 1.20141110
Severity: serious
joey@darkstar:~/src/github-backup>./github-backup joeyh
Usage: github-backup [USERNAME|ORGANIZATION] [--exclude USERNAME/REPOSITORY]
This leaves the program mostly useless, unable to backup all a user's
repos, although it can still be r
Source: dovecot
Version: 1:2.2.13-7
Severity: serious
After upgrading to this version, I cannot connect to dovecot's imap or
pop servers.
joey@darkstar:~>telnet kitenet.net imap
Trying 66.228.36.95...
Connected to kite.kitenet.net.
Escape character is '^]'.
Connection closed by foreign host.
Off
severity 768093 important
thanks
On second thought I don't consider this RC:
* It doesn't seem to actually result in very significant data loss.
* Pointing --git-dir at something not a git repo is asking for undefined
behavior. This is a little more undefined than could be desired,
but the us
Package: git-annex
Version: 5.20141024
Severity: serious
http://git-annex.branchable.com/bugs/misuse_of_--git-dir_might_destroy_a_git_repository_completely/
--
see shy jo
signature.asc
Description: Digital signature
Santiago Vila wrote:
> Instead, the work of debootstrap is precisely to guess the right order
> in which packages should be configured so that everything work.
>
> In other words, essential packages should not get in the business of
> breaking dependency cycles, because that's debootstrap job.
>
Petter Reinholdtsen wrote:
> Here is another draft, this time also providing the module name. I
> dropped the code looking in /proc/modules, as three ways to find
> firmware seem a bit too much.
Looking at dmesg might fail if something is spamming it and the message
drops out of the ring buffer.
Aurelien Jarno wrote:
> We have scheduled a few thousands of binNMUs on s390x due to the libc
> ABI breakage. It occurs that most of the non binNMUs safe packages are
> wrongly using this --link-doc option.
>
> I am therefore increasing the severity of this bug. dh_installdocs
> --link-doc should
Gianfranco Costamagna wrote:
> llvm maintainer (Sylvestre) says that llvm-3.4 is going to disappear
> (not before jessie, but somewhen after), and llvm-3.5 is built
> correctly on arm{el,hf}.
>
> Isn't it better to just upload with llvm-3.5 and do some binNMUs
> instead of using the old one and be
Sylvestre Ledru wrote:
> Yes, I know :(
> However, 3.5 has been released a few weeks before this freeze, 3.4 is
> unmaintained,
> 3.5 will be maintained a bit more, Ubuntu is also doing the switch to
> 3.5 and I wanted to default Debian
> on the last version. And as you found, the workaround is eas
Here's some debian/rules hacks to fix this.
This forces use of llvm-3.4 for building ghc, as well as
modifying the wrapper scripts to force use of that version at runtime.
The control file also needs to be changed to depend on llvm-3.4, rather
than llvm.
Note that just uploading ghc with this pat
Confirmed that installing llvm-3.4 and putting /usr/lib/llvm-3.4/bin
first in PATH before running ghc lets it build working executables on
armel and armhf.
This is certianly a bug in ghc. It should not depend on llvm, but on the
llvm-$ver it was built against, and it should use the toolchain from
Package: ghc, llvm
Version: 7.6.3-16
Severity: serious
It seems that ./Setup configure segfaults:
(sid_armhf-dchroot)joeyh@harris:/tmp/git-annex-5.20140926$ ./dist/setup/setup
configure
Segmentation fault
https://buildd.debian.org/status/fetch.php?pkg=git-annex&arch=armel&ver=5.2014
Package: bash
Version: 4.2+dfsg-0.1+deb7u1
Severity: grave
Tags: security
http://seclists.org/oss-sec/2014/q3/679
root@diatom:/tmp/empty>bash --version
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or
Christoph Anton Mitterer wrote:
> reopen 749795
> I'm reopening this for now, even if the issue is solved from a technical
> point of view (see below why).
AAICS, #749795 talked about bringing this to the security team's
attention, but they never seem to have been CCed.
So the security team may n
Michael Biebl wrote:
> This bug has been open for a while and is now blocking the removal of
> hal [0]. What's your plan regarding sleepd? Do you still want to port it
> to some newer/other interfaces or should the package be removed from the
> archive?
I have no plans for sleepd.
--
see shy jo
Thorsten Glaser wrote:
> Florian Weimer dixit:
> >Historically, the OpenSSL command line tools have been intended for
> >debugging only.
>
> I disagree, in the case of genrsa and friends anyway.
Me too, and openssl(1ssl) does not mention debugging or not for
production use or give any warnings. A
I belive all failed arches are big endian.
The Crypto/Cipher/TripleDES.hs which is failing a roundtrip decrypt . encrypt
test is littered with code that assumes little endian:
word64ToBs :: Word64 -> B.ByteString
word64ToBs = runPut . putWord64le
This has been extensively rewritten in the 0.6.1
I have a patch in git, but I don't know if it works, or if it will
continue working with newer kernels.
--
see shy jo
signature.asc
Description: Digital signature
Louis Bettens wrote:
> Done. The patch is being pushed in a couple of minutes. I commited a
> NMU (at least in the changelog) so what's next?
This patch has been included in a new upstream release.
--
see shy jo
signature.asc
Description: Digital signature
See https://github.com/audreyt/network-multicast/pull/6 for a patch for
this and also for an ugly file descriptor leak bug.
--
see shy jo
signature.asc
Description: Digital signature
Source: haskell-network-multicast
Version: 0.0.7-2
Severity: serious
After rebuilding this package from source, it fails to work:
Prelude Network.Multicast> multicastReceiver "224.0.0.99"
*** Exception: user error (Network.Socket.setSocketOption: socket option
ReusePort unsupported on this s
Samuel Thibault wrote:
> It seems dh_auto_install does not run make install at all any more
> here. I don't really understand why: there is a Makefile, and it does
> contain an install rule (it's automake-generated), debian/compat is 8,
> and debian/rules merely contains:
I can look at this in 2 w
(Did not notice this bug until now, due to the way it was
reassigned to debhelper w/o ccing me.)
I don't think I can revert the change that broke this.
There are no other good approaches for fixing #713257.
To fix this in debhelper, it would need to somehow detect that this
Makefile uses a differ
Michael Gold wrote:
> vidir should either reopen the editor on error (maybe with comments at
> the top and above the bad lines) or save a copy of the edited list in
> the working directory.
>
> I have occasionally encountered this problem after spending a long time
> editing a large directory, and
Package: git-annex
Version: 4.20130521
Severity: serious
git-annex has a bug that can cause data loss:
http://git-annex.branchable.com/bugs/git_annex_add_removes_file_with_no_data_left/
This probably only affects adding tarballs of git-annex repositories.
Which is not a completely absurd use cas
Package: haskell-devscripts
Version: 0.8.17
Severity: serious
This probably affects many haskell packages, but the one I encountered
it with is haskell-hinotify. Running debian/rules binary fails:
debian/hlibrary.setup copy --builddir=dist-ghc --destdir=debian/tmp-inst-ghc
Installing library in
d
Daniel Leidert wrote:
> I received the report below. Turns out, that there is a clean target,
> but debuild fails, because there is no distclean target. Could there be
> a mixup or a regression with #706923/#707481?
Only to the extent that before it ignored the -C you have specified,
so make found
Seems I confused xgalaga with xgalaga++, which does use dh.
--
see shy jo
signature.asc
Description: Digital signature
Paul Wise wrote:
> Control: severity -1 grave
> Control: reassign -1 debhelper 9.20130518
> Control: affects -1 + src:xgalaga++
> Control: tags -1 - jessie
>
> The FTBFS bug against xgalaga++ (#707481) is caused by debhelper, it
> builds fine with debhelper 9.20120909 but not with debhelper
> 9.20
Colin Watson wrote:
> I can work around this. However, it's a consequence of a debhelper
> change, already reported in #707336. Since dh_installdirs no longer
> runs, debian/vigor is not created, and so the upstream Makefile's lack
> of 'mkdir -p' trips.
I was just looking at this, and realized
Paul Wise wrote:
> On Fri, 2013-04-26 at 08:51 +, Debian Bug Tracking System wrote:
>
> > haskell-github (0.7.0-1) experimental; urgency=low
> > .
> >* New upstream release (Closes: #706187)
>
> Thanks, but I think this bug needs to be fixed in wheezy too?
I hav
Vincent McIntyre wrote:
> I found the string, in po/sublevel1, here's the templates.po
> #. Type: select
> #. Choices
> #: ../choose-mirror-bin.templates.http-in:2001
> #: ../choose-mirror-bin.templates.ftp.sel-in:2001
> msgid "enter information manually"
> msgstr ""
>
> Is it the case that I need
Gaudenz Steinlin wrote:
> Do you know how the problem can be triggerd. As far as I remember only
> some installation from USB are affected and I don't know if the
> difference between those affected and those unaffected has ever been
> identified. If I know that I'm testing the right test case, I'm
Vincent McIntyre wrote:
> It's entirely possible this patch is not the full resolution of the various
> issues people have reported but I'm posting it to get feedback on the
> approach and get some help with correctly integrating it into d-i.
This adds a new translatable template, which it is far
Joachim Breitner wrote:
> If you want to avoid cdbs, I’d be happy to see dh support Haskell, but
> it should use the same building steps as haskell-devscripts now, I’d
> think.
I don't know if it's worth putting in the time to make debhelper support
haskell library packages, but it certianly makes
Attached are minimal patches that seem to work. The haskell-certificate
change is direct from upstream git rev
a156d857189fc880f7d0a2de3310e750994c766b,
like vincenthz suggested. The minor haskell-tls-extra change mirrors what's
currently in upstream too.
I've tested using tls-debug's tls-retrie
Package: libghc-tls-extra-dev
Version: 0.4.6.1-1
Severity: serious
The security fix in this release seems to have caused a reversion
which rejects certificates that everything else accepts are valid.
Amoung the certificates now rejected is www.box.com, which is a problem
for me with git-annex. Ot
Marcin Owsiany wrote:
> Thanks for the fast review, please see the revised patch attached.
Applied. I will upload it once the current debhelper gets into testing.
--
see shy jo
signature.asc
Description: Digital signature
Marcin Owsiany wrote:
> +# 4: either text: shell-quoted sed to run on the snippet. Ie,
> 's/#PACKAGE#/$PACKAGE/'
> +#or a sub to run on each line of the snippet. Ie sub {
> s/#PACKAGE#/$PACKAGE/ }
I had not thought about making it operate on each line rather than the
whole file, but I think
Marcin Owsiany wrote:
> - dh_installxmlcatalogs passing an overly long string to autoscript().
>
> I think whatever fix is implemented (unless someone knows an answer to my
> question above), it will mean a change to dh_installxmlcatalogs. So perhaps
> this bug should be cloned against xml-co
gregor herrmann wrote:
> Solution: set GIT_AUTHOR_NAME _and_ GIT_COMMITTER_NAME in test.hs
> (additionally to EMAIL; or GIT_AUTHOR_EMAIL and GIT_COMMITTER_EMAIL
> instead of EMAIL).
I've applied that patch, thanks.
I don't know that this is actually RC, is building on pbuilder some kind
of releas
Motiejus Jakštys wrote:
> Building git-annex in pbuilder on squeeze having backports.debian.org
> repository enabled yields this error:
> Testing 1:blackbox:0:git-annex init
> Testing 1:blackbox:1:git-annex add:0
>
reassign 681347 ftp.debian.org
VastOne wrote:
> Package: pkgsel
> Severity: serious
> Tags: d-i
> Can't exec "aptitude": No such file or directory at /usr/bin/debconf-apt-
> progress line 130. line 2.
aptitude's priority was downgraded to optional, but d-i still uses it to
install security upda
Soeren Sonnenburg wrote:
> I am not really sure what you suggest here: ssh into some s390x machine
> and build things manually then ran the dh_shlibdeps?
Well, yes, the bug needs to be reproduced and investigated to see what
is crashing, surely.
--
see shy jo
signature.asc
Description: Digital
Joey Hess wrote:
> You can use dh_shlibdeps -d to get the dpkg-shlibdeps command line,
-v actually
> run that with -v to get the objdump command line, and chase down which
> program is actually crashing that way.
--
see shy jo
signature.asc
Description
Soeren Sonnenburg wrote:
> When building shogun dh_shlibdeps crashes with
> *** glibc detected *** /usr/bin/perl: free(): invalid pointer:
> dpkg-shlibdeps: error: objdump died from signal 6
> dh_shlibdeps: dpkg-shlibdeps -Tdebian/shogun-ruby-modular.substvars
> debian/shogun-ruby-modular/usr/lib
shawn wrote:
> is this still the case, because if so, I would be happy to switch it
> over to using weather.gov and/or some other NOAA source directly for US
> weather. (this is the source for 99.9% of US weather data anyways)
http://bugs.debian.org/647749
--
see shy jo
signature.asc
Descript
Joey Hess wrote:
> <http://lists.debian.org/20111204195557.ga11...@gnu.kitenet.net>
This seemed a good opportunity to expand that into a BoF, so I've
submitted this: https://penta.debconf.org/penta/submission/dc12/event/931
classifying and exposing network dependencies
D
I actually disagree with the thesis of this bug report. Suppose that
Github went away tomorrow, or was blocked by an oppressive regime, or
similar. github-backup would suddenly have its usefullness *validated*.
Furthermore, it is very much an undecided issue which web-API-dependant
packages belong
forwarded 678787 https://github.com/mike-burns/github/issues/24
tag 678787 help
thanks
Lucas Nussbaum wrote:
> > sbuild-build-depends-github-backup-dummy : Depends: libghc-github-dev but
> > it is not going to be installed
I've tried to update libghc-github-dev earlier, but it's been broken by
Nicola Chiapolini wrote:
> Dear Maintainer,
> When git annex is run from inside a sub-directory of the repository
> only the files in this directory get resored to real files.
> All other files are still symlinks to a now missing .git/annex directory.
> If this was the only repository, these files
Ondřej Surý wrote:
> the recent debhelper update broke every dh_strip --dbg-package out there,
> unless of course the .build-id/* is intentional:
Two minutes looking for dh_strip in the changelog and reading bug
#642158 have convinced me that .build_id is intentional. How about you?
Did you do at
Helmut Grohne wrote:
> I ask for feedback on this combination of patches. Since the bug is
> assigned to debhelper now, I explicitly pull in the sgml-base
> maintainers (who seem to be MIA).
Right. As I think I've posted before to this bug, I will
move ahead with the debhelper changes as soon as
Package: policykit-1
Version: 0.104-2
Severity: serious
Tags: d-i
In d-i, it is very easy to set up a system without entering a root
password. d-i sets up sudo, and configures gksu to use it
(by changing an alternative).
On such a system, I was prompted by policykit for the (nonexistant) root
pas
Helmut Grohne wrote:
> On Mon, Apr 30, 2012 at 12:24:52PM -0400, Joey Hess wrote:
> > Helmut Grohne wrote:
> > > On the debhelper side it should be enough to remove all remaining calls
> > > to update-catalog and introduce a dependency on the changed sgml-base. I
>
Helmut Grohne wrote:
> I worked out the sgml-base part of the patch. It will turn the super
> catalog into a symbolic link from /etc/sgml/catalog to
> /var/lib/sgml-base/supercatalog and update the latter file using
> triggers. The loosing of user configuration will persist in all detail
> until pa
Helmut Grohne wrote:
> On Thu, Apr 26, 2012 at 06:18:40PM -0400, Joey Hess wrote:
> > This is why I originally recommended that the registration process be
> > converted to use triggers. A [directory full] of catalogs, and a root
> > catalog
> > file automatically gene
Joey Hess wrote:
> This is why I originally recommended that the registration process be
> converted to use triggers. A file fill of catalogs, and a root catalog
^ directory full
> file automatically generated from them (which need not be a config
Helmut Grohne wrote:
> It gets even worse. Consider the case where a maintainer removes a
> catalog from an existing package and stops calling dh_installcatalogs.
> Then the root catalog would contain a dangling reference and there
> really is no way to fix this anymore, because our code is never i
Helmut Grohne wrote:
> So we seem to agree that both solutions (present vs. adding --transition
> to sgml-base) are doable and both have their own problems. Are you still
> interested in pushing the transitional code to sgml-base? Your arguments
> have convinced me that it could work. I have not ye
Erik de Castro Lopo wrote:
> That brings us to the language-javascript problem. Firstly, we should
> really ask upstream to ship the Lexer.x file from which the Lexer.hs
> file is generated. However the reason they reason they ship the haskell
> source rather than the lexer source is so that its po
Here's what happens when I try to validate a (100% valid) XHTML 1.0
document, now that w3c-sgml-lib has been changed in a way that breaks
w3c-html-validator:
*** Errors validating html/index.html: ***
Error at line 237, character 28: omitted tag minimization parameter can be
omitted only
Lucas Nussbaum wrote:
> > The following packages have unmet dependencies:
> > sbuild-build-depends-pyside-dummy : Depends: libphonon-dev but it is not
> > going to be installed
> > E: Unable to correct problems, you have held broken packages.
> > apt-get failed.
So more than one of these... perh
Lucas Nussbaum wrote:
> > sbuild-build-depends-github-backup-dummy : Depends: libghc-github-dev but
> > it is not going to be installed
> > E: Unable to correct problems, you have held broken packages.
I have no idea what this means. How can it possibly be a bug in
github-backup?
--
see shy jo
Helmut Grohne wrote:
> > In the unlikely event that the admin called it, it would detect that
> > the file was a conffile and not delete it.
>
> An admin could call update-catalog --transition for a package that was
> not rebuilt with the newer debhelper. In that case harm would still
> happen. Do
Helmut Grohne wrote:
> These were my points.
>
> On Sat, Jan 07, 2012 at 10:25:17PM +0100, Helmut Grohne wrote:
> > On Sat, Jan 07, 2012 at 02:53:46PM -0400, Joey Hess wrote:
> > > But update-catalog can get new switches that handle the transition, and
> > > deb
Adrian Bunk wrote:
> Severity: serious
Inflated. Bug #634741 probably did not affect many packages.
It is up to the indidivual package maintainer to use debhelper
in a way that produces a good package; there are many ways to use
debhelper that produce bad packages, and these are, on the whole,
not
Paul Gevers wrote:
> Hi,
>
> I believe you have reverted the solution to bug #660794. As I was hit by
> this bug #665263 as well, I solved it by changing the line in
> dh_usrlocal from:
> my $ebs = $bs x 2; # Escape the backslash from the shell
> to
> my $ebs = $bs;
binary is now provided by ghc. Besides causing the file conflict
documented in #659081, having libghc-binary-dev still around causes some
other problems. For one, if a package is built against the binary in
ghc, and libghc-binary-dev is installed, ghc sees a conflict and hides
the package that depe
Julien Cristau wrote:
> Hi Marco,
>
> in the regular udev package, 50-udev-default.rules has
> SUBSYSTEM=="input", ENV{ID_INPUT}=="", IMPORT{builtin}="input_id". This
> file (and rule) seem to be missing from the udeb, which breaks the gtk
> image (X doesn't get any input devices).
So, users hav
Helmut Grohne wrote:
> I agree that the complexity should not reside in debhelper templates.
> However that is already the case. The entire code that is responsible
> for #88010 already is contained in debhelper. It is debhelper's prerm
> that removes the package catalog from the root catalog. And
Helmut Grohne wrote:
> * preinst will do the tricky transition part. If it is called during an
>upgrade and /etc/sgml/$package.cat is not owned by any package (this
>is currently the case), then it fixes up the installation. The old
>prerm will have the package catalog removed from the
Julien Cristau wrote:
> rootskel-bootfloppy/ia64 unsatisfiable Depends: klibc-utils-floppy-udeb
> (>= 1.5-2)
This is not a new dependency, it's from 2008 and klibc-utils-floppy-udeb
is not built on ia64.
But why are you trying to use boot floppies, let alone on ia64 anyway?
--
see shy jo
Roger Leigh wrote:
> I think an important point to consider is that /usr would not
> disappear. It could be replaced by a symlink for new installs.
> This would permit older installs to continue to use /usr, but
> the files would end up on / for new installs. So no changes
> to --prefix would be
retitle 617315 policy /usr/local edge case failure
reassign 617315 debian-policy
severity 617315 normal
thanks
Policy requires that creation/removal of directories in /usr/local
never fail, but its example does fail as seen in this bug report.
Apparently the problem is that the chown or chmod coul
Helmut Grohne wrote:
> Good. This would also necessitate a versioned dependency on sgml-base.
Yes, easy since it already uses misc:Depends.
> Do you want a diff for debhelper?
Would be appreciated.
--
see shy jo
signature.asc
Description: Digital signature
Helmut Grohne wrote:
> So what are your thoughts on this?
I haven't considered all the implications... Will the new sgml-base
work ok with the old postinst? With mixtures of the new and old
postinsts?
I'm happy moving ahead with the debhelper changes as soon as sgml-base
is in unstable.
--
see
In other words, this needs to be fixed IMMEDIATELY, since this breaks
*all* installations of Debian testing and unstable.
--
see shy jo
signature.asc
Description: Digital signature
Colin Watson wrote:
> * While it's true that make is largely delegating responsibility to
> another program here, it's a common program used by many packages,
> and so serves to consolidate a lot of boring common code which is a
> fairly standard software virtue. I'd be hard-pressed
There is also a large piece of text about Dirac in another file in
calibre, which ends with "Copyright © Reed Business Information, a
division of Reed Elsevier Inc. All rights reserved."
--
see shy jo
signature.asc
Description: Digital signature
Package: calibre
Severity: serious
While looking in the source for something else, I stumbled upon this:
./recipes/comics_com.recipe:# "Peter is a
stay-at-home Dad [...]
./recipes/comics_com.recipe:# "Silly family antics
and goofball humor
Package: rpm
Version: 4.9.0-5
Severity: serious
This new version of rpm seems broken at building any spec file
I pass to rpmbuild.
error: No file attributes configured
This happens even if the spec file uses %defattr.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
AP
1 - 100 of 639 matches
Mail list logo
