Package: python-ceilometer
Version: 1:7.0.0-1
Severity: important
While trying to setup Ceilometer, I followed (amongst others)
http://docs.openstack.org/developer/ceilometer/install/index.html
This revealed that several files are missing from the package(s):
/usr/lib/python2.7/dist-
Package: openstack-pkg-tools
Version: 53
Severity: normal
Trying to run:
. /usr/share/openstack-pkg-tools/pkgos_func
pkgos_inifile set /etc/keystone/keystone-paste.ini pipeline:public_api \
pipeline "cors sizelimit http_proxy_to_wsgi osprofiler url_normalize
request_id build_auth_conte
Package: ironic-common
Version: 1:6.2.0-1
Severity: important
The file isn't created as it should, which leads to the postinst failing
Setting up ironic-common (1:6.2.0-1) ...
PKG-Openstack now calling: dbc_go ironic-common configure
Couldn't find either auth_host or auth_url :(
This is wh
Package: designate-common
Version: 1:3.0.0-1
Severity: important
- s n i p -
Now doing 'designate-manage database sync': this may take a while...
Option "verbose" from group "DEFAULT" is deprecated for removal. Its value may
be silently ignored in the future.
2016-12-04 20:59:25.853 2821
Package: glance-common
Version: 2:13.0.0-1
Severity: important
- s n i p -
Now doing glance-manage db_sync: this may take a while...
/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py:1171:
OsloDBDeprecationWarning: EngineFacade is deprecated; please use
oslo_db.sqlalche
Package: mistral-common
Version: 3.0.0-1
Severity: important
- s n i p -
Now calling mistral-db-manage upgrade head: this may take a while...
Traceback (most recent call last):
File "/usr/bin/mistral-db-manage", line 10, in
sys.exit(main())
File
"/usr/lib/python2.7/dist-packages/
Package: neutron-common
Version: 2:9.0.0-5
Severity: important
- s n i p -
INFO [alembic.runtime.migration] Context impl SQLiteImpl.
INFO [alembic.runtime.migration] Will assume non-transactional DDL.
Running upgrade for neutron ...
INFO [alembic.runtime.migration] Context impl SQLiteIm
Package: barbican-common
Version: 1:3.0.0~rc1-2
Severity: important
- s n i p -
Now calling barbican-db-manage upgrade: this may take a while...
2016-12-04 20:36:52.340 8574 WARNING barbican.model.migration.commands [-] !!!
Limited support for migration commands using sqlite databases; Th
Package: ironic-common
Version: 1:6.2.0-1
Severity: important
- s n i p -
INFO [alembic.runtime.migration] Context impl SQLiteImpl.
INFO [alembic.runtime.migration] Will assume non-transactional DDL.
INFO [alembic.runtime.migration] Running upgrade -> 2581ebaf0cb2, initial
migration
I
Package: manila-common
Version: 1:3.0.0-1
Severity: important
- s n i p -
2016-12-04 20:26:34.557 7550 INFO alembic.runtime.migration [-] Context impl
SQLiteImpl.
2016-12-04 20:26:34.557 7550 INFO alembic.runtime.migration [-] Will assume
non-transactional DDL.
2016-12-04 20:26:34.567 75
Package: murano-common
Version: 1:3.0.0-1
Severity: important
- s n i p -
Traceback (most recent call last):
File "/usr/bin/murano-db-manage", line 10, in
sys.exit(main())
File "/usr/lib/python2.7/dist-packages/murano/cmd/db_manage.py", line 80, in
main
CONF.command.func(conf
Package: keystone
Version: 2:10.0.0-2
Severity: important
Trying to start over, this time using Stretch (no backports).
When I try to pre-seed keystone, I endup with no database. Running
dpkg-reconfigure keystone
manually to try to figure out if there's something _I_ did, I eventually end up
Package: python-zaqar-ui
Version: 1.0.0.0b2-2
Severity: important
- s n i p -
Selecting previously unselected package python-zaqar-ui.
Preparing to unpack .../5-python-zaqar-ui_1.0.0.0b2-2_all.deb ...
Unpacking python-zaqar-ui (1.0.0.0b2-2) ...
Setting up python-zaqar-ui (1.0.0.0b2-2) ...
On 4 Nov 2016, at 19:29, Thomas Goirand wrote:
> Upstream does *not* support "jumping" version.
Yeah, that I’ve heard as well :(. I personally think that’s a horrible stance,
but there
you go..
> I haven't said we should blame upstream
In a way you do.. “Upstream did that”, “Upstream don’t su
On 3 Nov 2016, at 17:23, Thomas Goirand wrote:
> My priority was to have everything ready on time *AND TESTED* on my CI
I know this is “Unstable” and “shit happens”. I can live with that (I’d prefer
NOT
to, but I rather have a reasonably late version of OS so I had made the
compromise
to run S
On 3 Nov 2016, at 09:03, Thomas Goirand wrote:
> I very much agree with the above, the only issue is enough time to put
> these warning in place. Maybe some text in a NEWS or README.Debian file
> could do the trick. I'm not so fan of adding debconf text for such a
> warning.
You need to TAKE the
On 1 Nov 2016, at 17:42, Debian Bug Tracking System
wrote:
>
> * Remove the neutron-fwaas-l3-agent init script, as this package is
> now just a plugin. Make the neutron-fwaas-l3-agent package a transition
> package.
Ok, so this was done between the "1:9.0.0~b2-1” and "1:9.0.0~rc1-1” which is
Package: neutron-fwaas-common
Version: 1:9.0.0-1
Severity: important
Trying to start neutron-fwaas-l3-agent shows:
+ DAEMON_ARGS=--config-file=/etc/neutron/l3_agent.ini
--config-file=/etc/neutron/fwaas_driver.ini
--config-file=/etc/neutron/neutron.conf
+ [ -x /usr/bin/neutron-fwaas-l3-agent ]
+
Package: cinder-volume
Version: 2:9.0.0-1
Severity: normal
I shutdown all my services to do maintanence on my MySQL cluster and
noticed that I had 'tgtd' running. Trying to remove it, dpkg said that
cinder-volume depends on it.
But I'm already using open-iscsi (which is ALSO running). So the
depe
Package: python-ironic-inspector-client
Version: 1.7.0-2
Severity: minor
When running any 'openstack xxx yyy' command, I'm getting
WARNING: openstackclient.common.utils is deprecated and will be removed after
Jun 2017. Please use osc_lib.utils
Trying to track this done, I see:
# rgrep open
On Oct 13, 2016, at 5:33 PM, Debian Bug Tracking System wrote:
> I suppose that you still have the init script because you touched it at
> some point, so it stayed there, or maybe because of a missing --purge
> option when upgrading.
I was going to write something sarcastically here, because I _
On Oct 13, 2016, at 5:33 PM, Debian Bug Tracking System wrote:
> cp /usr/share/openstack-dashboard/local_settings.py \
> /etc/openstack-dashboard
I can accept that stuff like this should/could be required if I had
upgraded from one version of Openstack to another, but I went
from one versio
Package: python-designate-dashboard
Version: 3.0.0-2
Severity: important
- s n i p -
Setting up openstack-dashboard (3:10.0.0-1) ...
Traceback (most recent call last):
File "/usr/share/openstack-dashboard/manage.py", line 25, in
execute_from_command_line(sys.argv)
File
Package: openstack-dashboard-apache
Version: 3:10.0.0-1
Severity: important
- s n i p -
[...]
Copying
'/usr/lib/python2.7/dist-packages/horizon/static/horizon/lib/jquery/jquery.bootstrap.wizard.js'
Found another file with the destination path
'horizon/lib/jquery/jquery.min.js'. I
Package: keystone
Version: 2:10.0.0-2
Severity: important
# sh -x /etc/init.d/keystone start
[...]
+ [ -x /usr/bin/keystone-all ]
+ exit 0
bladeA01:~# file /usr/bin/keystone-all
/usr/bin/keystone-all: cannot open `/usr/bin/keystone-all' (No such file or
directory)
Not sure what packa
> ZFS relies on mtab which is a broken concept (putting info about mounted file
> systems on a mounted file system).
> The upstream commit "79251738" addresses the situation by relying on
> /proc/self/mounts instead.
On Debian GNU/Linux almost since the "dawn of time", /etc/mtab is a symlink to
On Aug 23, 2016, at 9:07 PM, Ondrej Novy wrote:
> Feel free to add patches to fix this bug if you are considering it
> unacceptable.
If I had enough knowledge in python/django, I would!
But washing your hands and say "fix it yourself if having
a completely broken package in Debian GNU/Linux" i
Please don't leave the package in this horrible, broken state!
You need to package an older version to replace this if you can't
get it to work. Granted, Sid is 'unstable', but that does NOT mean
that it's the same as 'completely broken'. That's what 'testing' is
for!
Waiting weeks (months?) for
Package: neutron-lbaas-agent
Version: 1:8.0.0-3
Severity: important
While trying to get LBaaS v2 to work, I noticed that it can't find the
haproxy.loadbalancer.j2 template.
- s n i p -
==> /var/log/neutron/neutron-lbaasv2-agent.log <==
2016-08-23 16:07:52.273 25229 ERROR neutron_lbaas.age
Package: neutron-lbaas-agent
Version: 1:8.0.0-3
Severity: important
The package is missing the init script for the v2 agent.
I duplicated neutron-lbaas-agent (changing any reference to
"{lbaas|LBaaS}" to "lbaasv2|LBaaS v2}" (etc) init script and
got it working.
-- System Information:
Debian Rele
Package: python-zaqar-ui
Version: 1.0.0.0b2-2
Severity: important
After installing python-zaqar-ui and going to /project/queues in Horizion,
the page/frame is empty/blank.
Looking at the apache logs, I see:
- - [20/Aug/2016:17:30:09 +0200] "GET
/static//dashboard/project/queues/table/queue
On Aug 16, 2016, at 8:22 PM, Ondrej Novy wrote:
> I can't reproduce your problem. Maybe you can try --no-install-recommends
> option for apt-get?
I found it quite easy to duplicate:
# debootstrap jessie /mnt/jessie
# chroot /mnt/jessie /bin/bash
# echo "deb http://http.debian.net/debian
Package: python-designateclient
Version: 2.1.0-2
Severity: normal
The following NEW packages will be installed:
binutils build-essential cpp cpp-4.9 dpkg-dev fakeroot g++ g++-4.9
gcc gcc-4.9 gir1.2-glib-2.0 ieee-data libalgorithm-diff-perl
libalgorithm-diff-xs-perl libalgorithm-merge-perl li
Mugsie (Graham Hayes) on IRC said that he abandoned the
patch because the Neutron team required a unit test for
this and he had no time to write one at this time..
no. its fine, it is a neutron reviewr going
overboard as per usual
so I still think it's worth adding to avoid problems.
Package: nova-api
Version: 2:13.1.0-2
Severity: important
This bug is reported at:
https://bugs.launchpad.net/nova/+bug/1604428
and includes a backported fix to Mitaka:
https://review.openstack.org/#/c/344371/
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT
Package: python-neutron
Version: 2:8.1.2-1
Severity: important
While installing Designate (DNSaaS), I stumbled on an
issue with Neutron.
Original issue:
https://bugs.launchpad.net/neutron/+bug/1605336
Neutron loadbalancer VIP port fails to create
Original fix:
https://review.openstack.o
Looking at the source package, the file(s) is indeed
there:
root@sid64:/usr/local/src/Openstack/manila-ui-2.1.0# find -name index.html
./manila_ui/dashboards/project/shares/templates/shares/index.html
./manila_ui/dashboards/admin/shares/templates/shares/index.html
However, both of the "templates"
A quick hack to get it working was to change the
/usr/lib/python2.7/dist-packages/designatedashboard/__init__.py
as mentioned in the PKG-INF file:
--- /usr/lib/python2.7/dist-packages/designatedashboard/__init__.py~
2016-04-07 21:38:14.0 +0100
+++ /usr/lib/python2.7/dist-packages
Package: python-manila-ui
Version: 2.1.0-1
Severity: important
==> /var/log/apache2/error.log <==
[Thu Jul 21 21:58:57.246123 2016] [wsgi:error] [pid 18459:tid 140503228061440]
Internal Server Error: /project/shares/
[Thu Jul 21 21:58:57.246144 2016] [wsgi:error] [pid 18459:tid 140503228061440]
Package: python-designate-dashboard
Version: 2.0.0-1
Severity: important
==> /var/log/apache2/error.log <==
[Thu Jul 21 20:55:57.875685 2016] [wsgi:error] [pid 14895:tid 140671901120256]
[client 10.0.0.254:53457] mod_wsgi (pid=14895): Target WSGI script
'/usr/share/openstack-dashboard/openstack_
Package: heat-common
Version: 1:6.0.0-2
Severity: important
The heat.conf file is missing the following options:
[DEFAULT]/heat_metadata_server_url
[DEFAULT]/heat_waitcondition_server_url
See point 10 at
http://docs.openstack.org/icehouse/install-guide/install/yum/content/heat-install.html
Package: heat-api-cfn
Version: 1:6.0.0-2
Severity: important
The service and endpoints needs to be setup for Heat to work
correctly.
- s n i p -
REGION_NAME=""
SERVICE_NAME="heat-cfn"
SERVICE_DESC="Orchestration CloudFormation"
SERVICE_TYPE="cloudformation"
PKG_ENDPOINT_IP=""
SERVICE_PORT
A "quick and dirty" fix for this is:
---
/usr/lib/python2.7/dist-packages/trove/guestagent/datastore/mysql_common/service.py.orig
2016-07-20 15:54:23.229714410 +0100
+++
/usr/lib/python2.7/dist-packages/trove/guestagent/datastore/mysql_common/service.py
2016-07-20 15:54:33.965714398
Package: trove-common
Version: 1:5.0.1-1
Severity: normal
Looking at trove-taskmanager.conf and then comparing that with the Python
file reading this
/usr/lib/python2.7/dist-packages/trove/common/cfg.py
there's many options missing, making it difficult to use something like
pkgos_inifile()
Package: neutron-common
Version: 2:8.1.2-1
Severity: wishlist
Getting Neutron and Designate to talk to each other is "fairly" simple.
But it would be nice to have a dummy section in place:
- s n i p -
# http://docs.openstack.org/mitaka/networking-guide/adv-config-dns.html
[designate]
url
Package: designate-common
Version: 1:2.0.0-2
Severity: important
With the help of 'mugsie' and 'mlavalle' on '#openstack-designate',
we found that there is a bug in the designate.conf file.
https://bugs.launchpad.net/designate/+bug/1604043
https://review.openstack.org/343727
* v2 is disabled by
On Jul 17, 2016, at 12:28 PM, Turbo Fredriksson wrote:
> However, even after adding those parts, it still won't work, so there
> might be even more things missing..
Finally, after adding the following I got it to work:
- s n i p -
[keystone_authtoken]
[etc]
username = senl
Package: senlin-common
Version: 1.0.0-2
Severity: important
Trying to get Senlin to work on Sid/Unstable, I'm getting
errors:
Expecting to find id or name in user - the server could not comply
with the request since it is either malformed or otherwise incorrect.
The client is assumed to be
Package: neutron-server
Version: 2:8.1.2-1
Severity: important
There is no init/systemd service file to start/stop/restart the
Metadata agent provided.
Cloning the "neutron-dhcp-agent.service" and "neutron-dhcp-agent"
init file worked fine..
Also, it's missing a template /etc/neutron/metadata_a
# sh -x /etc/init.d/neutron-vpnaas-agent start
[..]
+ DAEMON_ARGS=--config-file=/etc/neutron/vpnaas_agent.ini
--config-file=/etc/neutron/neutron_vpnaas.conf
--config-file=/etc/neutron/neutron.conf
+ [ -x /usr/bin/neutron-vpnaas-agent ]
+ exit 0
# file /usr/bin/neutron-vpnaas-agent
/usr/bin/neutro
On Jul 5, 2016, at 9:30 AM, Thomas Goirand wrote:
> dbconfig-common is *the* tool that packages are supposed to use to
> configure database. In what way is this irrelevant?
* Because it can't handle MongoDBs? And yet the script(s) call
it to setup the mongodb.
* Because the package(s) don't de
On Jul 4, 2016, at 3:27 PM, Thomas Goirand wrote:
> What I'm saying is that the lack of feature (ie: support for mongodb) is
> in dbconfig-common. dbconfig-common doesn't support mongodb.
Why do we need this dbconfig-common?? That is completely irrelevant.
The problem is that ceilometer.conf com
On Jul 4, 2016, at 9:39 AM, Debian Bug Tracking System wrote:
> if you prefer to
> type it yourself, then simply answer no to the ceilometer/configure_db
> debconf template, it's there for that.
Are you saying that it's to much to ask for for ceilometer-common to work
the same way as all the othe
On Jul 3, 2016, at 10:05 PM, Turbo Fredriksson wrote:
> Thanx! While you're at it, do the same for the other
> services as well.
Sorry, just took a look at the patch and I see you did.
Thanx.
--
Try not. Do. Or do not. There is no try!
- Yoda
On Jul 3, 2016, at 10:01 PM, Ondrej Novy wrote:
> you are right, sorry I misunderstood you. Fixed in git.
Thanx! While you're at it, do the same for the other
services as well.
--
I love deadlines. I love the whooshing noise they
make as they go by.
- Douglas Adams
On Jul 3, 2016, at 8:34 PM, Ondrej Novy wrote:
> that's not a bug. You need to correctly create a distribute ring file.
I still consider it a bug. The service(s) should refuse to
start if these files don't exist.
I'm so "spoiled" with Debian GNU/Linux services "just works"
out of the box and I
Package: ceilometer-common
Version: 1:6.0.0-2
Severity: normal
The default ceilometer.conf comes with the setting
connection=mongodb://localhost:27017/ceilometer
which means that the installation will hang on installation
if installing on a host which don't run MongoDB (I have that
on my DB/
Package: swift-account
Version: 2.7.0-6
Severity: important
When starting swift-account-replicator, I get Subj in the
syslog.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w
Package: trove-guestagent
Version: 1:5.0.1-1
Severity: important
I'm trying to get the trove guest agent to work, but
the first problem I got was that there (apparently)
is a config option missing:
[DEFAULT]
datastore_manager = mysql
However, that is only the beginning of the problem.
Enabl
On Jun 29, 2016, at 8:48 PM, Thomas Goirand wrote:
>http://git.debian.org/?p=openstack/keystone.git;a=commitdiff;h=cc00c49
Unfortunately, that patch itself isn't enough!
It won't work with a default, unchanged, configuration variable.
Did you have a problem with my fix?
Package: keystone
Version: 2:9.0.2-1
Severity: minor
The code say
grep -E '^[ \t]*provider[ \t]*=' /etc/keystone/keystone.conf
but if 'provider' is commented out (as in, "use default value")
#provider = uuid
then this will match nothing, not run the token_flush and the
script will exit
Package: ironic-common
Version: 1:5.1.2-1
Severity: important
I had to add the following to the [keystone_authtoken] section
to get Ironic to "boot up" (or at least have it respond to queries):
auth_host=
auth_protocol=http
admin_user=
admin_password=
admin_tenant_name=
au
Package: neutron-vpnaas-agent
Version: 1:8.0.0-1
Severity: important
The init script "/etc/init.d/neutron-vpnaas-agent" references the
daemon/binary "/usr/bin/neutron-vpnaas-agent", but it is not included
in the package.
It also tries to start the service as:
/usr/bin/neutron-vpnaas-agent \
Package: neutron-vpnaas-agent
Version: 1:8.0.0-1
Severity: important
The python-neutron-vpnaas package contain the actual code that
neutron-vpnaas-agent uses..
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
K
Package: neutron-lbaas-agent
Version: 1:8.0.0-1
Severity: important
The python-neutron-lbaas package contain the actual code that
neutron-lbaas-agent
uses..
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Ker
Package: trove-common
Version: 1:5.0.0-2
Severity: important
Trying to install Trove on Sid give this error:
- s n i p -
[...]
2016-06-20 12:48:10.686 19719 INFO migrate.versioning.api [-] 17 -> 18...
2016-06-20 12:48:10.741 19719 INFO migrate.versioning.api [-] done
2016-06-20 12:48:10.7
Package: neutron-server
Version: 2:8.0.0-2
Severity: important
Even though "europe-london" was specified, I still end up with "regionOne" in
the
config file.
- s n i p -
bladeA01b:~# grep regionOne /etc/neutron/neutron.conf
region_name = regionOne
bladeA01b:~# debconf-get-selections | eg
Package: openstack-pkg-tools
Version: 50
Severity: minor
Sourcing /usr/share/openstack-pkg-tools/pkgos_func in the shell and then
trying to use the "get" part of it does not work:
- s n i p -
bladeA01b:~# . /usr/share/openstack-pkg-tools/pkgos_func
bladeA01b:~# export PKGOS_VERBOSE=yes
bl
Package: nova-api
Version: 2:13.0.0-3
Severity: normal
I've now reproduced this problem several times. For some reason I get
"You have an error in your SQL syntax" when installing nova-api.
I have tracked this down to the dash in the "nova-api" user- and
database names. Removing this and calling
Package: nova-common
Version: 2:13.0.0-3
Severity: minor
- s n i p -
# Directory where the nova python module is installed (string value)
#pybasedir =
/home/zigo/sources/openstack/mitaka/nova/build-area/nova-13.0.0/debian/tmp/usr/lib/python2.7/dist-packages
- s n i p -
Granted, i
On Jun 11, 2016, at 7:54 AM, Petter Reinholdtsen wrote:
> Hm, wonder where those went. The Wheezy packages from ZoL had init.d
> scripts, at least. I guess we can dig them out from there. Are the
> kFreeBSD packages using init.d scripts? Perhaps we can reuse those?
See ./etc/init.d in the ZFS
Package: wiki.debian.org
Severity: important
The page https://wiki.debian.org/PXEBootInstall talks about
providing the netboot image, unpacking it and then "should now
contain" and there is pxelinux.* files!
It does not say where these files come from (links from the
looks of it).
The
http://ft
Package: mistral-api
Version: 2.0.0-2
Severity: normal
I got the following when installing mistral-api:
- s n i p -
dpkg: error processing package mistral-api (--configure):
subprocess installed post-installation script returned error exit status 10
Errors were encountered while processi
On Jun 6, 2016, at 12:15 AM, Debian Bug Tracking System wrote:
> Therefore, closing the bug. If you want to contribute such a fix, I
> welcome you to do so, but IMO, we have much more important things to do.
The "fix" is to _ALWAYS_ put variables in situation marks!
This is considered to be "good
On Jun 6, 2016, at 12:15 AM, Debian Bug Tracking System wrote:
>> The problem might also exist somewhere in dbconfig.. :(
>
> Exactly, which makes it pointless to fix in the OpenStack packages.
I did say "also"..
Package: ironic-common
Version: 1:5.1.0-2
Severity: normal
The config/postinst does as for a RabbitMQ user (defaults to 'guest'),
but if other user specified, this is not created.
-- System Information:
Debian Release: stretch/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates')
Package: keystone
Version: 2:9.0.0-2
Severity: normal
===> Registering keystone endpoint
unmatched '{' in format
Warning - data is empty
Setting-up: create-keystone-service unmatched '{' in format
dpkg: error processing package keystone (--configure):
subprocess installed post-installation script
Package: barbican-common
Version: 1:2.0.0-5
Severity: normal
The /var/lib/dpkg/info/barbican-common.config file contains the
following snippet:
- s n i p -
MYSQL_P_TMP=`mktemp -t OpenStack-mysql-statement.XX`
MYSQL_Q_TMP=`mktemp -t OpenStack-mysql-statement.XXX
On May 12, 2016, at 10:40 PM, Petter Reinholdtsen wrote:
> As zfs-linux finally entered unstable yesterday, I guess it is
> time to look at this issue again.
I'm pretty sure it's fixed in one of my PRs that haven't been
accepted. I've seen this issue on the ZoL trackers, but I can't
remember if w
fully
accepted into the FTP archives.
A third, highly theoretical solution, might be to offer downloadable
kernel modules outside the Debian GNU/Linux distribution, much like
many graphical drivers etc (adobe reader is one such I think) is
provided.
--
Turbo Fredriksson
tu...@bayour.com
On Apr 20, 2015, at 9:26 AM, Philip Hands wrote:
> Turbo Fredriksson writes:
>>
>> Good for you. Maybe it's better now, but my opinion still stands.
>
> Well, that's a jolly constructive attitude, well done.
Not how I meant it, but thanx for misunderstanding
On Apr 19, 2015, at 10:48 PM, Paul van der Vlis wrote:
> Backports main is official Debian. [1]
You misunderstand the announcement.
… official Debian service …
Notice the last word here! It say "service". Not 'official _PART_ of Debian'!
--
Life sucks and then you die
--
To UNSUBSCRIB
On Apr 20, 2015, at 7:01 AM, Christian PERRIER wrote:
> I really don't think this is a good idea and I'm this close to
> re-close the bug report.
Well, I asked a fair question I think. I knew the answer (but I could
be wrong - I haven't been paying attention to Debian GNU/Linux matters
in years)
On Apr 19, 2015, at 9:48 PM, Paul van der Vlis wrote:
> Did you check if it really was back ports?
Yes. I've been using Debian GNU/Linux since.. 'bo' or something and a DD since
'97 or so. I know what I'm doing (98% of the time :).
> I use backports on all machines I care about, and I never had
On Apr 19, 2015, at 8:25 PM, Geert Stappers wrote:
> What is the danger of having backports (default) enabled?
From what I've seen (when I tried it a couple of years ago), is that
the back porting is quite … "sloppy". If the package needs a newer lib,
that is back ported as well. And the newer li
On Apr 19, 2015, at 7:15 PM, Cyril Brulebois wrote:
> Paul van der Vlis (2015-04-19):
>
>> Are all machines with backports enabled ticking timebombs?
>> No, but you have to know what you do.
>
> Do you see that “but”? That's exactly why it's not safe to have this
> turned on by default.
Thank
On Aug 8, 2014, at 1:29 AM, Andreas Cadhalpun wrote:
> For this task I obtained the sources from
> https://github.com/zfsonlinux/pkg-spl, branch master/ubuntu/precise, which
> seems to contain the most recent changes.
That is the code for the SPL (Solaris Porting Layer) that ZFS/ZoL depends on.
On Aug 3, 2014, at 2:38 PM, Ritesh Raj Sarraf wrote:
> Why ?? It should work. Your previous bug report was about swap devices
> not being handled. With its inclusion, why will it not work ?
1. Because there's no fsck before mounting the filesystem.
That's really ugly, and potentially dangero
On Aug 3, 2014, at 10:16 AM, Ritesh Raj Sarraf wrote:
> I will soon, for the next upload, revert these changes, and move back to the
> old solution of (mount -a + swapon -a). Is that okay with you guys ???
Not to me, not really! Your previous way didn't work at all for me, this works
for everyo
On Aug 2, 2014, at 10:56 PM, Torben Frey wrote:
> Working perfectly for me now.
> Thanks for the quick fix and patch!
Sounds good and you're most welcome! Ritesh, mind applying it to the next
package
version?
Btw, you can close https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688209,
because t
How about this change? Torben, could you test?
I choose to use your 'temporary file' solution. Seemed simplest.
open-iscsi.init.diff
Description: Binary data
On Aug 2, 2014, at 3:58 PM, Torben Frey wrote:
> And I guess functionality is good after removing the “break” command.
I just tested this with multiple _netdev entries, and they all work!
So I couldn't reproduce this problem.
> I just don’t exactly know how the MOUNT_RESULT could summarize the r
On Jun 2, 2014, at 3:37 PM, Steven Chamberlain wrote:
> With such an overlap implied by that, and knowing it all originated from
> a common codebase at some time, I really hope it can be merged back into
> a common package built for kfreebsd-any and linux-any.
That's what Open-ZFS.org is all abou
n 02/03/2014 03:52, Dimitri John Ledkov wrote:
>> Also, if there is zfs-dkms module available, why existing zfsutils
>> packages just can't enable compilation on "linux-any"?! Which should
>> also reduce the scope of linux specific packages down to
>> -dkms/-in
On Mar 2, 2014, at 6:56 AM, Turbo Fredriksson wrote:
> On Mar 2, 2014, at 4:52 AM, Dimitri John Ledkov wrote:
>
>> Since these are two different implementations
>
> You said it yourself - they are different implementations.
Actually, this is not quite true either come to th
On Mar 2, 2014, at 4:52 AM, Dimitri John Ledkov wrote:
> Hostile binary takeover is not allowed - that is two separate source
> packages should not build the same binary package names, even if on
> different architectures.
Ok, sounds reasonable when you say it like that. I'd still appreciate a li
On Mar 1, 2014, at 2:25 PM, Robert Millan wrote:
> I already explained. Nobody listens... (sigh)
All I've seen is that you "think" that it "might" be a problem and that we
"might" be better of renaming it...
Please give us/me a direct link to the Debian GNU/Linux policy point that
explain tha
On Feb 28, 2014, at 5:23 PM, John Paul Adrian Glaubitz wrote:
> I suggest asking the FTP masters to mark the package as REJECT if you
> want to change something again.
Well, regarding the packaging, a lot have happened since this summer. And this
is also true with the
code itself.
But doing a R
On Feb 28, 2014, at 1:29 PM, Robert Millan wrote:
> The proposed package is poorly integrated with existing ZFS packages (e.g.
> zfsutils for native
> kFreeBSD support).
>
> First and foremost, there's a namespace grab which is likely to result in
> trouble, as I explained
> last November (and
On Feb 28, 2014, at 11:34 AM, Turbo Fredriksson wrote:
>> Where is the latest/greatest set of packaging repositories and/or packages
>> to look at?
>
> For Debian GNU/Linux Wheezy, this would be
>
>
> https://github.com/zfsonlinux/pkg-zfs/tree
1 - 100 of 170 matches
Mail list logo
