Re: Restore Reviewboard, Disaster happened.

['Eric Johnson' via Review Board Community]

I'm not a developer for the tool, but I've poked around on the innards 
enough to take some stabs at guesses.


On Tuesday, January 14, 2020 at 5:21:34 PM UTC-8, Danila Ladner wrote:
>
> Hello guys i am in need of RB help.
> I have lost my reviewboard installation, i only have mysql backup of it 
> but no site files which were on separate disk and which by accident wasn't 
> included in backup schedule and died.
>

The site files can be regenerated - *except* for the attachments that users 
might have added to reviews. You can see what you might be missing with the 
"attachments_fileattachment" in MySQL.
 

> I think my RB version was 3.1 or 3.2 but not sure ( is there a way to find 
> it from mysql)?
>

Certainly not 3.1 or 3.2, since no such release exists 
yet: https://downloads.reviewboard.org/releases/ReviewBoard/ 

The django_evolutions table in the database lists the evolutions that have 
been applied to the database. So if you've done multiple upgrades, the last 
upgrade you did is implied by the last evolution listed in this table. If 
you grab the source, you can search inside the source for the .py file 
matching the name of the evolution. If you find it, then go to the source 
 and see which release first 
has the file - that's your release.
 

> I do have old site files though 2 years ago, when version was 2.5.1 but 
> since was upgraded multiple times.
>

You probably want to use that, just to get access to attached files.
 

> But i do have access to the  SECRET_KEY setting in conf/settings_local.py
>

Turns out the SECRET_KEY is used to encrypt passwords, both for connecting 
to version control systems, and for local user accounts. If you lose the 
SECRET_KEY, you can still restore your system by resetting all the 
passwords.


> Do i have any chance of restoring this?
>

Seems like, yes, except for attachments.
 

> Thank you in advance, really in big trouble for this.
>

Regular system backups should be part of any IT operation.


-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/reviewboard/2109d4ee-5ea8-4bab-9b62-8e2b79905b37%40googlegroups.com.

Weird authentication issue - username + password not working with RBT

['Eric Johnson' via Review Board Community]

I'm not even sure where / how to troubleshoot this issue.

I've got clients of the server that I'm managing that have no problem
accessing the ReviewBoard website with a standard username and password
login.

(Note, as it may be relevant to understanding / diagnosing the issue:

   - I server multiple instances of ReviewBoard from the same server - each
   gets a separate database - but they are all sharing the same memcached
   instance.
   - I've got a custom authentication handler, as I need to be able to
   authenticate against two possible LDAP servers.

)

Weirdly, for some users, for some ReviewBoard instances (but not all of
them), the "rbt" tool now no longer works with username + password for
authentication.

So far, users have been able to get back to work using API tokens for
authentication instead. The question remains, though:

Why is it that only some users can no longer use "rbt" with username +
password authentication, but the same username + password works when
logging into the website directly?

Any suggestions for how to troubleshoot this / reproduce the problem?

Eric.

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/reviewboard/CANu9%3DNdH0pjv8g6RT0-SZ_vBtkjwwbB-fqLn74JFs_HPRT%3D-Sg%40mail.gmail.com.

Re: Review Board Integration With GitLab

['Eric Johnson' via Review Board Community]

Did you upgrade ReviewBoard? To what version did you upgrade?

I'm struggling with a GitLab problem right now, and certainly got past what 
you describe when using ReviewBoard 3.0.14.

Eric

On Monday, May 13, 2019 at 12:51:03 AM UTC-7, Akshay Agarwal wrote:
>
> Can someone help?
>
> On Friday, May 10, 2019 at 4:28:34 PM UTC+5:30, Akshay Agarwal wrote:
>>
>> We have decided to proceed by upgrading the Review Board. The error I am 
>> getting while setting up the Gitlab repo is as follows: 
>>
>> Unexpected error when linking the account: Could not determine the GitLab 
>> API version for https://10.106.165.254 due to an unexpected error 
>> (> target machine actively refused it>). Check to make sure the URL can be 
>> resolved from this server and that any SSL certificates are valid and 
>> trusted. Additional details may be found in the Review Board log file.
>>
>> Same can be seen in the image shared.
>> On Saturday, May 4, 2019 at 2:00:09 AM UTC+5:30, Christian Hammond wrote:
>>>
>>> Cgit and Gitweb are alternatives to using a service like GitLab. You can 
>>> use those with a self-hosted, raw git repository, which we discussed at 
>>> length in the other thread. But you have to understand, your choices are 
>>> limited to the options we are able to support with the version of Review 
>>> Board you are using. We can't just make an old version of Review Board 
>>> suddenly work with an API that was created after it was released, and we 
>>> can't make the Git protocol better.
>>>
>>> We also can't indefinitely support vastly older versions of Review Board 
>>> for free. We do offer support contracts and custom development contracts 
>>> for specific needs, but you'd have to be willing to pay, and I know that 
>>> that was an issue when we discussed licensing for Power Pack.
>>>
>>> Using older technology forever doesn't work. You're at the stage now 
>>> where you'll have to decide whether to change how you're hosting the Git 
>>> repositories, or upgrade Review Board. We've tried to make upgrading easy, 
>>> so long as your OS isn't too old, but if you go that route, back up 
>>> *everything* and test an upgrade on a clone of your server before you 
>>> proceed, as we won't be able to help fix a broken database upgrade without 
>>> a contract.
>>>
>>> Christian
>>>
>>>
>>> On Fri, May 3, 2019 at 3:07 AM Akshay Agarwal  
>>> wrote:
>>>
 So Review Board 2.0.21 is not compatible with Gitlab even after using 
 Cgit or Gitweb. You also said it will not work with Bitbucket either. You 
 need to understand that Review Board is being used for a corporate product 
 here and it is not that easy to just upgrade as there are many 
 dependencies 
 that come along with it. Is there any method you can suggest that will 
 successfully allow me to use the Review Board with a Git repository? 

 On Friday, May 3, 2019 at 2:53:13 PM UTC+5:30, Christian Hammond wrote:
>
> 2.0.21 is 4 years old, and GitLab no longer fully supports the version 
> of the API that Review Board 2.0.21 was compatible with. We also don't 
> provide any support for Review Board 2.0.x, so you'll need to upgrade to 
> the 3.0.x series if you want to use GitLab.
>
> Christian
>
> On Fri, May 3, 2019 at 1:05 AM Akshay Agarwal  
> wrote:
>
>> Since there is an option to add the Gilab repo in version 2.0.21, 
>> there must be another way to communicate with Gitlab right?
>>
>> On Friday, May 3, 2019 at 1:11:20 PM UTC+5:30, Akshay Agarwal wrote:
>>>
>>> Could I use Cgit or Gitweb between gitlab and reviewboard?
>>>
>>> On Fri, 3 May 2019 at 12:36 PM Christian Hammond <
>>> chri...@beanbaginc.com> wrote:
>>>
 Ah, that explains it. 2.0.x is now a few generations behind and no 
 longer supported by us in any form. The 2.5.x series followed, and 
 3.0.x is 
 the current and supported release. You'll need 3.0.x for GitLab 
 support, as 
 it's the only generation that supports the modern GitLab API.

 Christian

 On Fri, May 3, 2019 at 12:04 AM Akshay Agarwal  
 wrote:

> Version 2.0.21
>
> On Fri, 3 May 2019 at 12:28 PM Christian Hammond <
> chri...@beanbaginc.com> wrote:
>
>> What version of Review Board are you running?
>>
>> Christian
>>
>> On Thu, May 2, 2019 at 10:06 PM Akshay Agarwal <
>> aksha...@gmail.com> wrote:
>>
>>> While the Review Board documentation shows an option to add an 
>>> api token for Gitlab, there is no such option to do so in the 
>>> Review Board. 
>>> It only asks url, username and the password. The error being shown 
>>> is 
>>> "error when linking the account: HTTP Error 410"  The same has been 
>>> shown 
>>> in the file attached.
>>>
>>>

Re: site-upgrade from 1.7.14 to 2.0.20 fails

['Eric Johnson' via Review Board Community]

On Monday, June 3, 2019 at 7:58:29 AM UTC-7, Martin Großhauser wrote:
>
> Thanks for your reply.
>
> Indeed, there was version 1.7.27 from EPEL installed. But the version 
> running according to the web interface was 1.7.14. Also in the SQL-table 
> siteconfig_siteconfiguration I see a string '1.7.14', which looks to me 
> like the version. Uninstalling the RPM version and reinstalling 2.0.20 via 
> easy_install with an rb-site upgrade afterwards did not resolve my issue.
>
> Maybe there is a version conflict in the current setup?
>
> I did not maintain this setup in the past, so I do not know much about 
> what happened before. Internal documentation shows there was at least an 
> unfinished upgrade to 1.7.27 with an inconsistent state in between. Version 
> was rolled back to 1.7.14 then, but maybe some artifacts remained, which 
> are causing the current trouble.
>

Oh, this is a critical detail. There are two paths that I can think of here.

Path 1) Install a fresh copy of your current installed version (1.7.14) 
into a fresh database, and compare that database schema to the one for your 
production install. If they differ, repeat the exercise with 1.7.27, and 
see how that differs. It may be that you've got most of the changes for 
1.7.27, but for a few, and might be able to apply those.

At one point in the distant past of our ReviewBoard use (1.X), I did run 
into problems with a mismatch between the database layout and the version 
of ReviewBoard. It had to do with a similar situation - an aborted upgrade. 
I thought I had rolled back. In the end, I had to manually bring the 
database forward to the expected version. Once I did that, I haven't had 
problems since. However, I've been a die-hard developer for a long time, 
this path might not be for you. Digging into SQL, and pouring over the 
Python code of RB didn't deter me (it is pretty good code, as open source 
goes. It is almost like each commit gets reviewed ;-) ).

Path 2) ReviewBoard is a great tool, and BeanBag deserves $$ for the work 
they do making it. Perhaps pay for support from the company help untangle 
the issue you've got? It may save you a lot of time, and be worth every 
dollar spent.

Eric.

 

>
> Am Montag, 3. Juni 2019 15:28:47 UTC+2 schrieb Stephen Gallagher:
>>
>> On Mon, Jun 3, 2019 at 9:25 AM Martin Großhauser 
>>  wrote: 
>> > 
>> > I'm trying to upgrade ReviewBoard to 2.0.20, but site-upgrade fails 
>> with output: 
>> > 
>> > # rb-site upgrade /var/www/reviewboard 
>> > Rebuilding directory structure 
>> > Updating database. This may take a while. 
>> > 
>> > The log output below, including warnings and errors, 
>> > can be ignored unless upgrade fails. 
>> > 
>> > --  -- 
>> > Creating tables ... 
>> > Upgrading Review Board from 1.7.14 to 2.0.20 
>> > There are unapplied evolutions for auth. 
>> > There are unapplied evolutions for contenttypes. 
>> > There are unapplied evolutions for accounts. 
>> > There are unapplied evolutions for attachments. 
>> > There are unapplied evolutions for changedescs. 
>> > There are unapplied evolutions for diffviewer. 
>> > There are unapplied evolutions for hostingsvcs. 
>> > There are unapplied evolutions for reviews. 
>> > There are unapplied evolutions for scmtools. 
>> > There are unapplied evolutions for site. 
>> > Project signature has changed - an evolution is required 
>> > Installing custom SQL ... 
>> > Installing indexes ... 
>> > Installed 0 object(s) from 0 fixture(s) 
>> > The stored evolutions do not completely resolve all model changes. 
>> > 
>> > Run `./manage.py evolve --hint` to see a suggestion for the changes 
>> required. 
>> > 
>> > The following are the changes that could not be resolved: 
>> > The application markup has been deleted 
>> > In model attachments.FileAttachment: 
>> > In field 'file': 
>> > Property 'max_length' has changed 
>> > In model hostingsvcs.HostingServiceAccount: 
>> > Field 'hosting_url' has been added 
>> > The model auth.Message has been deleted 
>> > In model reviews.FileAttachmentComment: 
>> > Field 'extra_data' has been added 
>> > In model reviews.ReviewRequest: 
>> > Field 'depends_on' has been added 
>> > In model reviews.ReviewRequestDraft: 
>> > Field 'depends_on' has been added 
>> > In model accounts.Profile: 
>> > Field 'timezone' has been added 
>> > Field 'open_an_issue' has been added 
>> > Field 'extra_data' has been added 
>> > In model diffviewer.DiffSet: 
>> > Field 'base_commit_id' has been added 
>> > In model diffviewer.DiffSetHistory: 
>> > Field 'last_diff_updated' has been added 
>> > In model diffviewer.FileDiff: 
>> > Field 'diff_hash' has been added 
>> > Field 'parent_diff_hash' has been added 
>> > Field 'diff64' has been added 
>> > Field 'parent_diff64' has been added 
>> > Field 'parent_diff' has been deleted 
>> > Field 'diff' has been deleted 
>> > CommandError: Your models contain changes 

Re: In search of help packaging ReviewBoard 3.0.14 for Gentoo Linux, problem when running server, probably something simple I overlooked.

['Eric Johnson' via Review Board Community]

Hi Stephen,

On Tue, Jun 4, 2019 at 1:12 PM Stephen Gallagher 
wrote:

> On Tue, Jun 4, 2019 at 1:31 PM 'Eric Johnson' via Review Board
> Community  wrote:
> > The one challenge I observed with the ReviewBoard packages was that
> rbintegrations included a small handfule of binary files that I needed to
> copy over and add to the unpacked source.
> >
> > As for why my changes were not working when I wrote you initially, it
> appears that I forgot to reset my virtual machine for testing purposes, and
> was instead dealing with incremental changes, and it didn't work. When I
> reset my VM, and applied the upgrade to the Gentoo packages on a "clean"
> install of the 2.5.18 version, the end-result worked just fine.
> >
> > Thanks for your help. Your questions prodded me to keep looking, to make
> sure I could properly describe the problem, and that got me to find my
> mistake.
> >
>
> For what it's worth, you might find my Fedora packaging to be useful
> in guiding you here. Realistically, you probably want to do what I did
> and just bundle the rbintegrations tarball with the ReviewBoard build.
>
> The Fedora packaging is here:
> https://src.fedoraproject.org/rpms/ReviewBoard/tree/3.0


I almost had to go down that path. Fortunately, I was able to keep them
separate. They have an oddly cyclical relationship. As near as I can tell,
in the source, each depends on the existence of the other in setup.py .
Fortunately, when packaging for Gentoo, I simply removed all the setup
activities (making it equivalent to the whl files), which breaks the
dependency cycle.

Eric.

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/reviewboard/CANu9%3DNc-dqF66agep9dQgsqG3RH%3DYttkutKjwd6tnYPfXE_PRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: In search of help packaging ReviewBoard 3.0.14 for Gentoo Linux, problem when running server, probably something simple I overlooked.

['Eric Johnson' via Review Board Community]

Hi Christian,

Thanks so much for the response! As near as I can tell, ReviewBoard "just 
works" for the teams that use it here, so we're grateful for the quality 
work.

The issue appears to be solved at this point, and it looks like operator 
error. More details below.

On Friday, May 31, 2019 at 12:58:31 AM UTC-7, Christian Hammond wrote:
>
> Hi Eric,
>
> Can you verify that rbintegrations was also packaged and that its 
> extension is enabled?
>

> We really don't advise installing from our tarballs, as we build the eggs 
> and wheels with a particular setup to ensure they're packaged just right. 
> It is of course possible to build with tarballs, but there are differences. 
> The process of building eggs/wheels can result in changes to the required 
> dependencies and to some of the build steps. It'd be best if the "source" 
> could be the wheel, just extracted.
>

Unfortunately, I don't see that installing from the "whl" files or the 
"egg" files is really used at all on Gentoo. It is fairly straightforward 
to make sure I get the dependencies right, since I had to encode the 
dependencies into the Gentoo package ebuild files. As for getting the files 
right, a recursive compare of the pip install vs. the Gentoo install shows 
that they end up the same with the packages I created.

The one challenge I observed with the ReviewBoard packages was that 
rbintegrations included a small handfule of binary files that I needed to 
copy over and add to the unpacked source.

As for why my changes were not working when I wrote you initially, it 
appears that I forgot to reset my virtual machine for testing purposes, and 
was instead dealing with incremental changes, and it didn't work. When I 
reset my VM, and applied the upgrade to the Gentoo packages on a "clean" 
install of the 2.5.18 version, the end-result worked just fine.

Thanks for your help. Your questions prodded me to keep looking, to make 
sure I could properly describe the problem, and that got me to find my 
mistake.

Eric.

 

>
> Christian
>
> On Thu, May 30, 2019 at 2:52 PM 'Eric Johnson' via Review Board Community <
> revie...@googlegroups.com > wrote:
>
>> Mostly, I've managed to get quite far with packaging ReviewBoard for 
>> Linux. Although I don't know much about the Gentoo packaging system, it has 
>> turned out to be easier than I feared.
>>
>> We're currently running ReviewBoard 2.5.18, installed using the portage 
>> package manager. So we have done this packaging for 2.5.18. I tried this 
>> upgrade previously, but was stymied and gave up. This time I pushed ahead 
>> after understanding a better approach.
>>
>> I've gotten *almost* all the way to a successful 3.0.14 install of 
>> ReviewBoard. I've got it up and running, but one thing is going wrong, and 
>> I haven't figured out why, just yet. When I say I've got it up and running, 
>> that means that I've been able to perform rb-site upgrade on all the 
>> instances, login works, and I can browse the reviews. I can access the 
>> administrative pages (since I'm an admin). However, when I click on an 
>> individual review, I get an error:
>>
>> Traceback (most recent call last):
>>
>>   File "/usr/lib64/python2.7/site-packages/django/core/handlers/base.py", 
>> line 137, in get_response
>> response = response.render()
>>   File "/usr/lib64/python2.7/site-packages/django/template/response.py", 
>> line 105, in render
>> self.content = self.rendered_content
>>   File "/usr/lib64/python2.7/site-packages/django/template/response.py", 
>> line 82, in rendered_content
>> content = template.render(context)
>>   File "/usr/lib64/python2.7/site-packages/django/template/base.py", line 
>> 140, in render
>> return self._render(context)
>>   File "/usr/lib64/python2.7/site-packages/django/template/base.py", line 
>> 134, in _render
>> return self.nodelist.render(context)
>>   File "/usr/lib64/python2.7/site-packages/django/template/base.py", line 
>> 840, in render
>> bit = self.render_node(node, context)
>>   File "/usr/lib64/python2.7/site-packages/django/template/base.py", line 
>> 854, in render_node
>> return node.render(context)
>>   File 
>> "/usr/lib64/python2.7/site-packages/django/template/loader_tags.py", line 
>> 123, in render
>> return compiled_parent._render(context)
>>   File "/usr/lib64/python2.7/site-packages/django/template/base.py", line 
>> 134, in _render
>> return self.nodelist.render(context)
>>   File "/usr/lib64/python2.7/site-packages

In search of help packaging ReviewBoard 3.0.14 for Gentoo Linux, problem when running server, probably something simple I overlooked.

['Eric Johnson' via Review Board Community]

Mostly, I've managed to get quite far with packaging ReviewBoard for Linux.
Although I don't know much about the Gentoo packaging system, it has turned
out to be easier than I feared.

We're currently running ReviewBoard 2.5.18, installed using the portage
package manager. So we have done this packaging for 2.5.18. I tried this
upgrade previously, but was stymied and gave up. This time I pushed ahead
after understanding a better approach.

I've gotten *almost* all the way to a successful 3.0.14 install of
ReviewBoard. I've got it up and running, but one thing is going wrong, and
I haven't figured out why, just yet. When I say I've got it up and running,
that means that I've been able to perform rb-site upgrade on all the
instances, login works, and I can browse the reviews. I can access the
administrative pages (since I'm an admin). However, when I click on an
individual review, I get an error:

Traceback (most recent call last):

  File "/usr/lib64/python2.7/site-packages/django/core/handlers/base.py",
line 137, in get_response
response = response.render()
  File "/usr/lib64/python2.7/site-packages/django/template/response.py",
line 105, in render
self.content = self.rendered_content
  File "/usr/lib64/python2.7/site-packages/django/template/response.py",
line 82, in rendered_content
content = template.render(context)
  File "/usr/lib64/python2.7/site-packages/django/template/base.py", line
140, in render
return self._render(context)
  File "/usr/lib64/python2.7/site-packages/django/template/base.py", line
134, in _render
return self.nodelist.render(context)
  File "/usr/lib64/python2.7/site-packages/django/template/base.py", line
840, in render
bit = self.render_node(node, context)
  File "/usr/lib64/python2.7/site-packages/django/template/base.py", line
854, in render_node
return node.render(context)
  File "/usr/lib64/python2.7/site-packages/django/template/loader_tags.py",
line 123, in render
return compiled_parent._render(context)
  File "/usr/lib64/python2.7/site-packages/django/template/base.py", line
134, in _render
return self.nodelist.render(context)
  File "/usr/lib64/python2.7/site-packages/django/template/base.py", line
840, in render
bit = self.render_node(node, context)
  File "/usr/lib64/python2.7/site-packages/django/template/base.py", line
854, in render_node
return node.render(context)
  File "/usr/lib64/python2.7/site-packages/django/template/loader_tags.py",
line 123, in render
return compiled_parent._render(context)
  File "/usr/lib64/python2.7/site-packages/django/template/base.py", line
134, in _render
return self.nodelist.render(context)
  File "/usr/lib64/python2.7/site-packages/django/template/base.py", line
840, in render
bit = self.render_node(node, context)
  File "/usr/lib64/python2.7/site-packages/django/template/base.py", line
854, in render_node
return node.render(context)
  File "/usr/lib64/python2.7/site-packages/django/template/base.py", line
1125, in render
return func(*resolved_args, **resolved_kwargs)
  File
"/usr/lib64/python2.7/site-packages/djblets/extensions/templatetags/djblets_extensions.py",
line 295, in load_extensions_css
_render_css_bundle))
  File
"/usr/lib64/python2.7/site-packages/djblets/extensions/templatetags/djblets_extensions.py",
line 265, in _get_extension_bundles
yield renderer(context, extension, bundle_name)
  File
"/usr/lib64/python2.7/site-packages/djblets/extensions/templatetags/djblets_extensions.py",
line 143, in _render_css_bundle
name, 'CSS')
  File
"/usr/lib64/python2.7/site-packages/djblets/extensions/templatetags/djblets_extensions.py",
line 117, in _render_bundle
return node_cls('"%s"' % extension.get_bundle_id(name)).render(context)
  File
"/usr/lib64/python2.7/site-packages/pipeline/templatetags/pipeline.py",
line 140, in render
return self.render_compressed(package, package_name, 'css')
  File
"/usr/lib64/python2.7/site-packages/djblets/extensions/templatetags/djblets_extensions.py",
line 54, in render_compressed
rendered = self.render_compressed_output(*args, **kwargs)
  File
"/usr/lib64/python2.7/site-packages/pipeline/templatetags/pipeline.py",
line 82, in render_compressed_output
return method(package, package.output_filename)
  File
"/usr/lib64/python2.7/site-packages/pipeline/templatetags/pipeline.py",
line 147, in render_css
'url': mark_safe(staticfiles_storage.url(path))
  File
"/usr/lib64/python2.7/site-packages/django/contrib/staticfiles/storage.py",
line 139, in url
hashed_name = self.hashed_name(clean_name).replace('\\', '/')
  File
"/usr/lib64/python2.7/site-packages/django/contrib/staticfiles/storage.py",
line 96, in hashed_name
(clean_name, self))

ValueError: The file
'ext/rbintegrations.extension.RBIntegrationsExtension/css/fields.min.css'
could not be found with .

Note that this appears to be the same as:
https://groups.google.com/d/msg/reviewboard/FSzcHz-OaDg/89BXxRFDBAAJ
... but that thread in the mailing 

Re: HELP: Upgrade to 3.0.7 results in all reviews returning a Something broke! (Error 500)

['Eric Johnson' via Review Board Community]

Hi Alfred,

Were you ever able to resolve this issue? I'm now seeing an roughly 
identical problem with my install of 3.0.14...
I'm running Djblets 1.0.11, but looks to be the only substantive 
difference

Eric.

On Thursday, June 7, 2018 at 11:41:48 AM UTC-7, Alfred von Campe wrote:
>
>
> > On Jun 7, 2018, at 14:24, Alfred von Campe  > wrote: 
> > 
> > I’m not sure what is going on:  the initial “easy_install -U 
> ReviewBoard” did return an error, but after forcing the install of version 
> 3.0.3 where I was upgrading from, another easy_install -U ReviewBoard 
> succeeded, as did the rb-site upgrade.  I can add users again to review 
> groups (which is the reason I updated in the first place), but I can’t 
> access any reviews! 
>
>
> Here is an error from the log file which I hope will track down the issue: 
>
> 2018-06-07 18:32:56,590 - ERROR -  - 
> djblets.extensions.templatetags.djblets_extensions - Unable to load CSS 
> bundle "fields" for extension "Review Board Integrations" 
> (rbintegrations.extension.RBIntegrationsExtension) 
> Traceback (most recent call last): 
>   File 
> "/usr/lib/python2.7/site-packages/Djblets-1.0.6-py2.7.egg/djblets/extensions/templatetags/djblets_extensions.py",
>  
> line 117, in _render_bundle 
> return node_cls('"%s"' % 
> extension.get_bundle_id(name)).render(context) 
>   File 
> "/usr/lib/python2.7/site-packages/django_pipeline-1.6.14-py2.7.egg/pipeline/templatetags/pipeline.py",
>  
> line 140, in render 
> return self.render_compressed(package, package_name, 'css') 
>   File 
> "/usr/lib/python2.7/site-packages/Djblets-1.0.6-py2.7.egg/djblets/extensions/templatetags/djblets_extensions.py",
>  
> line 54, in render_compressed 
> rendered = self.render_compressed_output(*args, **kwargs) 
>   File 
> "/usr/lib/python2.7/site-packages/django_pipeline-1.6.14-py2.7.egg/pipeline/templatetags/pipeline.py",
>  
> line 82, in render_compressed_output 
> return method(package, package.output_filename) 
>   File 
> "/usr/lib/python2.7/site-packages/django_pipeline-1.6.14-py2.7.egg/pipeline/templatetags/pipeline.py",
>  
> line 147, in render_css 
> 'url': mark_safe(staticfiles_storage.url(path)) 
>   File 
> "/usr/lib/python2.7/site-packages/Django-1.6.11-py2.7.egg/django/contrib/staticfiles/storage.py",
>  
> line 139, in url 
> hashed_name = self.hashed_name(clean_name).replace('\\', '/') 
>   File 
> "/usr/lib/python2.7/site-packages/Django-1.6.11-py2.7.egg/django/contrib/staticfiles/storage.py",
>  
> line 96, in hashed_name 
> (clean_name, self)) 
> ValueError: The file 
> 'ext/rbintegrations.extension.RBIntegrationsExtension/css/fields.min.css' 
> could not be found with  0x55c9409c4fd0>. 
>
>
>

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/reviewboard/4933f7da-a83e-4246-a0d4-ddb670617c6f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Trying to get latest ReviewBoard to work on Gentoo Linux

['Eric Johnson' via Review Board Community]

Gentoo patches to pip to prevent installation as the root user - so as to
avoid package manager conflicts between emerge and pip.

To make it work, I'd need to install ReviewBoard packages as a non-root
user. Certainly possible to make that work, but it starts to feel like just
as many hoops as getting it to run that way as just putting together a
docker image. I'd have to update the PYTHON_PATH

Also, I was hoping someone might already have created some kind of Docker
build file that does most of what I need, although nobody has piped up yet.

Eric.


On Wed, May 2, 2018 at 7:35 PM, Christian Hammond 
wrote:

> Hi Eric,
>
> Why not just install via our official Python packages?
>
> Christian
>
>
> On Tue, May 1, 2018 at 10:04 eric via Review Board Community <
> reviewboard@googlegroups.com> wrote:
>
>>
>>
>> On Friday, April 20, 2018 at 9:54:23 AM UTC-7, Stephen Gallagher wrote:
>>
>>>
>>>
>>> On Fri, Apr 20, 2018 at 12:35 PM eric via Review Board Community <
>>> revie...@googlegroups.com> wrote:
>>>
 Hi Christian,

 Thanks so much for the response.


 On Wednesday, April 18, 2018 at 5:03:43 PM UTC-7, Christian Hammond
 wrote:
>
> It will, yes. You shouldn't need to make changes like that. This one
> in particular will break applications that try using Djblets in various
> ways. If this appears to fix packaging, then we really need to find out
> what's really going on to break it in the first place.
>

 I made some progress. Much closer.

 The Gentoo build that works with pip is mostly magic to me. I'm still
 trying to figure out the pieces.

 What I've figured out so far, is that as you suggest, I need to call
 setup.py (well, in a Gentoo ebuild, it is actually invoked via a wrapper
 command "esetup.py ..."). I have not yet gotten it to work, but I figured
 out several big steps forward.

 It would probably work better for Gentoo if setup.py develop was not a
 prerequisite to setup.py install. I see why you have it this way, but it
 makes it difficult to deal with.

 At the moment, I've figured out that I can patch out call the calls to
 _run_pip (which were triggering problems) - since the Gentoo environment
 already has the latest versions of those things installed.

 I'm tripping over the npm tool installation. While running package
 installs, Gentoo creates a sandbox, which prevents access to parts of the
 system that package install shouldn't normally need to touch. Looks like
 the Gentoo sandbox is preventing "npm install" from working. Trying to
 figure that out now.

 Since Gentoo mostly builds from source, I want to get it to work from
 the tar.gz distribution, but I can probably fall back to installing from
 the egg file, if I can't get this to work. Looks like the egg file has
 everything built as needed, and I wouldn't need to call "setup.py develop".

>>>
>>>
>>> Eric, I'm not sure how similar Gentoo is to Fedora, but if you want to
>>> have a look at how I'm doing the builds there, feel free to look at
>>> https://src.fedoraproject.org/rpms/ReviewBoard/blob/3.0/
>>> f/ReviewBoard.spec and https://src.fedoraproject.org/rpms/
>>> python-djblets/blob/1.0/f/python-djblets.spec
>>>
>>> I'm sort of "cheating" with the NPM build stuff. What I did was
>>> pre-download all of the NPMs ahead of time and then I have the build just
>>> untar the directory into the right place. This avoids issues like how the
>>> Fedora build system disallows network access (to ensure repeatable builds).
>>> It's also worth noting that the NPM bits are needed only at build-time and
>>> don't end up in the built package.
>>>
>>
>> After considering a bunch of different options, I've come to the
>> conclusion that I should pursue a radically different path. Since my goal
>> is not to build a generically useful ReviewBoard install for Gentoo, but
>> instead to simply get it up and running inside my company's data center,
>> I've concluded that setting up a Docker/Moby image and deploying that is
>> likely to lead to a better result.
>>
>> Anyone with suggestions for where to start?
>>
>> Eric.
>>
>>
>>
>>
>> --
>> Supercharge your Review Board with Power Pack:
>> https://www.reviewboard.org/powerpack/
>> Want us to host Review Board for you? Check out RBCommons:
>> https://rbcommons.com/
>> Happy user? Let us know! https://www.reviewboard.org/users/
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Review Board Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to reviewboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> --
> Christian Hammond
> President/CEO of Beanbag
> Makers of Review Board
>
> --
> Supercharge your Review Board with Power Pack:
> 

Re: Trying to get latest ReviewBoard to work on Gentoo Linux

['Eric Johnson' via Review Board Community]

Oops - by the way, for the previous post, although you can figure it out
from the stack trace, I'm trying to install Djblets-1.0.5

I seem to have made a big step forward. I used sed to edit the settings.py
file to replace

sed -e
"s/pipeline.storage.PipelineCachedStorage/pipeline.storage.NonPackagingPipelineCachedStorage/"
-i djblets/settings.py || die

Will this cause any problems (other than perhaps being slower than if the
post-processing was in place)?

Eric.

On Wed, Apr 18, 2018 at 4:15 PM, Eric Johnson  wrote:

> I'm tripping over getting the Djblets package to work.
>
> My current failure looks like this:
>
> Traceback (most recent call last):
>
>   File "contrib/internal/build-media.py", line 36, in 
>
> ret = call_command('collectstatic', interactive=False, verbosity=2)
>   File 
> "/usr/lib64/python2.7/site-packages/django/core/management/__init__.py",
> line 159, in call_command
> return klass.execute(*args, **defaults)
>   File "/usr/lib64/python2.7/site-packages/django/core/management/base.py",
> line 285, in execute
> output = self.handle(*args, **options)
>
>   File "/usr/lib64/python2.7/site-packages/django/core/management/base.py",
> line 415, in handle
> return self.handle_noargs(**options)
>
>   File "/usr/lib64/python2.7/site-packages/django/contrib/staticfil
> es/management/commands/collectstatic.py", line 173, in handle_noargs
> collected = self.collect()
>
>   File "/usr/lib64/python2.7/site-packages/django/contrib/staticfil
> es/management/commands/collectstatic.py", line 119, in collect
> for original_path, processed_path, processed in processor:
>
>   File "/usr/lib64/python2.7/site-packages/pipeline/storage.py", line 26,
> in post_process
> packager.pack_stylesheets(package)
>
>   File "/usr/lib64/python2.7/site-packages/pipeline/packager.py", line
> 96, in pack_stylesheets
> variant=package.variant, **kwargs)
>   File "/usr/lib64/python2.7/site-packages/pipeline/packager.py", line
> 105, in pack
> paths = self.compile(package.paths, force=True)
>   File "/usr/lib64/python2.7/site-packages/pipeline/packager.py", line
> 99, in compile
> return self.compiler.compile(paths, force=force)
>   File "/usr/lib64/python2.7/site-packages/pipeline/compilers/__init__.py",
> line 54, in compile
> return list(executor.map(_compile, paths))
>   File "/usr/lib64/python2.7/site-packages/concurrent/futures/_base.py",
> line 605, in result_iterator
> yield future.result()
>   File "/usr/lib64/python2.7/site-packages/concurrent/futures/_base.py",
> line 429, in result
> return self.__get_result()
>   File "/usr/lib64/python2.7/site-packages/concurrent/futures/thread.py",
> line 62, in run
> result = self.fn(*self.args, **self.kwargs)
>   File "/usr/lib64/python2.7/site-packages/pipeline/compilers/__init__.py",
> line 39, in _compile
> outdated = compiler.is_outdated(infile, outfile)
>   File "/var/tmp/portage/dev-python/Djblets-1.0.5/work/Djblets-1.0.
> 5/djblets/pipeline/compilers/less.py", line 83, in is_outdated
> self.execute_command(command, stdout_captured=imports_file)
>   File "/usr/lib64/python2.7/site-packages/pipeline/compilers/__init__.py",
> line 134, in execute_command
> error_output=stderr)
> pipeline.exceptions.CompilerError: [u'/var/tmp/portage/dev-python
> /Djblets-1.0.5/work/Djblets-1.0.5/djblets/pipeline/compilers/less-imports.js',
> u'--no-color', u'--source-map', u'--autoprefix=> 2%, ie >= 9',
> u'/var/tmp/portage/dev-python/Djblets-1.0.5/work/Djblets-1.0.5/dj
> blets/htdocs/static/djblets/css/forms/conditions.less'] exit code 1
> module.js:471
> throw err;
> ^
>
> Error: Cannot find module 'less'
> at Function.Module._resolveFilename (module.js:469:15)
> at Function.Module._load (module.js:417:25)
> at Module.require (module.js:497:17)
> at require (internal/module.js:20:19)
> at Object. (/var/tmp/portage/dev-python/D
> jblets-1.0.5/work/Djblets-1.0.5/djblets/pipeline/compilers/
> less-imports.js:18:12)
> at Module._compile (module.js:570:32)
> at Object.Module._extensions..js (module.js:579:10)
> at Module.load (module.js:487:32)
> at tryModuleLoad (module.js:446:12)
> at Function.Module._load (module.js:438:3)
>
> Traceback (most recent call last):
>   File "setup.py", line 443, in 
> 'Topic :: Software Development :: Libraries :: Python Modules',
>   File "/usr/lib64/python2.7/site-packages/setuptools/__init__.py", line
> 129, in setup
> return distutils.core.setup(**attrs)
>   File "/usr/lib64/python2.7/distutils/core.py", line 151, in setup
> dist.run_commands()
>   File "/usr/lib64/python2.7/distutils/dist.py", line 953, in run_commands
> self.run_command(cmd)
>   File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command
> cmd_obj.run()
>   File "/usr/lib64/python2.7/site-packages/setuptools/command/install.py",
> line 61, in run
> return orig.install.run(self)
>   File 

Trying to get latest ReviewBoard to work on Gentoo Linux

['Eric Johnson' via Review Board Community]

I'm tripping over getting the Djblets package to work.

My current failure looks like this:

Traceback (most recent call last):

  File "contrib/internal/build-media.py", line 36, in 

ret = call_command('collectstatic', interactive=False, verbosity=2)
  File
"/usr/lib64/python2.7/site-packages/django/core/management/__init__.py",
line 159, in call_command
return klass.execute(*args, **defaults)
  File "/usr/lib64/python2.7/site-packages/django/core/management/base.py",
line 285, in execute
output = self.handle(*args, **options)

  File "/usr/lib64/python2.7/site-packages/django/core/management/base.py",
line 415, in handle
return self.handle_noargs(**options)

  File
"/usr/lib64/python2.7/site-packages/django/contrib/staticfiles/management/commands/collectstatic.py",
line 173, in handle_noargs
collected = self.collect()

  File
"/usr/lib64/python2.7/site-packages/django/contrib/staticfiles/management/commands/collectstatic.py",
line 119, in collect
for original_path, processed_path, processed in processor:

  File "/usr/lib64/python2.7/site-packages/pipeline/storage.py", line 26,
in post_process
packager.pack_stylesheets(package)

  File "/usr/lib64/python2.7/site-packages/pipeline/packager.py", line 96,
in pack_stylesheets
variant=package.variant, **kwargs)
  File "/usr/lib64/python2.7/site-packages/pipeline/packager.py", line 105,
in pack
paths = self.compile(package.paths, force=True)
  File "/usr/lib64/python2.7/site-packages/pipeline/packager.py", line 99,
in compile
return self.compiler.compile(paths, force=force)
  File "/usr/lib64/python2.7/site-packages/pipeline/compilers/__init__.py",
line 54, in compile
return list(executor.map(_compile, paths))
  File "/usr/lib64/python2.7/site-packages/concurrent/futures/_base.py",
line 605, in result_iterator
yield future.result()
  File "/usr/lib64/python2.7/site-packages/concurrent/futures/_base.py",
line 429, in result
return self.__get_result()
  File "/usr/lib64/python2.7/site-packages/concurrent/futures/thread.py",
line 62, in run
result = self.fn(*self.args, **self.kwargs)
  File "/usr/lib64/python2.7/site-packages/pipeline/compilers/__init__.py",
line 39, in _compile
outdated = compiler.is_outdated(infile, outfile)
  File
"/var/tmp/portage/dev-python/Djblets-1.0.5/work/Djblets-1.0.5/djblets/pipeline/compilers/less.py",
line 83, in is_outdated
self.execute_command(command, stdout_captured=imports_file)
  File "/usr/lib64/python2.7/site-packages/pipeline/compilers/__init__.py",
line 134, in execute_command
error_output=stderr)
pipeline.exceptions.CompilerError:
[u'/var/tmp/portage/dev-python/Djblets-1.0.5/work/Djblets-1.0.5/djblets/pipeline/compilers/less-imports.js',
u'--no-color', u'--source-map', u'--autoprefix=> 2%, ie >= 9',
u'/var/tmp/portage/dev-python/Djblets-1.0.5/work/Djblets-1.0.5/dj
blets/htdocs/static/djblets/css/forms/conditions.less'] exit code 1
module.js:471
throw err;
^

Error: Cannot find module 'less'
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object.
(/var/tmp/portage/dev-python/Djblets-1.0.5/work/Djblets-1.0.5/djblets/pipeline/compilers/less-imports.js:18:12)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)

Traceback (most recent call last):
  File "setup.py", line 443, in 
'Topic :: Software Development :: Libraries :: Python Modules',
  File "/usr/lib64/python2.7/site-packages/setuptools/__init__.py", line
129, in setup
return distutils.core.setup(**attrs)
  File "/usr/lib64/python2.7/distutils/core.py", line 151, in setup
dist.run_commands()
  File "/usr/lib64/python2.7/distutils/dist.py", line 953, in run_commands
self.run_command(cmd)
  File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
  File "/usr/lib64/python2.7/site-packages/setuptools/command/install.py",
line 61, in run
return orig.install.run(self)
  File "/usr/lib64/python2.7/distutils/command/install.py", line 563, in run
self.run_command('build')
  File "/usr/lib64/python2.7/distutils/cmd.py", line 326, in run_command
self.distribution.run_command(command)
  File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()

Not exactly sure what to do from here. Options I can think of:

   - Change something like setup.py or settings.py so that "less" won't be
   executed.
   - Figure out how to get less in place before this line executes
   - Avoid running setup.py - it appears that pip install Djblets avoids
   calling setup.py (or maybe it does, it just calls it differently?)
   - ...?

Any tips or direction anyone an provide?

Eric.

-- 
Supercharge your Review Board 

Djblets missing requires constraint on markdown?

['Eric Johnson' via Review Board Community]

I'm working on packaging ReviewBoard for Gentoo, so that I can deploy an
update.

I noticed that the Djblets-1.0.3 release does not state a requirement on
markdown. I'm not a Python expert, so I don't know if there's a good reason
for its absence, or just an oversight?

In any case, if it does need the dependency, then it should be on version
2.6.9 or later, as 2.6.8 has a bug that affects ReviewBoard.

Thanks!

Eric.

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.